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.
I understand
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...
Can you elaborate on that one?
Because indeed having a good dependency mechanism is really important.
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
