Re: [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

2009/12/28 Andreas Raab <[hidden email]>:
oh, that's quite a big difference.
I am curious, is it because of simpler implementation or because of
smaller feature set?
Well, browser should use some protocol to distingush between traits & classes,
trait methods and regular ones etc.. As well as MC, SystemNotifier ,
changesets etc.

Do you plan to fully adopt new traits in trunk (means completely
replacing current ones, of course)?
AFAIK, Pharo cleaned-up some stuff , removed this particular trait.
I am however, think that putting traits in use for core classes having
one VERY IMPORTANT aspect,
that in this way we can decompose a bloated protocol(s) into a number
a smaller ones, with well-distinguished roles,
aside of code reuse.

> And hey, my code is always MIT, so if the Pharo folks are interested, tell
> them they're more than welcome to use and enhance it. The squeaksource
> repository is world-writable.

Aye, i CC this conversation to pharo list.
Personally, amount of code is the major criteria for me to choose
from. Especially for things in Kernel.
And especially, if it doesn't having heavy tradeoffs.

>
> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

First two remarks
        -we should remove the old infrasturcture for requirements computation that has not
        much with traits.
        - second counting number of classes is not a good measure.
        Do you think that this is better to have one Refactoring class or 18 Refactoring classes?

>> The "meat" for NanoTraits is 9 classes and 190 methods And, after installing
>> NanoTraits there will be many other methods removed in Behavior and friends
>> which are only the result of unnecessary complexity in Berned traits. It
>> will be *significantly* simpler by any measures and unloadable.

This is probably true.
This is why I want to see the result of nano traits.


I'm really interested in a cleaner/smaller/less intrusive trait implementations.
Contrary to what some not so clever guys thought it was always the case. ;D
Just no time right now. shit..... back project wirting

> Aye, i CC this conversation to pharo list.
> Personally, amount of code is the major criteria for me to choose
> from. Especially for things in Kernel.
> And especially, if it doesn't having heavy tradeoffs.

Igor please rephrase your thoughts! :)
        amount of complexity !!!
        not amount of code!!!
        Come on number of classes is not a decent measure in presence of late binding!

Stef



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/12/28 Stéphane Ducasse <[hidden email]>: I counting, because i want smaller kernel (including image size) and
memory footprint.
And sure thing, i don't think that 1 class with tons of custom methods
better than 18 ones. It depends.

i hope i'm not in that list :)

hehe.. i hope that Andreas writing short methods, not a fat ones which
trying to do everything at once :)
I just pointing out, that it is much easier to study & comprehend a
smaller code base.
Less methods, less classes => less code to read & understand.

I can't say anything about complexity of nano-traits comparing to Berne ones.
Its just my guess, that less code is a sign of less complex model, or
better code reuse, and so i welcome it :)

> Stef
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

we are in sync but this is always good to reassess the not so basics.

> I counting, because i want smaller kernel (including image size) and
> memory footprint.
> And sure thing, i don't think that 1 class with tons of custom methods
> better than 18 ones. It depends.

classes are active vocabulary.

:)

During sandwich lunch I will load it.... too curious :)

Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

for 1.1

Gofer new
         squeaksource: 'NanoTraits';
       package: 'NanoTraits-Kernel';
       package: 'NanoTraits-Tests';
        load


NanoTrait install

        I got a DNU ClassDescription traitImpl is not know.

ClassDescription>>traitImpl
       
        ^NanoTrait

uses: aTraitComposition
        | newTraits |
        newTraits := ((aTraitComposition isKindOf: NanoTrait) or: [ aTraitComposition isKindOf: NanoTraitTransformation])

aTraitComposition isKindOf: NanoTrait orOf: NanoTraitTransformation
        does not exist anymore in pharo :) luckily!


Behavior class>>installTraitsFrom: aTraitComposition
        ...
        self traitComposition removeTraitUser: self.
        -> DNU removeTraitUser:


