[squeak-dev] Unload Traits script

[squeak-dev] [ANN] Unload Traits script

***
Ok. Then what does this give you?

If you had such an image could you use it as a basis for development?
How would you update it?
How could you revert an update to it?

Basically what I am asking is could this be squeak 4.0 and a basis for future development?
Or would the image produced just be a curiosity that could not be developed further.

This is different from the question of should it be. That also is important to answer. But the "should"
question is a political one. I'm just looking for the technical answer to the "could" questions.

Yours in curiosity and service, --Jeorme Peace

P.S. How is work on DeltaStreams coming?



      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

El 5/10/08 5:58 PM, "Jerome Peace" <[hidden email]> escribió:


Well , 3.11 could not have Installer or any 3.8 don't have.
No SM, no Universes, no etc
As clean we manage to clean and not putting any.
Less code means less work, more easy to test, more easy to improve.
I plan to cut several things , so my first could be Traits.
It's your picture on Hall of Fame and going back to good track.

Repeat with me, smaller is good , smaller is faster , smaller is .... :=)

Edgar

Jerome Peace wrote: It gives you an image, a) without traits, and b) with the old class format.

The aim being to 1) enable folks with code that relies on the old format
to move up to 3.10 should they so desire 2) Satisfy those who dont like
the existing traits based traits implementation and would like to have
something simpler and 3) Provide a starting point for a future simpler
traits implementation if anyone wants to write it.
> If you had such an image could you use it as a basis for development?
>  
If you take 3.10 and remove traits, its roughly the same as a 3.8 image
with more toys and bug fixes of 3.9 and 3.10.

A future development for MC1.6+ will be to enable MC packages which
include traits to automatically load flattened into a non-trait image.
i.e. traits fans can use them as a design/code reuse tool publishing
their work as a package that anyone can use.
> How would you update it?
>  
In comparison to which current practice?
> How could you revert an update to it?
>
>  
In comparison to which current practice?

Reverting is part of the DS concept.

Sake/Packages has a Package-level unload function which could work well
if appropriately configured.
> Basically what I am asking is could this be squeak 4.0 and a basis for future development?
>  
If someone does the complementary "TraitsLoad", then
3.11-minimal-load-what-you-need-image can be published without traits.
However doing this would prevent traits being used unflattened in the
kernel, so it may be better to leave traits in, with a "flatten all
traits and remove traits" script or sake-task.
> Or would the image produced just be a curiosity that could not be developed further.
>
> This is different from the question of should it be. That also is important to answer. But the "should"
> question is a political one. I'm just looking for the technical answer to the "could" questions.
>  
Where there is a will there is a way...  subject to further tools support.

regards

Keith
 

2008/5/11, Keith Hodges <[hidden email]>:
What about people who need traits?

Cheers
Philippe

>> What about people who need traits?

Hi philippe

who care, they are idiot. Reuse is a bullshit.
if people believe that traits are the unique problem of Squeak let  
them believe it.

I recently receive that email from a guy aparently from the C++ and  
perl community. Certainly one of this
one idiot that believe in other abstractions.

"First, I wonder if you were aware of the impact your paper has had on  
the early stages of designing the object system for Perl 6.  I guess  
Larry was quite taken with the idea.  After struggling to bend C++  
templates to a similar end, I certainly see it as revolutionary.

I further wonder if you are interested in Perl 6, and are looking in  
on the design effort from time to time.  I'm currently working on a  
more detailed exploration of the type system.

--John"

We made a huge mistake to have done 3.9, we should have forked 3 years  
ago. Now I start to believe what marcus always told me.

Stef

Philippe Marschall wrote:
>>  It gives you an image, a) without traits, and b) with the old class format.
>>
>>  The aim being to 1) enable folks with code that relies on the old format to
>> move up to 3.10 should they so desire 2) Satisfy those who dont like the
>> existing traits based traits implementation and would like to have something
>> simpler and 3) Provide a starting point for a future simpler traits
>> implementation if anyone wants to write it.
>
> What about people who need traits?

There is no reason why a traits implementation needs to be as intrusive
as this one. Earlier this year I had been playing with a traits
implementation for Croquet just to understand some of the implementation
aspects a little better and it was pretty clear that an alternative
implementation which is much less invasive is not only trivial to do but
fits much better into the rest of the existing system. I'm attaching a
draft version of this experiment (which is not fully functional since I
lost interest but it will load into Croquet and is enough to play with
it) and you can check it out to see how it hooks into the system -
basically traits inherit from ClassDescription which avoids most of the
code duplication and leaves the option for perhaps having stateful
traits at some point. The extension points to the existing kernel are
few (and could be made fewer) and loading and unloading would be trivial
with just a tiny bit more work.

