- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 4009 in pharo: DNU on opening inspector with enabled taskbar

by pharo＠googlecode.com

Updates: Status: Duplicate Mergedinto: 4008 Comment #1 on issue 4009 by marcus.d...(a)gmail.com: DNU on opening inspector with enabled taskbar http://code.google.com/p/pharo/issues/detail?id=4009 (No comment was entered for this change.)

April 14, 2011

Re: [Pharo-project] isHealthy

by StÃ©phane Ducasse

I do not know. This is in RPackage and I do not know what to do. >> Hi igor >> >> this is strange I have a dictionary whose array contains nil and still isHealthy returns true. >> can an array of a dictionary contains nil? > > no, it can't . > And how you end up with dictionary which having array = nil? During > initialization, it allocates and initializes array, > so, normally, there is no way how it could be nil.

April 14, 2011

Re: [Pharo-project] Issue 4008 in pharo: DNU on opening inspector with enabled taskbar

by pharo＠googlecode.com

Comment #1 on issue 4008 by marcus.d...(a)gmail.com: DNU on opening inspector with enabled taskbar http://code.google.com/p/pharo/issues/detail?id=4008 Issue 4009 has been merged into this issue.

April 14, 2011

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

by Toon Verwaest

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 ;) 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 ... > >

April 14, 2011

[Pharo-project] Issue 4011 in pharo: Finder: self is not bound to class

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 4011 by marcus.d...(a)gmail.com: Finder: self is not bound to class http://code.google.com/p/pharo/issues/detail?id=4011 search for browseObsoleteReferences "self new browseObsoleteReferences" try to execute it --> DNU. Works in the browser.

April 14, 2011

[Pharo-project] Issue 4010 in pharo: References to it nor working in Inspector

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 4010 by marcus.d...(a)gmail.com: References to it nor working in Inspector http://code.google.com/p/pharo/issues/detail?id=4010 select a class name, do CMD-shift-N --> DNU Inspector #selectedClassOrMetaClass

April 14, 2011

[Pharo-project] Issue 4009 in pharo: DNU on opening inspector with enabled taskbar

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 4009 by marcus.d...(a)gmail.com: DNU on opening inspector with enabled taskbar http://code.google.com/p/pharo/issues/detail?id=4009 Inspector does not understand #theme taskbarIcon ^ self theme smallInspectItIcon

April 14, 2011

Re: [Pharo-project] isHealthy

by Henrik Sperre Johansen

On 14.04.2011 10:09, Igor Stasenko wrote: > On 13 April 2011 16:49, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: >> Hi igor >> >> this is strange I have a dictionary whose array contains nil and still isHealthy returns true. >> can an array of a dictionary contains nil? >> > no, it can't . > And how you end up with dictionary which having array = nil? During > initialization, it allocates and initializes array, > so, normally, there is no way how it could be nil. Ehm, the array can _contain_ nil(the empty slot marker) (and it will in all cases, if it's working correctly), it cannot _be_ nil though. isHealthy has nothing to do with this though, it checks if all elements (non-nil entries in the array) are at positions which are valid. Cheers, Henry

April 14, 2011

[Pharo-project] Issue 4008 in pharo: DNU on opening inspector with enabled taskbar

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 4008 by marcus.d...(a)gmail.com: DNU on opening inspector with enabled taskbar http://code.google.com/p/pharo/issues/detail?id=4008 Inspector does not understand #theme taskbarIcon ^ self theme smallInspectItIcon

April 14, 2011

[Pharo-project] Issue 4007 in pharo: Taskbar disappeared

by pharo＠googlecode.com

Status: FixProposed Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 4007 by marcus.d...(a)gmail.com: Taskbar disappeared http://code.google.com/p/pharo/issues/detail?id=4007 Needs a World showWorldTaskbar: true

April 14, 2011