>
> And after suggesting we can just ignore these classes, here comes a 
> suggestion to start using it in Object! :) 
fair point. :-)

> 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?
In this particular case, it is not appropriate to use Null instead of 
NullPersistence, because NullPersistence still does something, well a 
lot of things actually. It is not a true Null, its a 'manage your data 
but in the image only'  provides the default 'manage your data' 
implementation for many functions. When using the 
Pier-PersistencyManager to switch between persistency schemes, switching 
from PRMagmaPersistency to PRNullPersistency requires actions to pull 
the data in from the db into memory in order for NullPersistency to be 
selected. In some cases the PRNullPersistency simply reflects back 
double dispatch ed requests, whereas its subclasses do something (see 
#realizeKernel). PRNullPersistency way of "doing nothing" is to Null's 
way of "doing nothing", as a Mirror is in comparison to a Black Hole, 
they just dont work the same way.

If we do it the other way around, and implement a "clear", "specific" 
NullLogger class, then we have added a class to the image that has only 
one use. The next requirement for a Null class has no choice but to 
implement its own bespoke solution. If we use Null as the NullLogger 
then, we have a choice.
> I'm not yet convinced that this comes up enough to be a kernel class.
I think it could do if you are ripping things out, since it might become 
an option for replacing those ripped out things.
I would also like to argue for the inclusion of #askFor: as another aid 
for interacting with items that are optionally present.
> 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.
>
>     for split) then you cant get anything in there, unless of course you
>     happen to be the one in charge.
>
Just a little dig at the process that has continued to demonstrate that 
democracy doesn't seem to work in terms of pushing innovations, but 
appears to favour the status quo
> No need to take it personal.
As a suggestion for 3.11+ my proposal is to provide the tool for users 
to specify, packages, fixes/changesets, removals. With such a tool, we 
ask community members to lay out their own road maps of items they would 
like to see in the release. For example: kernel-events-logging-solution, 
kernel-streams-replaced-with-nile, nile-streams-backward-compatibility, 
openGL-rendering, exupery -support, morphic3, system-editor, 
atomic-monticello etc etc.

This encourages forks of 3.10 as each person can design their own idea 
of 3.11p (p for personal) and in their working environment develop the 
pieces that they wish to contribute.

Ralph and Edgar really didn't like this multiple-forks idea, however the 
point I think that was missed is, that if all the forks and pieces of 
fork are defined in the same build tool, then they can be designed with 
integration in mind. The aim of forking is not to go off to develop your 
own squeak, but to be able to manage your branch of innovation in such a 
way as to be able to contribute it back into the main stream in the mid 
to long term, and to have it potentially visible, and potentially 
programmed into the release schedule (via the unstable branch) so that 
others in their personal-unstable-build-based-branches can integrate 
their pieces with yours.

I tried using a wiki for this tool in order to promote collaborative 
working, but people did not seem to take to the idea. So instead I 
propose using a monticello package(s) to specify the parts/dependencies 
and the build processes. Doing it this way gives us the versioning, and 
merging tools of monticello to collaboratively design the release build 
processes.

Then we collate a 3.11a, from the contributed roadmap ideas, into a 
stable and an unstable build process, and individually we can work on 
the pieces, until each piece is in a state that is ready to move from 
the unstable build into the stable build. Pieces that are not yet ready 
at the end of a given release-time-box, can simply be passed into the 
next release unstable build process. When the relase-time-box is 
completed for a release 3.11a-stable gets nominated as 3.11b, and only 
bug fixes are accepted. Meanwhile 3.12a begins adopting the unused 
pieces from the 3.11a-unstable branch into a revised roadmap definition.

Thus bug-fix integration becomes just one piece of the process, rather 
than consuming the whole effort as it seems to now. This piece can be 
delegated to part of the team, while there are other proactive projects 
are in progress.

just a few of my thoughts, and at the moment I have no time to work on 
this for at least a month.

best regards

Keith