On 8/9/07, <b class="gmail_sendername">Keith Hodges</b> <<a href="mailto:keith_hodges@yahoo.co.uk">keith_hodges@yahoo.co.uk</a>> wrote:<div><span class="gmail_quote"></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think it could do if you are ripping things out, since it might become<br>an option for replacing those ripped out things.<br>I would also like to argue for the inclusion of #askFor: as another aid<br>for interacting with items that are optionally present.
</blockquote><div><br><br>And here is what makes me nervous (and maybe others as well): I have read the "Smalltalk Best Practice Patterns" and I try to draw a lot from the code in the image that I feel is elegant and Smalltalk style. And I have not felt this pain of not having a Null object. Maybe I haven't worked with enough different domains yet, or maybe this is something that just doesn't come up that much when coding in Smalltalk style.
<br><br>So if we put this in then maybe someone not fully mentally integrated into the "Smalltalk way" walks in, starts ripping things out all over the place and before you know it we have Objective-C with a little mouse at the top.
<br><br>I don't see a problem with there being a NullObject package out there for people who do need it, or just want to use it in their code. But why does this need to be in the main image? You are talking about ripping things out of the core and replacing it with this, but keep in mind some of the people who have worked on this code. They apparently didn't see the need so we shouldn't be so quick to just assume they didn't know what they were doing. That's not to say that what they did can never be replaced, but it just takes more thought IMO then simply making a new package out there that people can "opt in".
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Just a little dig at the process that has continued to demonstrate that<br>
democracy doesn't seem to work in terms of pushing innovations, but<br>appears to favour the status quo</blockquote><div><br><br>Begging your pardon, but isn't pronouncing something you happen to like as an "innovation" a bit presumptuous? :)
<br><br>Innovations have and do happen in Squeak. But to get people on your side you have to prove it's worth the risk. Make an image with your Null object and replace the things you think should be replaced and then come back and show how it runs faster/is less code/is easier to maintain/whatever and maybe people will start getting on board.
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As a suggestion for 3.11+ my proposal is to provide the tool for users<br>
to specify, packages, fixes/changesets, removals. With such a tool, we<br>ask community members to lay out their own road maps of items they would<br>like to see in the release. For example: kernel-events-logging-solution,
<br>kernel-streams-replaced-with-nile, nile-streams-backward-compatibility,<br>openGL-rendering, exupery -support, morphic3, system-editor,<br>atomic-monticello etc etc.<br><br>This encourages forks of 3.10 as each person can design their own idea
<br>of 3.11p (p for personal) and in their working environment develop the<br>pieces that they wish to contribute.<br><br>Ralph and Edgar really didn't like this multiple-forks idea, however the<br>point I think that was missed is, that if all the forks and pieces of
<br>fork are defined in the same build tool, then they can be designed with<br>integration in mind. The aim of forking is not to go off to develop your<br>own squeak, but to be able to manage your branch of innovation in such a
<br>way as to be able to contribute it back into the main stream in the mid<br>to long term, and to have it potentially visible, and potentially<br>programmed into the release schedule (via the unstable branch) so that<br>
others in their personal-unstable-build-based-branches can integrate<br>their pieces with yours.<br><br>I tried using a wiki for this tool in order to promote collaborative<br>working, but people did not seem to take to the idea. So instead I
<br>propose using a monticello package(s) to specify the parts/dependencies<br>and the build processes. Doing it this way gives us the versioning, and<br>merging tools of monticello to collaboratively design the release build
<br>processes.<br><br>Then we collate a 3.11a, from the contributed roadmap ideas, into a<br>stable and an unstable build process, and individually we can work on<br>the pieces, until each piece is in a state that is ready to move from
<br>the unstable build into the stable build. Pieces that are not yet ready<br>at the end of a given release-time-box, can simply be passed into the<br>next release unstable build process. When the relase-time-box is<br>completed for a release
3.11a-stable gets nominated as 3.11b, and only<br>bug fixes are accepted. Meanwhile 3.12a begins adopting the unused<br>pieces from the 3.11a-unstable branch into a revised roadmap definition.<br><br>Thus bug-fix integration becomes just one piece of the process, rather
<br>than consuming the whole effort as it seems to now. This piece can be<br>delegated to part of the team, while there are other proactive projects<br>are in progress.<br><br>just a few of my thoughts, and at the moment I have no time to work on
<br>this for at least a month.<br><br>best regards<br><br>Keith</blockquote><div><br><br>I'm a little bit confused by all this. Why does it need to be 3.11 images? What is wrong with Damien's approach of "value add" prepackaged images?
<br></div><br></div>