Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )
2009/12/28 Andreas Raab <andreas.raab@gmx.de>:
Igor Stasenko wrote:
1. diff the number of lines between existing traits implementation & yours ?
It's a bit tricky to get a precise comparison, since Berne traits reuse various methods across Kernel-Classes and Traits. OTOH, there are many methods that will be removed from Kernel due to completely unnecessary complexities. I think the real comparison can only be done if you look at the totals of Kernel+[Nano]Traits before and after and since I haven't done the cleanup yet there is a bit of a problem in comparing this precisely. But you give an idea, here is a bit of data measured as follows:
#('Traits' 'Traits-Kernel' 'Traits-Kernel-Traits' 'Traits-Composition' 'NanoTraits-Kernel' 'NanoTraits-Tests') do:[:pkgName| | pkg | Â Â Â Â pkg := PackageInfo named: pkgName. Â Â Â Â Transcript cr; show: pkg name; Â Â Â Â Â Â Â Â tab; show: pkg classes size; Â Â Â Â Â Â Â Â tab; show: pkg methods size. ].
Package         Classes     Methods Traits          59        873 Traits-Kernel      22        343 Traits-Kernel-Traits   17        215 Traits-Composition    7        127 NanoTraits-Kernel    9        190 NanoTraits-Tests     9        122
oh, that's quite a big difference. I am curious, is it because of simpler implementation or because of smaller feature set?
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.
2. tools support, MC, Browser etc ?
Same as before. Slightly better on older systems (i.e., 3.8 based) because browsers can cope with traits as is and mostly don't need special support (i.e., using #classSide etc).
3. are there some common protocols with old traits, so one could use traits for metaprogramming?
As far as black-box reuse is concerned, there is no difference at all. There is also plenty of common stuff for the internals but it's very hard to know which protocols a particular client would use.
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)?
I haven't time to take a look at your code. But if it is smaller & less complex than current version, i will vote for it.
Try it. Load it via:
(Installer repository: 'http://www.squeaksource.com/NanoTraits') Â Â Â Â install: 'NanoTraits-Kernel'; Â Â Â Â install: 'NanoTraits-Tests'.
then install it using:
    NanoTrait install.
(WARNING: Be prepared to throw the image away if something goes wrong)
I just have some concerns about common protocols, so developers could use traits in both pharo & squeak without need of refactoring.
Fair enough. I don't think there's much difficulty as far as extending the existing protocols go. We could even add compatibility traits (TCompilingBehavior etc) that model the old structure if people want to add extension methods to those.
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.
Package Classes Methods Traits 59 873 Traits-Kernel 22 343 Traits-Kernel-Traits 17 215 Traits-Composition 7 127 NanoTraits-Kernel 9 190 NanoTraits-Tests 9 122
oh, that's quite a big difference. I am curious, is it because of simpler implementation or because of smaller feature set?
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.
(Installer repository: 'http://www.squeaksource.com/NanoTraits') install: 'NanoTraits-Kernel'; install: 'NanoTraits-Tests'.
then install it using:
NanoTrait install.
(WARNING: Be prepared to throw the image away if something goes wrong)
I just have some concerns about common protocols, so developers could use traits in both pharo & squeak without need of refactoring.
Fair enough. I don't think there's much difficulty as far as extending the existing protocols go. We could even add compatibility traits (TCompilingBehavior etc) that model the old structure if people want to add extension methods to those.
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.
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
2009/12/28 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Package         Classes     Methods Traits          59        873 Traits-Kernel      22        343 Traits-Kernel-Traits   17        215 Traits-Composition    7        127 NanoTraits-Kernel    9        190 NanoTraits-Tests     9        122
oh, that's quite a big difference. I am curious, is it because of simpler implementation or because of smaller feature set?
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?
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.
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.
(Installer repository: 'http://www.squeaksource.com/NanoTraits') Â Â Â Â install: 'NanoTraits-Kernel'; Â Â Â Â install: 'NanoTraits-Tests'.
then install it using:
    NanoTrait install.
(WARNING: Be prepared to throw the image away if something goes wrong)
I just have some concerns about common protocols, so developers could use traits in both pharo & squeak without need of refactoring.
Fair enough. I don't think there's much difficulty as far as extending the existing protocols go. We could even add compatibility traits (TCompilingBehavior etc) that model the old structure if people want to add extension methods to those.
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.
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
i hope i'm not in that list :)
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!
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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.
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.
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
i hope i'm not in that list :)
:) During sandwich lunch I will load it.... too curious :) Stef
On Dec 28, 2009, at 12:39 , Igor Stasenko wrote:
2009/12/28 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Package Classes Methods Traits 59 873 Traits-Kernel 22 343 Traits-Kernel-Traits 17 215 Traits-Composition 7 127 NanoTraits-Kernel 9 190 NanoTraits-Tests 9 122
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
On Wed, 30 Dec 2009, Adrian Lienhard wrote:
On Dec 28, 2009, at 12:39 , Igor Stasenko wrote:
2009/12/28 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Package Classes Methods Traits 59 873 Traits-Kernel 22 343 Traits-Kernel-Traits 17 215 Traits-Composition 7 127 NanoTraits-Kernel 9 190 NanoTraits-Tests 9 122
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 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?
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 [...]
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
Not that it bothers me... Andreas is free to do what he likes in his Squeak ;)
Cheers, Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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
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
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
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
----------- 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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Dec 30, 2009, at 10:44 AM, Igor Stasenko wrote:
----------- 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).
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.
;)
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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.
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. ;)
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
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 Pharo-project@lists.gforge.inria.fr 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 :)
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. ;)
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 :(
participants (5)
-
Adrian Lienhard -
David T. Lewis -
Igor Stasenko -
Levente Uzonyi -
Stéphane Ducasse