[Packages] Split-Join in development universe etc
Keith Hodges
keith_hodges at yahoo.co.uk
Thu Aug 9 06:33:56 UTC 2007
>
> 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
More information about the Squeak-dev
mailing list
|