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

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

by Dale Henrichs

On 04/14/2011 01:33 AM, Toon Verwaest wrote: > Somehow I feel like I offended someone :) Not at all ... I like to wave my arms, talk passionately and draw all over a white board ... all things that are difficult to do in an email:) > > I personally don't have experience with 10'000+ classes in a system. I > do understand that's where you are coming from and do appreciate the > insight. > > My personal experience has rather been the opposite until now. For > example the Pharo/Squeak classbuilder is 1 single class doing > everything. This is horrible; not just horrible because the code is > completely horrid but it's non-extensible, non-configurable, > non-reusable, contains tons of duplication _just because_ it is all put > into one big ball of mud. By decomposing the classbuilder into 4 to 10 > different classes I ended up having very little methods with very little > code, and a very high level of configurability and understandability. I > now actually use this classbuilder to build anonymous classes too, > avoiding the whole problem with forgetting to copy in the format that > everyone seems to have. Monolithic classes are difficult to maintain and hard to extend ... I am whole heartedly in favor of using classes, just take a look at Metacello: ~300 classes including a dozen exception classes. My main message is that it is generally a bad idea to build a framework when one isn't needed. One shouldn't be shy about creating multiple classes to do a job, when they are called for. On the other hand, one shouldn't create a framework of classes until such a frame work is called for. For the Exception framework I think the following guidelines should apply: 1. Each unique error _should_ be uniquely identified and the current mechanism of providing a string argument to the #error: message is not sufficient. 2. Specific handlers will not be written for most errors, so it isn't absolutely necessary to create a unique exception class for all errors 3. If specific handlers exist (doing string parsing now) or there is a reasonable case made that specific handlers are likely to written, then a unique exception class should be created. 4. reasonCodes (within the namespace of an exception class or subhierarcy) can be used to uniquely identify an error condition, when a unique class isn't called for. 5. In the fullness of time, if a case is found where a reasonCode should be turned into a unique exception class, then the class should be created. These guidelines should help keep the Exception hierarchy as small as is needed, but allow expansion as well. Keep in mind that the primary purpose of the Exception is to allow code to be written that automates the handling of the exception. Developers don't need Exceptions to debug/develop applications ... the debugger provides all of the information that a developer needs ...So the exception is there when a developer cannot look at the stack and must write code to report the error to a log, an end user, or take corrective action .... for an error report, the exception class and reasonCode is sufficient information for a developer to go back to the code and determine the call site ... > > And this experience was showing me that having classes for all > _relevant_ concepts actually pays off in the long run. Since you (and > others) are saying that it doesn't for exceptions; and since I don't > have enough experience there I'll take your advice into account when > writing code ;) Agreed 100% ... we all have to use judgment when writing our code, so having a little more information never hurts (unless you're wacked by a waving arm:)... Dale

April 14, 2011

Re: [Pharo-project] Issue 3984 in pharo: Announcements announced when a test is runned

by pharo＠googlecode.com

Comment #6 on issue 3984 by Benjamin...(a)gmail.com: Announcements announced when a test is runned http://code.google.com/p/pharo/issues/detail?id=3984 A little fix in addition of the previous one Attachments: FixTestCaseAnnouncement.1.cs 974 bytes

April 14, 2011

Re: [Pharo-project] Issue 3984 in pharo: Announcements announced when a test is runned

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #5 on issue 3984 by Benjamin...(a)gmail.com: Announcements announced when a test is runned http://code.google.com/p/pharo/issues/detail?id=3984 A new version of announcements for TestCase The first one can be forgotten Attachments: TestCaseAnnouncements.1.cs 3.6 KB

April 14, 2011

Re: [Pharo-project] Issue 4016 in pharo: Monticello Announcements

by pharo＠googlecode.com

Comment #2 on issue 4016 by Benjamin...(a)gmail.com: Monticello Announcements http://code.google.com/p/pharo/issues/detail?id=4016 What do you mean by context ? A new cs with a new announcer, you can take only this one and ignore the first one Attachments: MonticelloAnnouncements2.1.cs 3.3 KB

April 14, 2011

Re: [Pharo-project] [Pharo-users] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk â Contributors

by Adrian Lienhard

