I like message eating nulls in some situations. It would be nice if each framework didn't have to provide their own.
I wouldn't go so far as to switch nil to act like null, but making null available as a design choice as part of the base system is a good idea. On Tue, Jul 29, 2008 at 8:32 AM, Keith Hodges <[EMAIL PROTECTED]> wrote: > Stéphane Ducasse wrote: >> >> On Jul 29, 2008, at 10:10 AM, Damien Cassou wrote: >> >>> On Mon, Jul 28, 2008 at 9:26 PM, Keith Hodges <[EMAIL PROTECTED]> >>> wrote: >>>>> >>>>> I was thinking that we could check a bit rio interface to see if we >>>>> could >>>>> use it as a scaffold >>>>> and slowly rewrite it so that at the end it is a not a wrapper anymore >>>>> on >>>>> that shit. >>>> >>>> Rio is not a wrapper and never has been, it is independant of >>>> FileDirectory >>>> always was and always will be >>> >>> Rio is a *must* have for Pharo. >> >> Ok can you check the NullPattern. >> Because I have a voice iside that tells me that I do not want it to creep >> in the image. > > I think you are just being chicken. ;-) > > The Null pattern is very useful in certain situations, particularly as a > null Logger in the Logging framework, and in higher level domain modelling. > > Now that we are entering an era in which we are attempting to remove chunks > of the base image, null comes into its own. As mentioned above it makes a > great Null logger for a minimal image when even the Logging interface itself > has been removed. > > It should be part of the base image because it needs to be supported well > within a particular Smalltalk implementation because it has the potential to > make the image unstable if implemented badly. Every Smalltalk I have used it > in so far has needed me to stoop to the lower level coding to write and > rewrite Null extensively so that it works properly. This should not be > necessary for higher level domain modelling work. I think that it should be > supported well out of the box. > > There is nothing wrong with null, it is a legitimate part of the tool bag we > have as smalltalk developers. Not putting it in the base image serves to > provide a psychological block to using it in situations where it would be > appropriate, and as I have pointed out there are some. > > For example in Rio it performs a very small role, but this makes code much > more readable, and handles errors gracefully. The power to weight ratio of > null is high, another reason it should be available as a resource for > tidying up the kernel. > > Another item that is needed for domain modelling and I think should be in > the base image is a dependency mechanism, SmalltalkAgents had a fairly good > one. Announcements has some good ideas but is fundamentally flawed... >> >> So we could fork rio and provide an implementation that is not based on >> the null pattern >> > Its not based upon the null pattern, the null provides one idiom. That of > returning "null" if it fails to obtain a valid read or writeStream. This > enables readable code for writing to files without having to error check all > over the place. It can tidy up a fair bit of code. > > As an alternative you could return nil, and implement UndefinedObject>>#use: > aBlock ^self > This should catch most of the places where null's behaviour is used, i.e. > #writer: #reader: and #<< > > best regards > > Keith > > > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