Some comments I got just reading the code and eating.
Difficult to write in mails because this is more like metathoughts about the overall design space
(not only NT) but kernel, Btrait and NTraits.

        - I tried to understand what is the benefit to have NTdescription and NClassTrait subclass of
        ClassDescription.
        I think that this is a pity that the interface of the existing kernel and BTrait could not

        Now what I would really like to see is the impact on the tools (I imagine that andreas design
        is better for that and I would like to understand what are the underlying invariant of the tools
        that Btraits broke. I imagine that Btrait interface is not that far from NTrait now the point is probably
        that the fact that NT inherits some not necessary behavior from ClassDescription fulfills better
        the tool invariant.


        - I have the impression that the design of adrian was less backwards and more here is a "new" kernel
        and tools were shaken.

        - something that I would like to see fixed in traits is the problem with the superclass
               
Igor once you remove the non traits related classes:
        Trait-Requires
        Trait-LocalSends

        Traits-Kernel => 5 classes
        Traits-Composition => 7  (and I imagine that we could do a pass to clean method)
        so all in all we may have 15 classes in total (exception included).

Issue 1706: Clean Traits implementation
        http://code.google.com/p/pharo/issues/detail?id=1706


Back latexing pffffff :(


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Dec 28, 2009, at 12:39 , Igor Stasenko wrote:

Haha. This table is nonsense:
- The package "Traits" includes "Traits-Kernel", "Traits-Composition"  
etc. so it is counting the same classes and methods twice
- The numbers are from an older implementation of Traits. In Pharo  
there is a refactored version with less traits that is easier to  
understand. Squeak has an old version.
- Methods defined in the traits ("Traits-Kernel-Traits") are also used  
by Behavior, ClassDescription, etc. hence making these classes smaller  
in turn (but the table does not show this fact)
- The requires algorithm is not directly related to Traits (as I  
pointed out in a recent mail)

In a Pharo 1.0 image I get

Package                 Classes         Methods
Traits-Kernel 11 343
Traits-Kernel-Traits 6 215
Traits-Composition 7 122

[...]

>> Igor please rephrase your thoughts! :)
>>        amount of complexity !!!
>>        not amount of code!!!
>>        Come on number of classes is not a decent measure in  
>> presence of late binding!
>>
>
> hehe.. i hope that Andreas writing short methods, not a fat ones which
> trying to do everything at once :)


Not sure about this. I browsed through the NanoTraits code for 2  
minutes, and one thing that puzzled me was this method:

!ClassDescription methodsFor: '*NanoTraits-Extensions' stamp: 'ar  
12/20/2009 13:38'!
installTraitsFrom: aTraitComposition
        "Install the traits from the given composition"
        | allTraits methods oldMethod removals oldCategories |
        (aTraitComposition isKindOf: NanoTraitComposition)
                ifFalse:[self error: 'Invalid composition'].
        (self traitComposition isEmpty and: [aTraitComposition isEmpty])  
