April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Meanwhile, at another vm

by Dave Mason

From: http://www.jcp.org/en/jsr/detail?id=292 "We will also investigate support for hotswapping, the capability to modify the structure of classes at run time." So, yes, they planned to "investigate" a version of become: The DaVinci Machine http://openjdk.java.net/projects/mlvm/ has an implementation: http://wiki.jvmlangsummit.com/images/4/41/DaVinciMachineTalk.pdf ../Dave

April 13, 2011

Re: [Pharo-project] Meanwhile, at another vm

by Philippe Marschall

On 13.04.2011 19:40, Stephan Eggermont wrote: > JSR 292 explicitly talks about become: (calls it hotswap) and is supposed > to make it possible to run Smalltalk efficiently on a jvm. What I know as hotswap as hot swap would not help with #become:. My understanding is that when "they" went from an object table to direct pointers for memory access speed that made it more complicated to implement #become: and certainly slower. Cheers Philippe

April 13, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by Toon Verwaest

I find the "managing the exception hierarchy" a bit strange... Do you really have to manage anything more than just normal classes? Every exception is related to a specific part of your code, just like other classes. What's wrong with creating hundreds of small classes wherever it's necessary? You might save a tiny bit of memory by using error codes or symbols, but I don't really see much more of a gain there, while you do gain from proper objects. Being clear and modeling properly generally pays off in the long run. And the bit of runtime memory you save isn't really worth your while... Or am I missing something else? I didn't really follow the whole conversation in-depth. cheers, Toon On 04/13/2011 09:54 PM, Dale Henrichs wrote: > Camillo, > > Hey, I _am_ old, but not _that_ old:) ... There are a couple of things > that were invented in the Stone Age that have survived to today, so > old ideas are not immediately bad, because they are old:) > > It feels like you are creating classes that are not much more than > symbols ... > > I am not one to shy away from using classes when they are called for, > but I am just making a practicality point ... we don't have a unique > class for each character in the alphabet, but we could....we could > have a unique class for every possible error condition or not ... > > I think it is simply a practical answer... > > I do maintain that you _should_ use some sort of test along the lines > of: "Will anyone ever need to write a handler for the exception?" in > your criteria for deciding when to create a class and when to use > something like a "reason code" to disambiguate the signalling site... > > Dale > > On 04/13/2011 12:32 PM, Camillo Bruni wrote: >> Perfect, I ll be there to bang heads ;). >> >> So without "Exception" pre- or suffix seems to be nice. However I >> don't see the need of using symbols over real classes. This feels >> indeed like going to stone age of error handling, thats what you have >> polymorphism and ExceptionSets for. >> >> Anyway, the main idea is to make single exceptions recognizable and >> not just use one single, basically meaningless, exception type. >> >> best regards, Camillo Bruni >> >> >> On 2011-04-13, at 21:22, Sven Van Caekenberghe wrote: >> >>> Thanks a lot everybody for the reactions, this could become a nice >>> discussion next Friday. All points raised are valid, I would like >>> simple names and a compact multipurpose hierarchy too. >>> >>> On 13 Apr 2011, at 19:39, Dale Henrichs wrote: >>> >>>> Some thoughts from an old man (started programming before >>>> exceptions of any kind were available:) ... >>>> >>>> In the old days, error numbers had a place in the universe ... >>>> error numbers of a certain range indicated specific errors and >>>> the "error handlers" could check for a range or a specific error >>>> ... >>>> >>>> Today I think there is still a place for the notion of "error >>>> numbers". >>>> >>>> In Smalltalk I would use Symbols instead of numbers, but the idea >>>> would be to use a concrete exception class to identify broad >>>> categories of error conditions (i.e., FileStreamError) and a >>>> symbolic "reason code" to indicate the specific error (i.e., >>>> #fileDoesNotExist, #fileExists, #cannotDelete, etc.), that way an >>>> error handler can be written for FileStreamError and then >>>> specific action take with respect to which "reason code" is >>>> involved, if such action is needed. >>>> >>>> The main advantage of using reasonCodes over using a "class per >>>> error condition" is that you can reduce the size of the Exception >>>> hierarchy to a manageable size (GemStone has hundreds of error >>>> conditions, so we've resorted to using "reason codes" to manage >>>> the size of the hierarchy). >>>> >>>> As Hernan hints, more often than not it is important to be very >>>> specific about the error condition when signalling an error (a >>>> unique error message per "per reason code" would be desirable), >>>> but the there are very few places where the handler is going to >>>> be that specific ... >>>> >>>> In other words, if it is likely that programmers in the course of >>>> using an application will be writing specific error handlers to >>>> distinguish between the KeyNotFound and ValueNotFound condition, >>>> then classes should be created, otherwise, the NotFoundException >>>> could be implemented with three reason codes: #keyNotFound, >>>> #valueNotFound, and #elementNotFound and you'd get the best of >>>> both worlds, explicit information at the signalling site and a >>>> much smaller and more manageable Exception class hierarchy. >>>> >>>> Dale >>>> >>>> On 04/13/2011 10:15 AM, Hernan Wilkinson wrote: >>>>> I think it is not a good idea to use the prefix Exception. We >>>>> do not use the word "exception" in real life, so we should not >>>>> do it on our systems. About the proposed hierarchy, the problem >>>>> with having specific exceptions is that they are important for >>>>> those who catch them, not for those who signal them. For >>>>> example, besides the name, what is the difference between >>>>> KeyNotFound or ValueNotFound? none. So, I think that the >>>>> exception hierarchy should be grown from it uses, not created >>>>> based on how or where they are signaled. >>>>> >>>>> my 2 cents :-) >>>>> >>>>> On Wed, Apr 13, 2011 at 1:55 PM, Miguel >>>>> CobÃ¡<miguel.coba(a)gmail.com <mailto:miguel.coba@gmail.com>> >>>>> wrote: >>>>> >>>>> El miÃ©, 13-04-2011 a las 14:52 +0200, Camillo Bruni escribiÃ³: >>>>> >>>>>> And as Mariano pointed out, there should be a convention on >>>>>> the naming: I am still not sure about suffixing the exception >>>>>> classes >>>>> with >>>>>> "Exception", but I guess this is a good thing to do. Though >>>>>> I >>>>> must say >>>>>> that I omitted it so far ;) and just put the verb there, but >>>>>> that can be easily changed. >>>>> >>>>> I would say no to suffixes. Analogous to announcements, they >>>>> shouldn't have the suffix. The name should be descriptive >>>>> enough and intention revealing that the suffix isn't needed in >>>>> most cases. For example, I think that >>>>> >>>>> DividedByZero >>>>> >>>>> is better than >>>>> >>>>> DividedByZeroException >>>>> >>>>> and no information is lost with the sorter name. Instead, >>>>> DivideByZero isn't clear enough to indicate that is a event >>>>> that happened. >>>>> >>>>> What do you think? >>>>> >>>>> -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz >>>>> http://miguel.leugim.com.mx >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- *HernÃ¡n Wilkinson Agile Software Development, Teaching& >>>>> Coaching Mobile: +54 - 911 - 4470 - 7207 email: >>>>> hernan.wilkinson(a)10Pines.com site: >>>>> http://www.10Pines.com<http://www.10pines.com/>* >>>>> >>>> >>>> >>> >>> >> >> > >