In any case, this is not a complete implementation but rather an
illustration that the current implementation isn't the only way traits
can be implemented in Squeak and that an alternative can be small,
loadable, and easy to understand.

Cheers,
   - Andreas

2008/5/12, Andreas Raab <[hidden email]>:
All fine and well. But my question is what about people with existing
traits code (like myself). I don't really care about the
implementation (it's OO after all). I care wether the stuff actually
works or not.

Cheers
Philippe

Philippe Marschall wrote:
> All fine and well. But my question is what about people with existing
> traits code (like myself). I don't really care about the
> implementation (it's OO after all). I care wether the stuff actually
> works or not.

I see. I thought your question was more about the meta aspect. Assuming
this goes forward (which, as far as I know is still completely open), I
would suggest you stay with 3.10 for the time being until either a
reload-script for the existing traits implementation is available, or an
alternative traits implementation exists. The version I posted would
require some adjustments for 3.10 and a lot more bug-fixing but the
basics are certainly in place. Having some more black-box tests for
traits would definitely help, too.

Cheers,
   - Andreas

On Mon, 12 May 2008 14:57:22 +0200, Andreas Raab wrote:

Interesting. What would be class Metatrait about (you do new new to it),  
other than for the browser's convenience? Would it make possible to apply  
the same traits to a) the instance side of class A and b) the class side  
of class B?

Klaus D. Witzel wrote:
> Interesting. What would be class Metatrait about (you do new new to it),
> other than for the browser's convenience? Would it make possible to
> apply the same traits to a) the instance side of class A and b) the
> class side of class B?

Purely convenience. By having the class-side trait being represented as
the class of the instance trait, the browser doesn't need to be aware of
it. Not necessarily the most obvious solution but it keeps changes in
other places very minimal.

Your idea about applying traits is certainly possible but relationship
between traits and classes is already questionable as far as I am
concerned. For example, traits without a class trait can be applied to
meta classes; traits with class traits can not be applied meta classes;
but once an instance trait is applied to a metaclass one can still add a
method to its class trait etc. So I'm not in favour of making that any
more complex than it absolutely has to be; in fact, I'd be in favor of
abandoning the ability to apply instance traits to metaclasses
altogether for clarity.

Cheers,
   - Andreas

On Mon, 12 May 2008 19:39:32 +0200, Andreas Raab wrote:

Yes, right.

> Your idea about applying traits is certainly possible but relationship  
> between traits and classes is already questionable as far as I am  
> concerned. For example, traits without a class trait can be applied to  
> meta classes; traits with class traits can not be applied meta classes;  
> but once an instance trait is applied to a metaclass one can still add a  
> method to its class trait etc. So I'm not in favour of making that any  
> more complex than it absolutely has to be; in fact, I'd be in favor of  
> abandoning the ability to apply instance traits to metaclasses  
> altogether for clarity.

It is perhaps possible to go one step further (or go back, for that  
matter) and have no instance traits and no class traits, but just traits  
(subclass of ClassDescription, instVar 'users'). It can be applied to  
either side of some class, since the whole machinery has no requirement  
other than #traitComposition (as far as I've seen). Wouldn't that make the  
exercise less complex and more clear, or am I missing something.

There may even be quite different compositions required for both sides of  
a class. As an example consider making Traits (incl. their tests ;) for  
the 5.3 Fundamental Protocols of ANSI Smalltalk 1997. This looks to be  
impossible with dualistic traits.

/Klaus

2008/5/12, Klaus D. Witzel <[hidden email]>:
It would also be interesting to see if getting rid of sharing
CompiledMethods would simplify the implementation.

Cheers
Philippe