ifTrue: [^self].

        "Check for cycles"
        allTraits := aTraitComposition gather: [:t | t allTraits copyWith: t].
        (allTraits includes: self) ifTrue:[^self error: 'Cyclic trait  
definition detected'].

        "XXXX: addUser/removeUser should be part of setter, but subclass
        override prevents it until we've got rid of Traits mess."
        self traitComposition removeTraitUser: self.
        self traitComposition: aTraitComposition.
        aTraitComposition addTraitUser: self.

        "Assemble the methods in a new dictionary first.
        Uses a Dictionary instead of a MethodDictionary for speed (MDs grow  
by #become:)"
        methods := Dictionary new.

        "Stick in the local methods first, since this avoids generating  
conflict methods unnecessarily"
        self selectorsAndMethodsDo:[:sel :newMethod|
                (self isLocalMethod: newMethod)
                        ifTrue:[methods at: sel put:newMethod]].

        "Now assemble the traits methods"
        aTraitComposition do:[:trait|
                trait selectorsAndMethodsDo:[:sel :newMethod|
                        oldMethod := methods at: sel ifAbsentPut:[newMethod].
                        newMethod == oldMethod ifFalse:["a conflict"
                                (self isLocalMethod: oldMethod) ifFalse:[
                                        methods at: sel put: (self resolveTraitsConflict: sel from:  
oldMethod to: newMethod).
                                ].
                        ].
                ].
        ].

        "Apply the changes. We first add the new or changed methods."
        oldCategories := Set new.
        methods keysAndValuesDo:[:sel :newMethod|
                oldMethod := self compiledMethodAt: sel ifAbsent:[nil].
                oldMethod == newMethod ifFalse:[
                        self traitAddSelector: sel withMethod: newMethod.
                        (self organization categoryOfElement: sel) ifNotNil:[:cat|  
oldCategories add: cat].
                        self organization classify: sel under:
                                (newMethod methodHome organization categoryOfElement: newMethod  
selector).
                ]].

        "Now remove the old or obsoleted ones"
        removals := OrderedCollection new.
        self selectorsDo:[:sel| (methods includesKey: sel) ifFalse:[removals  
add: sel]].
        removals do:[:sel| self traitRemoveSelector: sel].

        "Clean out empty categories"
        oldCategories do:[:cat|
                (self organization isEmptyCategoryNamed: cat)
                        ifTrue:[self organization removeCategory: cat]].

        self isMeta ifFalse:[self class updateTraitsFrom:  
aTraitComposition].! !


Not that it bothers me... Andreas is free to do what he likes in his  
Squeak ;)

Cheers,
Adrian
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Wed, 30 Dec 2009, Adrian Lienhard wrote:
The first line in the table is "nonsense" or just gives a brief overview.

> - The numbers are from an older implementation of Traits. In Pharo
> there is a refactored version with less traits that is easier to
> understand. Squeak has an old version.

Well, it's abandoned.

> - Methods defined in the traits ("Traits-Kernel-Traits") are also used
> by Behavior, ClassDescription, etc. hence making these classes smaller
> in turn (but the table does not show this fact)

Correct me if I'm wrong, but PackageInfo >> #methods returns only local
selectors, so this is not true.

> - The requires algorithm is not directly related to Traits (as I
> pointed out in a recent mail)

That's cool, but why is it there?
Picking one long method is easy. Let's see raw numbers:

NanoTraits in Squeak Trunk (update 8660)
Package Classes Methods Loc Loc/Method
Traits-Composition 5 64 221 3.45
Traits-Kernel 22 91 394 4.33
Traits-Kernel-Traits 17 0 0 -
Kernel-Classes 10 589 4754 8.07
Total 54 744 5369 7.22

Traits in Pharo 1.1 (update 11120)
Package Classes Methods Loc Loc/Method
Traits-Composition 7 122 615 5.04
Traits-Kernel 11 343 1988 5.8
Traits-Kernel-Traits 6 214 1360 6.36
Kernel-Classes 10 460 3931 8.55
Total 34 1139 7894 6.93

According to these numbers, Pharo's traits implementation has less
classes, more methods, more code and longer methods (average).

(Code to generate the data:
String streamContents: [ :stream |
    #('Traits-Composition' 'Traits-Kernel' 'Traits-Kernel-Traits' 'Kernel-Classes' )
       do: [ :packageName |
          | package methods linesOfCode |
          package := PackageInfo named: packageName.
          methods := package methods.
          linesOfCode := methods detectSum: [ :each |
             each compiledMethod linesOfCode ].
          stream nextPutAll: (
             '<1S><T><2P><T><3P><T><4P><T><5P><N>'
                expandMacrosWithArguments: {
                   packageName.
                   package classes size.
                   methods size.
                   linesOfCode.
                   methods
                      ifEmpty: [ '-' ]
                      ifNotEmpty: [
                         linesOfCode / methods size roundTo: 0.01 ] }) ] ])


Levente

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
>
>> - The requires algorithm is not directly related to Traits (as I
>> pointed out in a recent mail)
>
> That's cool, but why is it there?

I can reply to you on that one :)

Some historical background first. Nathanael (who was hesitating to go to work with andreas - since andreas
was really interested to have traits to build user interface for kids - I remember them drawing picture on
the board of nathanael and marcus office) implemented a Browser that showed
instantaneously where you would need to provide a method because of a trait composition.
This was difficult because of the quality of Squeak library (containing a lot of self send to method
not existing in Object), the bad state of the browser and because the system is dynamic (you can add a method anytime anywhere). This is explained in depth in his PhD.
Nathanael was wise and declined the offer to go to google. I'm sure that he does not feel insulted
by certain statement because a lot of languages would like to have traits or introduce them instead
of bashing them: Scala, Perl, Fortress... we even got a guy of MS that asked us to apply to get a grant
to port trait to C# (boring with types).

Nathanael did a first implementation of traits that was driven by tape to fix a lot of places which
were suboptimal. Then Adrian reimplemented the core as part of his master thesis. The idea
was that Squeak deserved a good trait implementation if we wanted to get a chance to build on them.
The state of the Squeak browser was getting in our way (no tree widgets at that time still not today). OB was not an alternative - no tree widgets. So adrian did not get the time and will to fix the Squeak UI lib and build a browser.

Now this is just fun to see how some people have the tendency to insult others because I think that adrian is
        - a really smart guy (got several awards for his work)
        - talented (run his own company since years in parallel to do research)
        I mean a real company that is not sponsored but live with the money it collects.

Then practically during the last two years, we clean a ***lot*** of problem. Now squeak is starting to clean.
Mainly also because nicolas is pushing a lot of fixes from pharo to squeak.
And we go at our little speed but we go steadily and we will continue.

I imagine that this gives an historical view to the question and I thanks you because we will probably clean it.

Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Adrian