April 13, 2011

Re: [Pharo-project] About float: new chapter looking for reader and contributors

by Nicolas Cellier

Here is a small variation. It's not perfect, and most elements are already in Stephane's text. But maybe we can jump deeper in the first example that claims some explanations. We can first explain that 0.1 will answer the Float nearest to (1/10). Thanks to this important property, if we enter 0.1, it will be printed 0.1 and reinterpreted the same. A nice property to have! However, what is fundamental is that this Float won't be equal to (1/10). How is this so ? Hey we didn't learn that in school ! Well, Float have an internal representation in base 2, of the form mantissa * (2 raisedTo: exponent). There is no way to represent (1/10) in base 2 with a finite number of bits... (like illustrated with 1.3 example, #significandAsInteger, #exponent, #ulp and such kind of messages...). A rounding operation has to occur to make this number fit in Float internal representation ( it might be good to tell that Pharo Float follow the IEEE 754 double precision standard with a link to http://en.wikipedia.org/wiki/IEEE_754-1985 . This standard governs the way most FPU work on this planet). This rounding operation introduce a rounding error, and thus we don't get exactly (1/10). To know the exact internal representation of 0.1 the Smalltalk way is as usual to send a message: 0.1 asTrueFraction. The same goes with 0.2, it's not equal to (2/10), check it with 0.2 asTrueFraction. So what goes on with this operation 0.1+0.2 ? In fact you asked the system to perform following operation (0.1 asTrueFraction+0.2 asTrueFraction) asFloat. (0.1 asTrueFraction+0.2 asTrueFraction) is an exact operation, but the result again does not fit in Float internal representation: (0.1 asTrueFraction+0.2 asTrueFraction) numerator highBit -> 54 (0.1 asTrueFraction+0.2 asTrueFraction) numerator lowBit -> 1 This means that 54 bits of mantissa are required to represent this number. Float only have 53 Float precision -> 53 So converting it to aFloat requires another rounding operation, and due to this rounding error, (0.1 asTrueFraction+0.2 asTrueFraction) ~= (0.1 asTrueFraction+0.2 asTrueFraction) asFloat. That's exactly how your IEEE-754 compliant FPU will work. In the whole process, 3 rounding errors have been cumulated: (1/10) asFloat -> 0.1 (the error is not yet visible, but it's here already) (2/10) asFloat -> 0.2 (same) (0.1 asTrueFraction+0.2 asTrueFraction) asFloat -> 0.30000000000000004 This is to be compared to 0.3, which has a single rounding error: (3/10) asFloat -> 0.3 Due to these rounding errors, and the way they cumulate or annihilate, both result might differ. And in this case, they differ. This is a very important property of Float. Float are fast thanks to hardware acceleration, and thanks to these rounding errors that keep the number of significant bits from growing. But the counterpart is that operations on Float are inexact. Due to this inexactness, it is most often inadequate to rely on strict equality of Float, as this very simple example illustrates. Instead, Float comparisons shall better be tested with fuzzy tolerance. Note that the nice thing with Pharo is that you immediately see that (0.1+0.2) ~= 0.3 thanks to extraneous digits printed. Pharo does not hide the horrible truth by shortening the printed representation to 0.3 like some system do. However, the decimal printed form does not show you the truth about 0.1 ~= (1/10). Inexactness is hidden. This is an implicit knowledge to remember about Float, that you now learned with this lesson. Remember, this is not a deficiency of Pharo. This is the way Float are expected to work whatever the language. Nicolas 2011/4/13 laurent laffont <laurent.laffont(a)gmail.com>: > > > > On Tue, Apr 12, 2011 at 6:07 PM, stephane ducasse <stephane.ducasse(a)free.fr> > wrote: >> >> Hi guys >> >> I started to put in shape a chapter on floats based on the numerous >> discussions we got over the years. >> You can find it on github under the pharo by example book/Floats > > > For me it's a good candidate for a ProfStef tutorial (text, evaluations, > text, ...) > Laurent > >> >> Stef >> > >

April 13, 2011

Re: [Pharo-project] [squeak-dev] [ANN] Seattle Smalltalk Users Group

by Casey Ransberger

LOL yeah and the roads here just go every which way... it's as if they gave a guy two bottles of scotch, and wherever he walked with them, they built a road. Seriously, though, if you think about it: Smalltalk has a culture that was founded by musicians. One thing I'd really like to see is a room full of people face to face figuring out new and interesting ways to make music with Squeak or Scratch. I would encourage people to bring their instruments:) On Wed, Apr 13, 2011 at 12:55 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Excellent idea. I cc'ed vw. > > BTW... I am imaging how the logo could look like...something betweenKurt > Cobain and the Smalltalk baloon heheheh. > > On Wed, Apr 13, 2011 at 9:52 PM, Casey Ransberger < > casey.obrien.r(a)gmail.com> wrote: > >> A while back I asked if anyone on the squeak-dev list was in the greater >> Seattle area and wanted to meet up. I did get a few responses. Thanks to >> those who wrote back, and I apologize for the delay. I'm starting this up in >> part to create a venue here where Smalltalk isn't automatically out as >> off-topic. The idea is that it's about Smalltalk and anything remotely >> related to Smalltalk. In fact I'd really like this to be open to everyone >> who can be respectful to other people. The rest is just a bunch of >> implementation detail! >> >> So if you're in the neighborhood, and you think you might like to meet up >> with some like minded people on a regular basis, do pop over and add >> yourself to the list. I figure I'll work out a schedule if and when I have >> signups, but in general it will probably be early evenings on Wednesdays, >> maybe once a month to begin with. >> >> The site is here: >> >> http://www.meetup.com/Seattle-Smalltalk-Users-Group/ >> >> If anyone here is on the vwnc list and would like to pass my message along >> there, or anywhere else it might reach Smalltalkers in the Seattle area, I'd >> be much obliged! >> >> -- >> Casey Ransberger >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Casey Ransberger

