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