I think the most important thing is to make all pictures the same width and height. Then I wouldn't do a table, but rather add filters. For instance, this would allow the visitor to filter for people by country and possibly other properties (like university, industry, ...). Another improvement would be to print the names as a heading (they are just normal text now). If somebody likes to help with this, pls contact me. Adrian On Apr 14, 2011, at 16:42 , laurent laffont wrote: > On Thu, Apr 14, 2011 at 4:29 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Thu, Apr 14, 2011 at 4:26 PM, Serge Stinckwich < >> serge.stinckwich(a)gmail.com> wrote: >> >>> I think it's a great idea to have a picture and short description. >>> Maybe we could have something more uniform with the same size for each >>> picture ? >>> >> >> Yes sure, and maybe put a kind of table were each of us is a row, and all >> data is one column and the picture is another one. So they are aligned. >> > > We should just adapt the CSS. I don't know how to modify it in CMSBox. > > Laurent > > > >> But first the first :) Get the contributors and then we take care about >> the make up ehehe >> >> Laurent may be able to take care about the makeup ? >> > >> Cheers >> >> Mariano >> >> >>> Regards, >>> >>> On Thu, Apr 14, 2011 at 8:46 PM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com> wrote: >>>> if true...then what are you wainting for? >>>> >>>> http://www.pharo-project.org/community/contributors >>>> >>>> Send you data and nice picture :) >>>> >>>> Seriously, it is important for marketing among other things. Imagine you >>>> arrive to a new project...it is good to see that there are several >>>> contributing to it. Probably this page is not the best, but is something >>>> more. >>>> >>>> Mariano >>>> >>>> >>>> >>>> On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont < >>> laurent.laffont(a)gmail.com> >>>> wrote: >>>>> >>>>> Added ! >>>>> Laurent. >>>>> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich <juan(a)jvuletich.org> >>> wrote: >>>>>> >>>>>> Hi Laurent, >>>>>> >>>>>> I'd like to be added to >>>>>> http://www.pharo-project.org/community/contributors . My picture is >>>>>> attached. Description text could be "Contributed the default >>> anti-aliased >>>>>> fonts and the SimpleMorphic UI framework. Web page at >>> www.jvuletich.org". >>>>>> >>>>>> Thank you. >>>>>> >>>>>> Cheers, >>>>>> Juan Vuletich >>>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>> >>> >>> >>> -- >>> Serge Stinckwich >>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >>> Every DSL ends up being Smalltalk >>> http://doesnotunderstand.org/ >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >>

April 14, 2011

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

by Michael Haupt

Hi, On 14 April 2011 16:40, Norbert Hartl <norbert(a)hartl.name> wrote: >> But we're probably rather off-topic by now. ;-) > > No, the subject is "Meanwhile, at another vm". Quite flexible and welcoming to all sorts of discussions :) all right then. Here we go. :-D Best, Michael

April 14, 2011

Re: [Pharo-project] [Pharo-users] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk â Contributors

by laurent laffont

On Thu, Apr 14, 2011 at 4:29 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Thu, Apr 14, 2011 at 4:26 PM, Serge Stinckwich < > serge.stinckwich(a)gmail.com> wrote: > >> I think it's a great idea to have a picture and short description. >> Maybe we could have something more uniform with the same size for each >> picture ? >> > > Yes sure, and maybe put a kind of table were each of us is a row, and all > data is one column and the picture is another one. So they are aligned. > We should just adapt the CSS. I don't know how to modify it in CMSBox. Laurent > But first the first :) Get the contributors and then we take care about > the make up ehehe > > Laurent may be able to take care about the makeup ? > > Cheers > > Mariano > > >> Regards, >> >> On Thu, Apr 14, 2011 at 8:46 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >> > if true...then what are you wainting for? >> > >> > http://www.pharo-project.org/community/contributors >> > >> > Send you data and nice picture :) >> > >> > Seriously, it is important for marketing among other things. Imagine you >> > arrive to a new project...it is good to see that there are several >> > contributing to it. Probably this page is not the best, but is something >> > more. >> > >> > Mariano >> > >> > >> > >> > On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont < >> laurent.laffont(a)gmail.com> >> > wrote: >> >> >> >> Added ! >> >> Laurent. >> >> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich <juan(a)jvuletich.org> >> wrote: >> >>> >> >>> Hi Laurent, >> >>> >> >>> I'd like to be added to >> >>> http://www.pharo-project.org/community/contributors . My picture is >> >>> attached. Description text could be "Contributed the default >> anti-aliased >> >>> fonts and the SimpleMorphic UI framework. Web page at >> www.jvuletich.org". >> >>> >> >>> Thank you. >> >>> >> >>> Cheers, >> >>> Juan Vuletich >> >> >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > >> >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Every DSL ends up being Smalltalk >> http://doesnotunderstand.org/ >> > > > > -- > Mariano > http://marianopeck.wordpress.com > >

April 14, 2011

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

by Norbert Hartl

Am 14.04.2011 um 16:29 schrieb Michael Haupt: > But we're probably rather off-topic by now. ;-) No, the subject is "Meanwhile, at another vm". Quite flexible and welcoming to all sorts of discussions :) Norbert

April 14, 2011

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

by Hernan Wilkinson

