Yes I have the impression.
Stef
On Jul 29, 2008, at 7:44 PM, David Mitchell wrote:
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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
