Stef,

FWIW, I agree with your path that is making Squeak changes that add values for 
developers and researchers, make a cleaner and stronger foundation (which I 
cannot judge but trust you doing that) - in brief, you guys have my support 
(and thanks for contributing to Squeak and it's community in the past). If it 
turns out that you need a separate version of Squeak, please let me know 
where to find it :)

My only experience with any Smalltalk is using Squeak, mostly playing with 
etoys, and I only play in whatever spare time I have, so I realize my opinion 
should not count much, and I cannot comment on many of the changes you are 
introducing, apart from a few things perhaps:

	- introducing a good code completion support is important to me (eCompletion)

	- I like traits, have been reading on them and played (very little)

	- will Chuck be included, if only as underlying inference for code 
completion?

	- A bigger issue: I feel that to gain more support for Squeak is to get more 
funding (direct or indirect) into it. One way of achieving that, is to have 
rich users - banks, insurance companies etc. That is a hard chicken and egg 
problem, as Squeak lacks AFAIK a strong, standard API for database access 
(such as JDBC / level 4 support) which all these "richies" need and require. 
Perhaps a large company not tied up to their ears with Java, like 
HewletPackard could fund such effort and provide additional marketing thrust 
:) .. 

Thanks again for your guys work, past and future,

Milan


On December 9, 2004 07:38 am, stéphane ducasse wrote:
> hi all
>
> I have been discussing with marcus/alex and also thinking about that
> after my remarks on andreas remarks related to
> changes, interfaces/ cleaning vs changes. So to avoid get frustration
> from all the parts and to state clearly what is our
> plan for 3.9 we would like you to read the following and let us know.
> Depending on the reactions, we (the guys from berne) may decide to
> produce our own stream, because we must work too ;). But we understand
> that other people cannot deal with a system changing. But in that case
> we should draw the consequences.
>
> Our part that we will work on for 3.9 is to get the system improved
> from a developers point of view. We
> think that having a good foundation is important for everybody.
>
> The overall idea is to slowly improve one aspect of Squeak: The idea to
> have a System to build the next
> System with.
>
> This has lots of consquences, one is that you want the system to be in
> a shape that e.g., students that are not yet
> complete Squeak experts can start to do experiments with it on a quite
> deep level, e.g., change the compiler or
> add a feature to the Browser.  Another aspect is to have a System for
> research. The Traits project has been hugely
> successful, but it has shown that Squeak does have real problems if you
> use it for stuff like that. If Squeak is supposed
> to be the system of choice for research like this, we need to fix those
> problems, we need to make sure that the
> lessons learned from those projects get fed back into the system. (One
> example is the change-notification that was added to 3.7, it is a
> direct result of the Traits project)
>
> All this does not mean that 3.9 will only be about that stuff: We
> surely want to see e.g. the work of Diego beeing
> included, also any changes that other people would need are welcome.
>
> For our perspective here what we would like to have: we put in (p) the
> code that  will be in external packages,
> which likely will be "full".
>
> 	- services
> 	- new preferences pane
> 	- OB (p?) + browseUnit new version
> 	- MC in the base image
> 	- rbengine (p)
> 	- shout (p)
> 	- SqueakMap II (yes we want it)
> 	- eCompletion or another package
> 	- keybinding
> 	- traits
> 	- new compiler framework of anthony adapted by marcus to produce
> 	not full block. Note that for Etoy the old compiler will still be in
> the image so from that point of view
> 	it should not have an impact.
> 	- refactoring of systemDictionary. (see below this point)
>
> We are sure that we forgot something but this is what we have on top of
> my head.
>
> Now for systemDictionary here is the situation and here is where we
> would like to be after 3.9
>
> In the past we created SmalltalkImage out of SystemDictionary in the
> hope to have SystemDictionary be a nice
> and simple namespace class. Lot of stuff has been put in coherent
> places (SystemNavigation, SpaceTally, Changeset....)
> But this will not work since people get used to add stuff there and
> Smalltalk is a cool name.
> So the new proposal is the following one and is partly implemented.
> Note however that it will require
> from us a lot of work so if you are against it please say it and we
> will only do it for us.
>
> from a user point of view we want to have:
> 	only one class: SmalltalkImage/SystDict for all the image related
> services
> 	(VM pluggins, ....) but the namespace behavior will be delegated to
> Namespace.
>
>         All the previous code referencing Smalltalk will work but with
> deprecation for the namespace interface.
>
>  From the language programmer point of view:
> 	there will be a namespace that can be used for experimentation
> 	this class will replace the environment class of dan that is now
> obsolete
>
> We plan to proceed that way:
> 	- create a class namespace with a new interface (done)
> 	- delegate from systemDictionary to this new class (done but not
> published)
> 	- deprecate all the namespace method of systemDictionary (but we
> likely want to keep them for some time)
> 	- fix all the in image senders of Smalltalk as a namespace to use the
> new class (using self environment for example).
> 	(partly done over the previous years)
> 	- merge back SmalltalkImage into SystemDictionary: the idea here is to
> not have SystemDict as a subclass of Dictionary
> 	- have Smalltalk pointing to an instance of this new entity, so that
> everybody is happy.
>
>
>
> Stef and Marcus