I want this class builder :) On Apr 14, 2011, at 10:33 AM, Toon Verwaest 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 ;) > > 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 ... >> >> > >
