<br><br><div class="gmail_quote">On Tue, Apr 8, 2008 at 2:01 PM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2008/4/8 Michael van der Gulik <<a href="mailto:mikevdg@gmail.com">mikevdg@gmail.com</a>>:<br>
<div class="Ih2E3d">><br>
><br>
><br>
> On Tue, Apr 8, 2008 at 11:19 AM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br>
> ><br>
> ><br>
> > I'm aware of at least two of module-based solutions for Squeak:<br>
> > - Spoon by Craig Latta<br>
> > - Namespaces by Michael van Der Gulik , as part of his SecureSqueak<br>
> project<br>
> ><br>
> > Both systems currently in development. And almost 99% it is solo<br>
> > development by their authors.<br>
</div>> > Both systems having own pros and cons , and it's hard to decide (as<br>
> > for me), which is better for the future of Squeak.<br>
><br>
><br>
> FWIW, "SecureSqueak" isn't going to be the future of Squeak; it's going to<br>
> be a fork. It's going to be too different from Squeak to be a good candidate<br>
> for a future version.<br>
><br>
<br>
Yes, if you read my latest post in this thread about forks. Isn't it<br>
would be better to make fork become Squeak in that way? ;)<br>
I don't want to repeat myself, but do you think it wouldn't be better<br>
to incorporate module-based system in Squeak release?<br>
Because if not, then obviously Squeak community will be forked as<br>
well. Is there a way to put stop on this? Can we make a system which<br>
will make need of forking unnecessary?<br>
<font color="#888888"><br>
</font></blockquote><div><br><br>I think DeltaStreams has a lot of potential to keep the various forks of Squeak together. At some stage I'll investigate whether it can be integrated into Namespaces. If this works well, it would be the best way to share bug fixes with each other.<br>
<br>I also think that forking the community should be encouraged. The "<a href="http://squeak.org">squeak.org</a> image" should be a minimal lowest-common-denominator image, which others take and, by adding packages, make into a variety of images for various uses, such as Squeak-Dev or FunSqueak. For now, MC does an adequate job[1].<br>
<br>One of the reasons that it is unlikely that my Namespaces implementation will be able to be part of the <a href="http://squeak.org">squeak.org</a> image is because I plan to do away with the "Smalltalk" SystemDictionary and reorganise everything into individual, live Packages, each containing hierarchies of Namespaces and Classes. The community here would never agree to such a radical change.<br>
<br>[1] You currently can't load my NamespaceTools package from the package universe browser because MC has trouble redefining instance variables in some of the ToolBuilder packages. It works if you recompile several classes.<br>
<br></div></div>Gulik.<br clear="all"><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">http://people.squeakfoundation.org/person/mikevdg</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a>