> All fine and well. But my question is what about people with existing
> traits code (like myself). I don't really care about the
> implementation (it's OO after all). I care wether the stuff actually
> works or not.
>
> Cheers
> Philippe
>  
Dear Philippe,

Some members of the current ad-hoc release team, namely Matthew, and
myself, are moving for a change of culture when it comes to moving
Squeak forward.

This change is aiming to promote inclusiveness among of the different
squeak user communities. Enabling projects to migrate between the
different base versions currently in use, aiming to provide the
underpinnings that will allow image building scripts to work in more
contexts.

A lot of progress has been made on this front, with much more still
happening in the background. Such radical changes in attitude will
probably take a while to catch on, but I think this is the right way to go.

This means that Matthew's work on the TraitsUnload script is intended to
include an excluded branch of the community. However this is not to be
done at the expense of the Trait using community.

Given that the design of traits supports flattening, I think this
inter-workability is acheivable. Matthew (and I if I can find time) will
be working on some better tools support for loading traits in to both
types of images.

At some stage I would like to do the same for Namespaces.... the tools
can support loading namespace requiring code into non-namespaced images
etc. Thus lowering the bar of conflict between the two  (or more)
approaches.

best regards

Keith

stephane ducasse wrote: Sorry Stef but I think you are overreacting,

We like traits, we are just providing options for the community.

It is clear that Andreas likes the idea of traits enough to consider
working them into Croquet as he has shown in the previous email.

If you didnt want this level of flexibility then you guys shouldnt have
designed traits to be flattenable and hence backwardly compatibile.
Therefore this is just a perfectly logical next step in the traits story
and nothing to get upset about.

best regards

Keith

Klaus D. Witzel wrote:
> It is perhaps possible to go one step further (or go back, for that
> matter) and have no instance traits and no class traits, but just traits
> (subclass of ClassDescription, instVar 'users'). It can be applied to
> either side of some class, since the whole machinery has no requirement
> other than #traitComposition (as far as I've seen). Wouldn't that make
> the exercise less complex and more clear, or am I missing something.

 From my POV that's even better but also a little more drastic ;-)

Cheers,
   - Andreas

Philippe Marschall wrote:
>>  It is perhaps possible to go one step further (or go back, for that matter)
>> and have no instance traits and no class traits, but just traits (subclass
>> of ClassDescription, instVar 'users'). It can be applied to either side of
>> some class, since the whole machinery has no requirement other than
>> #traitComposition (as far as I've seen). Wouldn't that make the exercise
>> less complex and more clear, or am I missing something.
>
> It would also be interesting to see if getting rid of sharing
> CompiledMethods would simplify the implementation.

Actually, very little. The only piece that distinguishes a version which
shares from a version which doesn't is that the former has a conditional
that says "only recompile when this method has a super-send". Outside of
that there really is no difference.

 From what I can tell, most of the complexity of the implementation of
traits originates from having to broadcast and handle changes to methods
in traits to their users (managing local overrides etc) and to deal with
the transformations along the way.

Cheers,
   - Andreas

"Klaus D. Witzel" <[hidden email]> wrote in message

> It is perhaps possible to go one step further (or go back, for that
> matter) and have no instance traits and no class traits, but just traits

+1. This seems much cleaner (without knowing the intricacies of
implementation).

But there is value to having an explicit "pair-of-traits" construct, since a
trait on normal instances often naturally pairs with (and needs) a
corresponding trait on the class, and vice-versa.

Sophie

On Mon, 12 May 2008 23:12:45 +0200, Andreas Raab wrote:

Hhm, all the class traits that I've seen so far tell me this:

- don't even *think* about applying me to any other class than "mine"
- I am *not* reusable, my methods should be ordinary class methods

Class methods carry the burden of instance creation and class  
initialization. Now if such a class traits could *really* be applied,  
*as*is*, say to 100+ potential users, then something must be wrong in the  
realm of the king of Denmark. I mean to say, that for the class hierarchy  
that someone is going to create with such class traits, *something*must*  
be wrong, be it design, inheritance, or whatever.

The traits in category Nile-Base-Traits of Nil-Base-dc.57.mcz, for  
example, have *zero* class traits, for good reason.

The traits in category Traits-Kernel-Traits, for another example, have  
*zero* class traits, for good reason. And all other class traits in the  
Traits-* category are *unapplicable* when not used by the sole class for  
which they have been designed. Re-use? I fail to see any re-use potential  
for the class traits of this package.

People correct me please since there must be something wrong.

But if not, or almost not, then I kindly ask that we do not base our  
decisions on un-reusable cases.

/Klaus

> Cheers,
>    - Andreas
[...]

On Tue, 13 May 2008 00:56:35 +0200, itsme213 <[hidden email]> wrote:

> "Klaus D. Witzel" <[hidden email]> wrote in message
>
>> It is perhaps possible to go one step further (or go back, for that
>> matter) and have no instance traits and no class traits, but just traits
>
> +1. This seems much cleaner (without knowing the intricacies of
> implementation).

:)

> But there is value to having an explicit "pair-of-traits" construct,  
> since a
> trait on normal instances often naturally pairs with (and needs) a
> corresponding trait on the class, and vice-versa.

Yes, if there really is some class traits that the instance traits depends  
on, it would have value. But I doubt that the class traits can then be  
re-used (for instance creation and/or class initialization), see my  
response to Andreas.

> Sophie
>
>
>
>
>

"Klaus D. Witzel" <[hidden email]> wrote in message

> Yes, if there really is some class traits that the instance traits depends
> on, it would have value.

It shows up often when designing a DSL e.g. for state machines

  - FSMClassTrait: stateList, initialState, transitions
  - FSMInstanceTrait: currentState, doTransition: anEvent

> But I doubt that the class traits can then be  re-used (for instance
> creation and/or class initialization)

Probably true.

- Sophie