On Thu, Apr 14, 2011 at 5:33 AM, Toon Verwaest <toon.verwaest(a)gmail.com>wrote: > Somehow I feel like I offended someone :) > > I personally don't have experience with 10'000+ classes in a system. I do > understand that's where you are coming from and do appreciate the insight. > > My personal experience has rather been the opposite until now. For example > the Pharo/Squeak classbuilder is 1 single class doing everything. This is > horrible; not just horrible because the code is completely horrid but it's > non-extensible, non-configurable, non-reusable, contains tons of duplication > _just because_ it is all put into one big ball of mud. By decomposing the > classbuilder into 4 to 10 different classes I ended up having very little > methods with very little code, and a very high level of configurability and > understandability. I now actually use this classbuilder to build anonymous > classes too, avoiding the whole problem with forgetting to copy in the > format that everyone seems to have. > > And this experience was showing me that having classes for all _relevant_ > concepts actually pays off in the long run. Since you (and others) are > saying that it doesn't for exceptions; and since I don't have enough > experience there I'll take your advice into account when writing code ;) > I think you said it right here: "having classes for all _relevant_ concepts actually pays off"... Related to exceptions, my question is: what are all the different concepts you have? for example, not finding a Key or not finding a Value are really different concepts? or is it the same (not finding something) that depending on the context (finding a value or a key) is what looks like they are different? if so, then there is only one concept (i.e. not finding an object), if it is a key or a value is accidental, contextual to what you are looking for. So, I completely agree when you say "having classes for all relevant concepts"... I think we do not agree on what are the relevant concepts when we talk about exceptions... > > Toon > > > On 04/14/2011 01:00 AM, Dale Henrichs wrote: > >> On 04/13/2011 02:58 PM, Toon Verwaest wrote: >> >>> Is it such a problem if you duplicate a certain exception class? At the >>> moment you'll do the same anyway by not completely writing the exact >>> same symbol. >>> >> >> It's a simple matter of namespaces and volume of names ... with a large >> open ended namespace you are more likely to have a number of redundant names >> with slight differences in spelling showing up in different spots in the >> hierarchy...with a logically segmented namespace each segment will have a >> manageable number of names and the risk of duplication is reduced ... end of >> discussion ... >> >> 10,000 names vs 30 names ... I can easily recognize duplicates in a list >> of 30 names ... not so easy in 10,000 ... that is all ... >> >> to attempt to map every possible error condition onto a class will lead >> you to 10,000 much quicker than using reasonCodes ... that is all ... >> >> I don't hate classes, it is a _practical_ matter ... if _you_ would rather >> manage 10,000 names then I will say that it isn't practical ... I'm _not_ >> saying it is _wrong_, just not _practical_. >> >> >>> And if the problem is not finding classes anymore, maybe we need a >>> better way of organizing the exception classes away from the standard >>> classes so that they are as non-intrusive as symbols, but convey more >>> information? >>> >> >> And now you've hit the nail on the head ... in order to handle the extra >> complexity you need additional tools ... before creating more tools, ask >> your self the simple question: "Do I _need_ the additional complexity?" ... >> if the answer is yes, then create the tool, if the answer is no, then you >> don't need to create a new tool .. >> >> Again, this is a _practical_ matter... >> >> >>> self error: #keyNotFound >>> does not really give much information; and isn't much more difficult to >>> write than: >>> KeyNotFoundException new in: self; key: key; signal >>> >> >> From a practical perspective how many exception handlers will be written >> to handle KeyNotFoundException ... I use at:ifAbsent: when I'm doing a look >> up that I think might fail ... better than writing an exception handler ... >> >> If there is a real need to write a handler for KeyNotFoundException, then >> by all means create the class, but until you actually NEED >> KeyNotFoundException, `self error: #keyNotFound` or `NotFoundException >> signal: #keyNotFound` will work just fine... >> >>> >>> although the second one gives you all the contextual information that >>> the first one misses. >>> >> >> _If_ you NEED the additional contextual information. It's just like >> writing a framework that no uses ... there's nothing wrong with the idea or >> the implementation, it's just that the framework didn't solve a problem that >> anyone had... >> >> If you are going to create a class, I think the least it should do is >> address an real problem, not an imaginary one. >> >> To say that "if one were to handle the KeyNotFoundException, they will >> need the complete context", I prefer to say "Until one needs the complete >> context of the KeyNotFoundException, don't bother creating class" >> >> >>> What I mean mostly: what about trying to figure out why you want to >>> avoid decent exception classes and tackling that problem? >>> >> >> Depends upon what your definition of a decent exception classes is? My >> argument is simply that it is not _necessary_ to create a unique class for >> every unique error condition ... I think that folks should answer the >> question: "Will anyone every write an exception handler for this exception" >> before creating the class ... if the answer is yes (or better yet, I am >> writing code right now and need that exception) then by all means create the >> class. >> >> Maybe we don't want classes but exception objects that can pool data >>> together? Maybe a very silly idea: what about just exception "classes" >>> that have dictionaries to store enough information? >>> >> >> That would be another way of doing things ... although using exception >> classes and reasonCodes is pretty close to all that is needed... >> >> I agree with the notion that it isn't that useful to have a single Error >> class and have all errors mapped to it ... on the other hand I don't think >> it is particularly useful to have an exception class for every possible >> error condition ... the compromise is to provide a smallish hierarchy of >> excpetion classes with fairly general structure, provide a means for >> uniquely identifying every possible error condition (I think that is >> important) and then add new classes to the hierarchy when a demand for the >> class is found ... >> >> >> > > -- *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 14, 2011

Re: [Pharo-project] Issue 4022 in pharo: Symbol readFrom:

by pharo＠googlecode.com

Updates: Labels: Importance-High Comment #1 on issue 4022 by Benjamin...(a)gmail.com: Symbol readFrom: http://code.google.com/p/pharo/issues/detail?id=4022 (No comment was entered for this change.)

April 14, 2011