[Packages] Split-Join in development universe etc

Jason Johnson jason.johnson.081 at gmail.com
Thu Aug 9 05:17:06 UTC 2007


On 8/8/07, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
>
>
> > I was under the impression that now is the best time ever to get
> > needed things into the image.  The "Message eating null" and
> > namespaces are big controversial things that can't be ignored once
> > present.
> But in actual fact in these two cases they CAN be ignored once present.



Of course they can't.  We put things in to be used, so once these two things
are in people will start using them and then everyone else will run into it
while working in the image.

However I happen to think that it would be useful if they were present,
> Null in particular.
>
> For example I use Object-#log as a handle to a ProcessLocalLog instance
> which plugs in to the logging technology of your choice (toothpick
> /simple log etc). In moving towards the kernel image ideal, all of the
> Transcript stuff in the core could be ripped out and use "self log
> kernel: message" instead, the base implementation of which can return
> Null if no logging package is loaded.



And after suggesting we can just ignore these classes, here comes a
suggestion to start using it in Object! :)  That's not a bad idea about
logging, but in this case I think about what other places do.  In Pier you
can have persistence, or you can turn it off by setting NullPersistence.
That is, of course, a "message eating null" class but it is explicit.  If
they replaced that with "Null", then things get a little les clear, no?

I'm not yet convinced that this comes up enough to be a kernel class.  Of
course one can always code in ways to *make* something come up a lot, but
with current usage I can think of about 3 places in the whole image it comes
up, and each is made more clear imo by having an explicit class.

As an excercise I think that it is interesting that if you cant get two
> or three methods of the importance and usefullness of split and join
> into the image (and btw unless I am mistaken there is no existing idiom
> for split) then you cant get anything in there, unless of course you
> happen to be the one in charge.
>
> cheers
>
> Keith
>


No need to take it personal, the jury is still out on these things (even the
join/split that I thought most people would like).  But saying "oh just put
it in, you can totally ignore it once it's in!" is definitely not the way to
get votes imo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070809/64984ff0/attachment.htm


More information about the Squeak-dev mailing list