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

[Pharo-project] Document on UIBuilder Tool

by sourav roy

Hi all,Can any suggest me some documents on1.UIBuilder Tool2.UI/Morph Class3.Database Connection Programming using Pharo.Thanks&Regards,Sourav RoyBangaloreIndiaGet Yourself a cool, short @in.com Email ID now!

April 13, 2011

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

by Stephan Eggermont

JSR 292 explicitly talks about become: (calls it hotswap) and is supposed to make it possible to run Smalltalk efficiently on a jvm. I don't know how complete the jsr 292 implementation is of mlvm. I got the link in a tweet. Roos builds modular automated test equipment. Stephan

April 13, 2011

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

by Dale Henrichs

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] Improving Pharo's Exception Hierarchy

by Hernan Wilkinson

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> 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] Improving Pharo's Exception Hierarchy

by Camillo Bruni

On 2011-04-13, at 18:55, Miguel CobÃ¡ 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? If this has been applied in the same sense before and its not a big deal I would prefer no suffixes as well. camillo

April 13, 2011

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

by Miguel CobÃ¡

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

April 13, 2011

Re: [Pharo-project] Issue 4003 in pharo: Build of Core 1.3 broken because of integration of 13147

by pharo＠googlecode.com

Updates: Status: Closed Comment #8 on issue 4003 by marcus.d...(a)gmail.com: Build of Core 1.3 broken because of integration of 13147 http://code.google.com/p/pharo/issues/detail?id=4003 fixed

April 13, 2011

[Pharo-project] Issue 4006 in pharo: Some UI improvement

by pharo＠googlecode.com

Status: FixProposed Owner: Benjamin...(a)gmail.com Labels: Nautilus New issue 4006 by Benjamin...(a)gmail.com: Some UI improvement http://code.google.com/p/pharo/issues/detail?id=4006 - Extraction of a method in IconicButton to allow subclasses to easily redefine the extra border. - a forgotten change set about PluggableMenuItemSpec to allow the enablement to depend of a block without be forced of building the whole menu again Attachments: IconicButtonImprovement.1.cs 728 bytes PluggableMenuItemSpec.BenjaminVanRyseghem.1.cs 1.1 KB

April 13, 2011

[Pharo-project] new transcript :(

by StÃ©phane Ducasse

hi guys why there is no scrollbar on the widgets? why I cannot select text there? why I cannot delete text there? Stef

April 13, 2011

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

by StÃ©phane Ducasse

> You probably know the PharoByExample chapter on exceptions, >> but just in case: https://gforge.inria.fr/frs/download.php/26600/PBE2-Exceptions-2010-03-02.p… > > Seems like the right kind of preparation, I will reread it. > I love written documentation. me too :) this is why I write it and I would love to have a chapter on Zinc for the new book :). > Thanks! > > Sven > > >

April 13, 2011