April 13, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by Hernan Wilkinson

I completely agree with what Dale is saying... if you look at Patagonia (is on squeak source) you will see a package call Patagonia-AssertionsModel where I use something similar (if not the same) as Dale is saying... That package reifies different types of assertions, but when an assertion fails, it only throws one exception... the problem is how to handle an specific assertion failure?... if you look at the method #asExceptionToHandle you will get it, but basically from the handler point of view you write: [ bla bla bla ] on: #earlyRegistrationFeeShouldBeLessThanLateRegistrationFee asExceptionToHandle do: [ :anAssertionFailure | .... ] Doing so the exception hierarchy is really simple. But each assertion has a name (what Dale calls "error numbers" at the begining) so the assertion failure (the exception) knows the assertion that failed and therefore it can be identified by the assertion's name, and you don't need to have a class per exception.... (the cool thing is that the name of an assertion is automatically set with the name of the method you are creating the assertion in, hehe, so if you rename the "helper" method where you create the assertion, the rename refactoring takes care of renaming all the places where it is handle :-) ) Anyway, being able to extend the exception mechanism with this is another reason why Smalltalk will never die :-) On Wed, Apr 13, 2011 at 2:39 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Some thoughts from an old man (started programming before exceptions of any > kind were available:) ... > > In the old days, error numbers had a place in the universe ... error > numbers of a certain range indicated specific errors and the "error > handlers" could check for a range or a specific error ... > > Today I think there is still a place for the notion of "error numbers". > > In Smalltalk I would use Symbols instead of numbers, but the idea would be > to use a concrete exception class to identify broad categories of error > conditions (i.e., FileStreamError) and a symbolic "reason code" to indicate > the specific error (i.e., #fileDoesNotExist, #fileExists, #cannotDelete, > etc.), that way an error handler can be written for FileStreamError and then > specific action take with respect to which "reason code" is involved, if > such action is needed. > > The main advantage of using reasonCodes over using a "class per error > condition" is that you can reduce the size of the Exception hierarchy to a > manageable size (GemStone has hundreds of error conditions, so we've > resorted to using "reason codes" to manage the size of the hierarchy). > > As Hernan hints, more often than not it is important to be very specific > about the error condition when signalling an error (a unique error message > per "per reason code" would be desirable), but the there are very few places > where the handler is going to be that specific ... > > In other words, if it is likely that programmers in the course of using an > application will be writing specific error handlers to distinguish between > the KeyNotFound and ValueNotFound condition, then classes should be created, > otherwise, the NotFoundException could be implemented with three reason > codes: #keyNotFound, #valueNotFound, and #elementNotFound and you'd get the > best of both worlds, explicit information at the signalling site and a much > smaller and more manageable Exception class hierarchy. > > Dale > > > On 04/13/2011 10:15 AM, Hernan Wilkinson wrote: > >> I think it is not a good idea to use the prefix Exception. We do not use >> the word "exception" in real life, so we should not do it on our systems. >> About the proposed hierarchy, the problem with having specific >> exceptions is that they are important for those who catch them, not for >> those who signal them. For example, besides the name, what is the >> difference between KeyNotFound or ValueNotFound? none. So, I think that >> the exception hierarchy should be grown from it uses, not created based >> on how or where they are signaled. >> >> my 2 cents :-) >> >> On Wed, Apr 13, 2011 at 1:55 PM, Miguel CobÃ¡ <miguel.coba(a)gmail.com >> <mailto:miguel.coba@gmail.com>> wrote: >> >> El miÃ©, 13-04-2011 a las 14:52 +0200, Camillo Bruni escribiÃ³: >> >> > And as Mariano pointed out, there should be a convention on the >> > naming: I am still not sure about suffixing the exception classes >> with >> > "Exception", but I guess this is a good thing to do. Though I >> must say >> > that I omitted it so far ;) and just put the verb there, but that >> can >> > be easily changed. >> >> I would say no to suffixes. Analogous to announcements, they shouldn't >> have the suffix. The name should be descriptive enough and intention >> revealing that the suffix isn't needed in most cases. For example, I >> think that >> >> DividedByZero >> >> is better than >> >> DividedByZeroException >> >> and no information is lost with the sorter name. Instead, DivideByZero >> isn't clear enough to indicate that is a event that happened. >> >> What do you think? >> >> -- >> Miguel CobÃ¡ >> http://twitter.com/MiguelCobaMtz >> http://miguel.leugim.com.mx >> >> >> >> >> >> >> >> -- >> *HernÃ¡n Wilkinson >> Agile Software Development, Teaching & Coaching >> Mobile: +54 - 911 - 4470 - 7207 >> email: hernan.wilkinson(a)10Pines.com >> site: http://www.10Pines.com <http://www.10pines.com/>* >> >> > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