What I would like to understand
        - what part of the require algorithm could we unload?
        because I imagine that the requirement analysis is
        for the self sends deep up the hierarchy that may invoke an explicit requirement
        deep down the composition and this is not related
        to the simple self explicitRequirement. I would be good to do a pass because it would
        clarify the code. I could give a try but I would prefer you to do it and also we should not
        rush this is not because squeak is getting frantic that we should - I said that mainly for me. ;)

        - what is the impact from the tool perspective to have trait subclass of class description
        I imagine that you get less bug due to Trait dnu superclass and friend.
       
I do not care about the install method I imagine that it is long and you can throw it away.

Now let us be smarter than some people think we are :)
What can we learn from nanotrait:
        - is the composition more robust (I think that andreas change a bit the operator)
        - is the code simpler?
                for example
                        push traitComposition into TraitOrganizer so that we don't need to
                        duplicate it in three places (Class, Metaclass, TraitDescription).
                        of course using trait you do not duplicate
        - we have the opportunity to compare and weight pro and cons.
        We could even write a workshop paper on it for fun (ok not that fun :)).
Stef


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-----------
Reposting from squeak-dev (about nanotraits):

ClassDescription , Metaclass ivars:
 traitComposition localSelectors
has no uses.

Andreas using a TraitMethodProperties to hold a reference to original
method, and then to trait. So, its easy to tell whether method is
local or not, by asking it, without need of keeping a separate state.
I find such approach less error prone, since method is the unit of
manipulation for traits and asking it directly, where it came, seems
more straightforward.
It is, however incurs a little overhead: any method which comes from
trait should keep additional state in
MethodProperties (in fact , a subclass of it), while normally, most of
methods don't need to have it.
And sure thing, copying method over multiple method
dicts, does not require you to care about keeping something else in
sync (except categorizer, maybe).
----------

Stephane,
i appreciate your way of doing things. Really, if something is 'not
invented here' , its a signal to learn from it, how you could improve
things,
but not a signal to start bashing each other over and over again.
For professionals, at first place should be the code, the idea and
quality of implementation, but not where it came from.

2009/12/30 Stéphane Ducasse <[hidden email]>:


--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Dec 30, 2009, at 10:44 AM, Igor Stasenko wrote:


I have to digest that paragraph (a bit difficult).

> Stephane,
> i appreciate your way of doing things. Really, if something is 'not
> invented here' , its a signal to learn from it, how you could improve
> things,
> but not a signal to start bashing each other over and over again.

Thanks. I really believe what I wrote :) No marketing in it.
I always want to learn from alternate design.
I think that in general there is a chance people need another view to things
to understand the world.

> For professionals, at first place should be the code, the idea and
> quality of implementation, but not where it came from.

        ;)


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Dec 30, 2009, at 09:53 , Stéphane Ducasse wrote:

> Adrian
>
> What I would like to understand
> - what part of the require algorithm could we unload?

Everything can be unloaded.

Yes, I can take a look. But as you say, not right now ;)

> - what is the impact from the tool perspective to have trait  
> subclass of class description
> I imagine that you get less bug due to Trait dnu superclass and  
> friend.

I'd also like to look closer into NanoTraits. But so far I failed to  
get a trunk image with it. I downloaded Squeak3.11-8472-alpha.image  
from the ftp server and did an update to 8660 but I still get the  
outdated traits implementation of Squeak.

Inheriting from ClassDescription you need less code but you inherit  
too much so I wonder how you deal with the inherited behavior that  
does not make sense for traits.

> I do not care about the install method I imagine that it is long and  
> you can throw it away.

Me neither. This was a joke ;)

Adrian


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Excellent
So we should finish 1.0 so that you get some cycles for 1.1 :)

>> What I would like to understand
>> - what part of the require algorithm could we unload?
>
> Everything can be unloaded.
        Good I tried 5 min in a wild way but I failed but ok it was quite wild :)
:)


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Wed, Dec 30, 2009 at 09:50:40AM +0100, St?phane Ducasse wrote:
> >
> >> - The requires algorithm is not directly related to Traits (as I
> >> pointed out in a recent mail)
> >
> > That's cool, but why is it there?
>
> I can reply to you on that one :)

<snip>

> I imagine that this gives an historical view to the question and I thanks
> you because we will probably clean it.

Stef,

Thanks for providing this historical background. It's an interesting story
and helps understanding for those of us who did not have an office near by :)

Dave


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> I imagine that this gives an historical view to the question and I thanks
>> you because we will probably clean it.
>
> Stef,
>
> Thanks for providing this historical background. It's an interesting story
> and helps understanding for those of us who did not have an office near by :)

I'm a bit sad that google attracted nathanael because he had plenty of other cool
ideas. But we cannot redo the history.
So head to the future :)

Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project