Two important issues...

Stephane Ducasse ducasse at iam.unibe.ch
Sat Feb 15 08:12:49 UTC 2003


Hi daniel


On Saturday, February 15, 2003, at 02:43 AM, Daniel Vainsencher wrote:

> If we learned something from the 3.3aModules, it is that for something
> to be accepted, it better come in small, edible bites. People should be
> able to play with it from the beginning. Keep it in mind when you plan
> your releases.
>
> * Do take a little time to get feedback on the demo you posted. I've
> read the web page, including the screen shots.


Yes this is what we asked for.

> I think a good way to
> provoke more feedback would be to provide a real tutorial that doesn't
> just show features, but explains how to do something useful, for
> example, a walk through a small refactoring or two of a known existing
> class. After all, that's the most important potential most people have
> seen in Traits for - refactoring existing classes. Creating a new kind
> of Circle doesn't speak to me at least... but I'd love to get a feel 
> for
> how the streams refactoring is done, or something like it.

There is a good web page, three papers.  We are adults. we can also 
build
an example for ourselves.


> * Start posting some of the infrastucture in usable ways. The analysis
> code - package it up and put it on SM, even if the updating is 
> sometimes
> slow (or even without caching), so people can see it and offer comments
> (maybe the analysis part doesn't require recompiling 
> ClassDescription?).
> If you require patches to the base system, start posting them as 
> [FIX]es
> and such, so when you have a product, it doesn't depend on too many
> changes itself.

Yes but there some much patches of not so good squeak code.
Nathanael will do this analysis for us anyway so we will let you know.


> * Plan how the initial adopters will use the tool on their own 
> packages.
> Solving the big problems in the base image (collections, streams) is
> tempting, but it's not incremental. Start from the outside in - after
> Avi converts Seaside to use Traits (for example), the decision to adopt
> will seem very different.

You are vicious ;)

> * Articulate your architecture. Besides the theoretical aspect, to 
> adopt
> your code, people need to find their way around it. So even before you
> start coding, write up the components the system will require. Write up
> your release plan, and request feedback on it. You don't have to
> implement every suggestion (you'd never finish), but you'll see how
> people think about things, and what needs more explaining, and what
> people need for a release to be useful.
> * I'll put this on the table - for something as deep as Traits to 
> become
> part of the image, you need to treat the adopting very seriously. Think
> what happens if it get's accepted, then you decide to work on a
> different model, and then problems come up... we're stuck. Only way to
> avoid this is if other people seriously understand what it does, and we
> take the adoption slowly.

We know.

And imagine we have also classBoxes.
>
> I hope this helps. Let me know if I can help more.
>
> Daniel Vainsencher
>
> =?iso-8859-1?Q?Nathanael_Sch=E4rli?= <n.schaerli at gmx.net> wrote:
>> I would like to add that I'm open for your opinion regarding the 
>> future
>> plan of how and when to have a stable version of traits in Squeak. The
>> stuff I wrote below is just what seems to be the most effective for my
>> research activities and the availability of traits in Squeak. Please 
>> let
>> me know if you have other suggestions...
>>
>> Cheers,
>> Nathanael
>>
>>
>>> -----Original Message-----
>>> From: squeak-dev-bounces at lists.squeakfoundation.org
>>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
>>> Behalf Of Nathanael Schärli
>>> Sent: Freitag, 14. Februar 2003 22:54
>>> To: 'The general-purpose Squeak developers list'
>>> Subject: RE: Two important issues...
>>>
>>>
>>> Hi Daniel, hi all
>>>
>>> Thanks very much for your effort for clarifications. I hope
>>> that my comments makes things even more clear and understandable:
>>>
>>>> * 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).
>>>
>>> It is true that file out doesn't work in the current
>>> prototype. But this is not because it would be particularly
>>> hard to do, it is simply that I didn't get around to do it yet.
>>>
>>>> * You're going to create a v2, maybe in Squeak maybe not.
>>>> Maybe we'll know next week.
>>>
>>> Most probably it's going to be in Squeak, but I can't tell
>>> for sure yet.
>>>
>>>> Just want to clarify where we stand - it doesn't seems like
>>>> you're either ready or aiming for immidiate inclusion...
>>>
>>> Well, as it looks now, we are not going to derive a stable
>>> traits changeset from the current prototype implementation.
>>> This is mainly because we have some improvements of the model
>>> (v2) in mind, and we want to make sure that our next
>>> implementation supports this new model. However, it is
>>> important to note that we want to make sure that the next
>>> implementation can also be used as a stable version of traits v1.
>>>
>>> In fact, the main reason why we don't want to do much more
>>> work based on the current prototype is that we think it is
>>> more effective to spend our time on the new implementation
>>> and thereby to kill two birds with one stone.
>>>
>>> As a conclusion I would say that we don't aim for an
>>> _immediate_ inclusion into the image, but it is definitely an
>>> important goal to have traits (v1 and/or v2) available in
>>> Squeak not too far off!
>>>
>>>> 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?
>>>
>>> That's right. People who are interested in traits can try the
>>> demo, and of course I love to get any kind of feedback. Then,
>>> if someone wants to have a part of it available as soon as
>>> possible, I'm always interested in collaboration. Just let me know...
>>>
>>> Furthermore, we would of course appreciate any help in our
>>> effort to implement the extended stable version of traits. I
>>> don't know exactly what will be needed yet, but we could
>>> definitely need some help with a good and _flexible_ browser,
>>> a stable kernel (especially ClassBuilder) etc. I'll discuss
>>> with my group at Berne and Andreas next week and then I'll be
>>> able to gove more details.
>>>
>>> I hope that this helped clarifying things. I'll definitely
>>> post an update once we talked with Andreas. In the meantime,
>>> please feel free top ask any questions.
>>>
>>> Cheers,
>>> Nathanael
>>>
>>>
>>>> -----Original Message-----
>>>> From: squeak-dev-bounces at lists.squeakfoundation.org
>>>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
>>>> Behalf Of Daniel Vainsencher
>>>> Sent: Freitag, 14. Februar 2003 18:24
>>>> To: The general-purpose Squeak developers list
>>>> Subject: RE: Two important issues...
>>>>
>>>>
>>>> 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