Two important issues...

Daniel Vainsencher danielv at netvision.net.il
Sat Feb 15 13:37:49 UTC 2003


In theory, which is the best anyone can tell you in advance, I think
Traits could be wonderful for Squeak. In practice, it's a relationship,
not a sale. 

I read somewhere that we fall in love with what we hope the other is,
then get stuck with who they really are. I for one, love the Bern group
for what it really is - a bunch of guys producing wonderful ideas for
Smalltalk, that sometimes carry over to Squeak (like SB). I don't really
expect you to forever do all your research in Squeak, though it would
make me happy.

I hope you decide to continue your work in Squeak, and with your eyes
open...

Daniel

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> Hi
> 
> I think that there is two issues:
> 	- First do the community wants traits?
> 	- How the community assess it?
> 	-> I guess by trying and building up confidence
> 
> 	- Now our personal plans are to continue to extend the model in a 
> backward
> 	compatible way. However this does not means that Squeak has to have 
> the second
> 	model may be Squeak only wants the version1. But this is not a problem 
> because v2 includes
> 	v1 in a transparent way if we do not use the features of v2.
> 
> 	- In all cases we need a stabler Parser, cleaner AST, ClassBuilder, 
> and BROWSER
> 	So we will see if we can get some momentum and synergy with SqScript, 
> in such a case
> 	we will see if we sue SmaCC, redo ClassBuilder. Else we may end up 
> moving to another 	Smalltalk. We will take our decision next week.
> 
> 	So to summarize this is not our decision to know whether Traits should 
> be included
> 	this is the people that should shout for it and build a consensus.
> 	In any case, if this would happen we would put the resources to 
> provide a stable version
> 	of traits for Squeak.
> 
> 
> Stef
> 
> 
> 
> 
> On Friday, February 14, 2003, at 06:23 PM, Daniel Vainsencher wrote:
> 
> > Hi Nathanael,
> >
> > Let see if I got this right -
> > * Right now it can't be integrated, because file out is a pretty
> > important part of such a facility (even fixable glitches with filing in
> > in 3.3a modules were a big cause for strife).
> > * You're going to create a v2, maybe in Squeak maybe not. Maybe we'll
> > know next week.
> >
> > Conclusion - the best thing for people that want to see Traits in 
> > Squeak
> > to do is to try the demo out, give feedback, and cross their fingers.
> > True? anything else that could help?
> >
> > Just want to clarify where we stand - it doesn't seems like you're
> > either ready or aiming for immidiate inclusion...
> >
> > Daniel
> >
> > =?iso-8859-1?Q?Nathanael_Sch=E4rli?= <n.schaerli at gmx.net> wrote:
> >> Goran,
> >>
> >>> Personally I do think it could be placed in core. It seems to
> >>> be such an elegant extension solving a lot of problems. But
> >>> some people probably wants Squeak to stay as a "Smalltalk
> >>> clone" and be as compatible with other Smalltalks as
> >>> possible. Well, I am not one of them - but it will be
> >>> interesting to see the discussion unfold.
> >>
> >> I think that this is quite a fundamental question. Since traits are 
> >> only
> >> available as a more or less stable prototype version at the moment, we
> >> don't have to take a decision right now, but it never hurts to talk
> >> about it in advance.
> >>
> >> I also think that it would be helpful for you to know our future 
> >> (Stef,
> >> Roel, Alex and me) plans regarding traits. So here they are:
> >>
> >> - As I said before, the current model of traits is just a first step. 
> >> We
> >> have very concrete and exciting ideas of a second version of the model
> >> that is much more powerful than what we have now. Because we want to
> >> validate this new model in practice, we are definitely going to
> >> implement it on top of Squeak, SqueakScript or possibly another
> >> Smalltalk implementation. At the end of next week, Andreas Raab is
> >> visiting our lab, and then we will talk with him and take a decision
> >> regarding the platform.
> >>
> >> - Once this is decided, we are going to do a _clean_ implementation of
> >> this extended traits model. Since this new model is a completely
> >> downwards compatible extension of the current model, the new
> >> implementation will also serve as the basis for a clean and stable
> >> implementation of traits as they are now.
> >>
> >> Cheers,
> >> Nathanael
> >>
> >>> -----Original Message-----
> >>> From: squeak-dev-bounces at lists.squeakfoundation.org
> >>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
> >>> Behalf Of goran.hultgren at bluefish.se
> >>> Sent: Freitag, 14. Februar 2003 13:23
> >>> To: Squeak-dev at lists.squeakfoundation.org
> >>> Subject: Two important issues...
> >>>
> >>>
> >>> Hi all!
> >>>
> >>> I thought this list was so "quiet" so I just had to start a
> >>> new thread... :-)
> >>>
> >>> There are two (well, 723 to be exact, but these two are
> >>> interesting) issues we really need to start discussing:
> >>>
> >>> 1. Package grouping/blessing, package ownership, allowed
> >>> dependencies etc.
> >>>
> >>> 2. Traits.
> >>>
> >>> In different threads the last days we have been discussing
> >>> how to prevent chaos when we start tearing the image to
> >>> pieces and putting stuff on SqueakMap instead.
> >>>
> >>> Sidenote: We might want to wait a bit until *really* removing
> >>> packages from the image - at least until SM1.1 is out. There
> >>> are a bunch of good reasons for that.
> >>>
> >>> Issue 1
> >>> ========
> >>>
> >>> ...is about how we should group our packages. Here are a few
> >>> suggestions:
> >>>
> >>> Core packages - these are typically packages currently in the
> >>> base image and they more or less constitute what we like to
> >>> call "Squeak". We will probably have different "rules" for
> >>> how to maintain these - higher standards, cooperative
> >>> ownership etc, what do I know. Packages in core can only
> >>> depend on other packages in core of course.
> >>>
> >>> Extra packages - these are packages not regarded as core but
> >>> nevertheless packages that applications etc tend to rely on.
> >>> They are typically personally owned and maintained but the
> >>> maintainer is aware of the fact that the package is important
> >>> to many others. But they aren't core - so some relaxation
> >>> exist. Packages here can depend on both packages in core and in 
> >>> Extra.
> >>>
> >>> Core replacements - these are packages that can not coexist
> >>> with one or more packages in core. A Morphic replacement
> >>> would typically be here. Depending on one of these packages
> >>> is obviously quite risky and would greatly increase the risk
> >>> of conflicts with other packages. Experimental rewrites of
> >>> core packages will live here until they can actually step
> >>> into core and replace the old packages. Packages here can
> >>> depend on both packages in core and in Core replacements. But
> >>> when moved into core they can of course only depend on
> >>> packages in core.
> >>>
> >>> Normal packages - well, the rest. :-) Here we have all the
> >>> applications, tools, you name it. They can depend on packages
> >>> in all other groups. Depending on packages in Core
> >>> replacements is on the other hand a pretty dicy thing of course.
> >>>
> >>> Ok, that probably got your brains in gear... This is a very
> >>> important question for us to sort out. Implementation is on
> >>> the other hand very easy - we simply add a few categories on
> >>> SM for grouping. So, shoot.
> >>>
> >>>
> >>> Issue 2
> >>> ========
> >>>
> >>> Issue 2 is somewhat peripherally connected to the above.
> >>> Traits is standing outside our pretty little Smalltalk-80
> >>> descendant house and is knocking on the door. What does this
> >>> mean? If Traits was a package - where should we put it? In
> >>> core? Ok, that would essentially mean that Squeak is taking a
> >>> step away from Smalltalk. Squeak simply isn't a "Smalltalk-80
> >>> clone" anymore. And the argument that Traits is optional to
> >>> use doesn't hold - people *will* use it and that will change *a lot*.
> >>>
> >>> Personally I do think it could be placed in core. It seems to
> >>> be such an elegant extension solving a lot of problems. But
> >>> some people probably wants Squeak to stay as a "Smalltalk
> >>> clone" and be as compatible with other Smalltalks as
> >>> possible. Well, I am not one of them - but it will be
> >>> interesting to see the discussion unfold.
> >>>
> >>> What if we put Traits in "Extra" then? Sure, that is a
> >>> compromise that may work. But then we will loose a lot of the
> >>> real good use of Traits - to untangle our core packages like
> >>> for example Collections or Morphic. Because we can't have
> >>> packages in core depending on packages outside of core. So
> >>> that doesn't really sound like an interesting option.
> >>>
> >>> So, again - a very interesting challenge I think. Are we
> >>> going into the future or are we staying in the eighties? :-)
> >>> Can we do both?
> >>>
> >>> Well, fire away. But let's keep it civil. ;-)
> >>>
> >>> regards, Göran
> >>>
> >>>
> >
> >
> Prof. Dr. Stéphane DUCASSE (ducasse at iam.unibe.ch) 
> http://www.iam.unibe.ch/~ducasse/
>   "if you knew today was your last day on earth, what would you do
>   different? ... especially if, by doing something different, today
>   might not be your last day on earth" Calvin&Hobbes



More information about the Squeak-dev mailing list