April 13, 2011

Re: [Pharo-project] OSProcess and CommandShell

by Miguel CobÃ¡

OSProcess is supported and all tests are green in Pharo 1.1 and Pharo 1.2. The stable version for Pharo 1.2 is the 4.4.0 but you can also load and run 4.3.11 and 4.3.12 (although if you don't disable deprecations warnings a lot of pop ups will show). 4.4.0 doesn't have problems with deprecated methods. To load: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOSProcess'; load. ((Smalltalk at: #ConfigurationOfOSProcess) project version: #stable) load. CommandShell hasn't a configuration so you'll have to load it from the monticello repository following the documentation of it somewhere in the wiki. Cheers El miÃ©, 13-04-2011 a las 15:23 -0300, Casimiro de Almeida Barreto escribiÃ³: > I'd like to know the state of: > > OSProcess > and > CommandShell > > under pharo. > > There's a ConfigurationOfOSProcess but there's no > ConfigurationOfCommandShell. > > What's working and what's not working? > > Best regards > > CdAB > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 13, 2011

Re: [Pharo-project] [squeak-dev] [ANN] Seattle Smalltalk Users Group

by Mariano Martinez Peck

Excellent idea. I cc'ed vw. BTW... I am imaging how the logo could look like...something betweenKurt Cobain and the Smalltalk baloon heheheh. On Wed, Apr 13, 2011 at 9:52 PM, Casey Ransberger <casey.obrien.r(a)gmail.com>wrote: > A while back I asked if anyone on the squeak-dev list was in the greater > Seattle area and wanted to meet up. I did get a few responses. Thanks to > those who wrote back, and I apologize for the delay. I'm starting this up in > part to create a venue here where Smalltalk isn't automatically out as > off-topic. The idea is that it's about Smalltalk and anything remotely > related to Smalltalk. In fact I'd really like this to be open to everyone > who can be respectful to other people. The rest is just a bunch of > implementation detail! > > So if you're in the neighborhood, and you think you might like to meet up > with some like minded people on a regular basis, do pop over and add > yourself to the list. I figure I'll work out a schedule if and when I have > signups, but in general it will probably be early evenings on Wednesdays, > maybe once a month to begin with. > > The site is here: > > http://www.meetup.com/Seattle-Smalltalk-Users-Group/ > > If anyone here is on the vwnc list and would like to pass my message along > there, or anywhere else it might reach Smalltalkers in the Seattle area, I'd > be much obliged! > > -- > Casey Ransberger > > > > -- Mariano http://marianopeck.wordpress.com

April 13, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by Dale Henrichs

Camillo, Hey, I _am_ old, but not _that_ old:) ... There are a couple of things that were invented in the Stone Age that have survived to today, so old ideas are not immediately bad, because they are old:) It feels like you are creating classes that are not much more than symbols ... I am not one to shy away from using classes when they are called for, but I am just making a practicality point ... we don't have a unique class for each character in the alphabet, but we could....we could have a unique class for every possible error condition or not ... I think it is simply a practical answer... I do maintain that you _should_ use some sort of test along the lines of: "Will anyone ever need to write a handler for the exception?" in your criteria for deciding when to create a class and when to use something like a "reason code" to disambiguate the signalling site... Dale On 04/13/2011 12:32 PM, Camillo Bruni wrote: > Perfect, I ll be there to bang heads ;). > > So without "Exception" pre- or suffix seems to be nice. However I > don't see the need of using symbols over real classes. This feels > indeed like going to stone age of error handling, thats what you have > polymorphism and ExceptionSets for. > > Anyway, the main idea is to make single exceptions recognizable and > not just use one single, basically meaningless, exception type. > > best regards, Camillo Bruni > > > On 2011-04-13, at 21:22, Sven Van Caekenberghe wrote: > >> Thanks a lot everybody for the reactions, this could become a nice >> discussion next Friday. All points raised are valid, I would like >> simple names and a compact multipurpose hierarchy too. >> >> On 13 Apr 2011, at 19:39, Dale Henrichs wrote: >> >>> Some thoughts from an old man (started programming before >>> exceptions of any kind were available:) ... >>> >>> In the old days, error numbers had a place in the universe ... >>> error numbers of a certain range indicated specific errors and >>> the "error handlers" could check for a range or a specific error >>> ... >>> >>> Today I think there is still a place for the notion of "error >>> numbers". >>> >>> In Smalltalk I would use Symbols instead of numbers, but the idea >>> would be to use a concrete exception class to identify broad >>> categories of error conditions (i.e., FileStreamError) and a >>> symbolic "reason code" to indicate the specific error (i.e., >>> #fileDoesNotExist, #fileExists, #cannotDelete, etc.), that way an >>> error handler can be written for FileStreamError and then >>> specific action take with respect to which "reason code" is >>> involved, if such action is needed. >>> >>> The main advantage of using reasonCodes over using a "class per >>> error condition" is that you can reduce the size of the Exception >>> hierarchy to a manageable size (GemStone has hundreds of error >>> conditions, so we've resorted to using "reason codes" to manage >>> the size of the hierarchy). >>> >>> As Hernan hints, more often than not it is important to be very >>> specific about the error condition when signalling an error (a >>> unique error message per "per reason code" would be desirable), >>> but the there are very few places where the handler is going to >>> be that specific ... >>> >>> In other words, if it is likely that programmers in the course of >>> using an application will be writing specific error handlers to >>> distinguish between the KeyNotFound and ValueNotFound condition, >>> then classes should be created, otherwise, the NotFoundException >>> could be implemented with three reason codes: #keyNotFound, >>> #valueNotFound, and #elementNotFound and you'd get the best of >>> both worlds, explicit information at the signalling site and a >>> much smaller and more manageable Exception class hierarchy. >>> >>> Dale >>> >>> On 04/13/2011 10:15 AM, Hernan Wilkinson wrote: >>>> I think it is not a good idea to use the prefix Exception. We >>>> do not use the word "exception" in real life, so we should not >>>> do it on our systems. About the proposed hierarchy, the problem >>>> with having specific exceptions is that they are important for >>>> those who catch them, not for those who signal them. For >>>> example, besides the name, what is the difference between >>>> KeyNotFound or ValueNotFound? none. So, I think that the >>>> exception hierarchy should be grown from it uses, not created >>>> based on how or where they are signaled. >>>> >>>> my 2 cents :-) >>>> >>>> On Wed, Apr 13, 2011 at 1:55 PM, Miguel >>>> CobÃ¡<miguel.coba(a)gmail.com <mailto:miguel.coba@gmail.com>> >>>> wrote: >>>> >>>> El miÃ©, 13-04-2011 a las 14:52 +0200, Camillo Bruni escribiÃ³: >>>> >>>>> And as Mariano pointed out, there should be a convention on >>>>> the naming: I am still not sure about suffixing the exception >>>>> classes >>>> with >>>>> "Exception", but I guess this is a good thing to do. Though >>>>> I >>>> must say >>>>> that I omitted it so far ;) and just put the verb there, but >>>>> that can be easily changed. >>>> >>>> I would say no to suffixes. Analogous to announcements, they >>>> shouldn't have the suffix. The name should be descriptive >>>> enough and intention revealing that the suffix isn't needed in >>>> most cases. For example, I think that >>>> >>>> DividedByZero >>>> >>>> is better than >>>> >>>> DividedByZeroException >>>> >>>> and no information is lost with the sorter name. Instead, >>>> DivideByZero isn't clear enough to indicate that is a event >>>> that happened. >>>> >>>> What do you think? >>>> >>>> -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz >>>> http://miguel.leugim.com.mx >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- *HernÃ¡n Wilkinson Agile Software Development, Teaching& >>>> Coaching Mobile: +54 - 911 - 4470 - 7207 email: >>>> hernan.wilkinson(a)10Pines.com site: >>>> http://www.10Pines.com<http://www.10pines.com/>* >>>> >>> >>> >> >> > >

April 13, 2011

Re: [Pharo-project] [COTDC] 47 - TAssertable

by Mariano Martinez Peck

On Wed, Apr 13, 2011 at 9:28 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > On Tue, Apr 12, 2011 at 10:14 PM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> Today: TAssertable >> > > Is it used ? Could not find any reference. > > I think it is not used yet. I think it is a Trait so that we can make things assertable and not need to subclass from TestCase for example. I may expect that TestCase uses such Trait instead of implementing all those methods, but it is not the case. Even more, TAssertable users size -> 0. So...seems a work half done. Adrian Kuhn introduce it. Check http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=12948… Cheers Mariano > > Laurent. > > > > >> >> Comment Of The Day Contest - One Day One Comment >> Rules: >> #1: Each day a not commented class is elected. Each day the best comment >> will be integrated with name of the author(s). >> #2: If you cannot comment it, deprecate it. >> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >> >> Laurent >> > > -- Mariano http://marianopeck.wordpress.com

April 13, 2011