On 12/1/06, J J azreal1977@hotmail.com wrote:
Yes, the inheritance model without them has some real problems. And finding a solution is tough. C++'s multiple inheritance? Too complicated. Java's interfaces? Too much work and code duplication. So now smalltalk has a solution, and IMO the best one.
Is that opinion based on real-world use of Traits? Now that they've been in the base image for a decent length of time, I'm curious to hear of any war stories from using Traits outside of a research context. I've never used them in anger myself, so it would be very interesting to hear from those who have.
Avi
On 1-Dec-06, at 11:05 AM, Avi Bryant wrote:
On 12/1/06, J J azreal1977@hotmail.com wrote:
Yes, the inheritance model without them has some real problems. And finding a solution is tough. C++'s multiple inheritance? Too complicated. Java's interfaces? Too much work and code duplication. So now smalltalk has a solution, and IMO the best one.
Is that opinion based on real-world use of Traits? Now that they've been in the base image for a decent length of time, I'm curious to hear of any war stories from using Traits outside of a research context. I've never used them in anger myself, so it would be very interesting to hear from those who have.
I've not tried to use them but I did trip over them when working on cleaning up the compiled method source pointer mess (which I still haven't finished, rats). The problem is that the tool support appears to be missing, which is a real pain. For example, I edit a trait- method in one place that it is incorporated (imported? linked? whatever) and there is nothing that tells me it is a trait, or asks me if I want to make my change a local version or a global one or anything at all. No matter how good an idea is, without proper integration it ends up causing problems.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Pedaling real fast, but not getting anywhere.
I've not tried to use them but I did trip over them when working on cleaning up the compiled method source pointer mess (which I still haven't finished, rats). The problem is that the tool support appears to be missing, which is a real pain. For example, I edit a trait- method in one place that it is incorporated (imported? linked? whatever) and there is nothing that tells me it is a trait, or asks me if I want to make my change a local version or a global one or anything at all.
OmniBrowser has a small extension in 3.9 that shows imported methods in italic, redefined and locally defined ones with normal fonts. This helps a little bit, but I agree it does not help more than for toy examples: very soon you end up not understanding anymore what is going on.
I wonder if the virtual method-categories of Damien Cassou would help here? In the traits model all the info is there, it just needs to be displayed in the browser nicely. Should be a matter of minutes to define those method-categories (requires, supplies, overrides) to get a useable trait browser, no?
And to answer the initial question: no, unfortunately not.
Cheers, Lukas
On 1-Dec-06, at 11:32 AM, Lukas Renggli wrote:
OmniBrowser has a small extension in 3.9 that shows imported methods in italic, redefined and locally defined ones with normal fonts. This helps a little bit, but I agree it does not help more than for toy examples: very soon you end up not understanding anymore what is going on.
Anything relying on extremely minor cues like that is not going to work for many people. It has to be clear and informative and include added/changed menus etc. Anything much less than full integration with documentation to assist will just mean that at the very best a new capability like this will get ignored. Most likely it will be misused through ignorance and cause bugs down the line. Surely nobody wants that?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Logic: The art of being wrong with confidence...
2006/12/1, Lukas Renggli renggli@gmail.com:
I've not tried to use them but I did trip over them when working on cleaning up the compiled method source pointer mess (which I still haven't finished, rats). The problem is that the tool support appears to be missing, which is a real pain. For example, I edit a trait- method in one place that it is incorporated (imported? linked? whatever) and there is nothing that tells me it is a trait, or asks me if I want to make my change a local version or a global one or anything at all.
OmniBrowser has a small extension in 3.9 that shows imported methods in italic, redefined and locally defined ones with normal fonts. This helps a little bit, but I agree it does not help more than for toy examples: very soon you end up not understanding anymore what is going on.
I wonder if the virtual method-categories of Damien Cassou would help here? In the traits model all the info is there, it just needs to be displayed in the browser nicely. Should be a matter of minutes to define those method-categories (requires, supplies, overrides) to get a useable trait browser, no?
And to answer the initial question: no, unfortunately not.
For the n-th time:
TraitsOmniBrowser (not the one in the image): that's what virtual categories come from in the first place anyway.
Philipe
From: tim Rowledge tim@rowledge.org Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: avi@smallthought.com, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: Traits in use (was Re: Re: Squeak and Namespaces) Date: Fri, 1 Dec 2006 11:16:28 -0800
On 1-Dec-06, at 11:05 AM, Avi Bryant wrote:
On 12/1/06, J J azreal1977@hotmail.com wrote:
Yes, the inheritance model without them has some real problems. And finding a solution is tough. C++'s multiple inheritance? Too complicated. Java's interfaces? Too much work and code duplication. So now smalltalk has a solution, and IMO the best one.
Is that opinion based on real-world use of Traits? Now that they've been in the base image for a decent length of time, I'm curious to hear of any war stories from using Traits outside of a research context. I've never used them in anger myself, so it would be very interesting to hear from those who have.
I've not tried to use them but I did trip over them when working on cleaning up the compiled method source pointer mess (which I still haven't finished, rats). The problem is that the tool support appears to be missing, which is a real pain. For example, I edit a trait- method in one place that it is incorporated (imported? linked? whatever) and there is nothing that tells me it is a trait, or asks me if I want to make my change a local version or a global one or anything at all. No matter how good an idea is, without proper integration it ends up causing problems.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Pedaling real fast, but not getting anywhere.
I was under the impression that there was a "trait's aware" browser in the image, or at least loadable from squeak map or something. Am I wrong?
_________________________________________________________________ Share your latest news with your friends with the Windows Live Spaces friends module. http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spa...
Hi Avi,
I do not believe that you haven't used the trait concept for real-world problems (no offense).
Instead, whenever you factored some methods such that instance variables and class variables are on accessors, you have traitified these methods. Every other class, which provides the respective accessors, can (re-)use these traitified methods (modulo that that makes sense for an application).
Stateless traits is nothing much more. But the Trait system in Squeak comes with Trait *composition* and composition is something which perhaps was not used before (perhaps not intentionally). Doing Trait composition manually, without using the supportive code in Squeak, is like gcc -S followed by cut&paste, IMHO ;-)
/Klaus
On Fri, 01 Dec 2006 20:05:38 +0100, Avi Bryant wrote:
On 12/1/06, J J azreal1977@hotmail.com wrote:
Yes, the inheritance model without them has some real problems. And finding a solution is tough. C++'s multiple inheritance? Too complicated. Java's interfaces? Too much work and code duplication. So now smalltalk has a solution, and IMO the best one.
Is that opinion based on real-world use of Traits? Now that they've been in the base image for a decent length of time, I'm curious to hear of any war stories from using Traits outside of a research context. I've never used them in anger myself, so it would be very interesting to hear from those who have.
Avi
On 12/1/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Hi Avi,
I do not believe that you haven't used the trait concept for real-world problems (no offense).
Klaus,
No offense, but I was asking for practice and you're giving me more theory. My question wasn't about traits. It was about Traits. There's a big difference between using a concept/pattern, and using a particular implementation, and I was asking about the latter. Yes, given that we use traits all the time, Traits ought to be a big win, but I'd love to see some evidence to confirm that.
Avi
Avi, what about 3.9's
ProtoObject #() Object #()
Behavior #('superclass' 'methodDict' 'format') ClassDescription #('instanceVariables' 'organization') Class #('subclasses' 'name' 'classPool' 'sharedPools' 'environment' 'category' 'traitComposition' 'localSelectors') [ ... all the Metaclasses ... ] Metaclass #('thisClass' 'traitComposition' 'localSelectors')
There it is, a particular non-trivial implementation, in form of open heart surgery ;-)
Okay the work on Collection (in the paper) doesn't count that much *but* the above is real-world.
/Klaus
On Fri, 01 Dec 2006 22:53:30 +0100, Av wrote:
On 12/1/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Hi Avi,
I do not believe that you haven't used the trait concept for real-world problems (no offense).
Klaus,
No offense, but I was asking for practice and you're giving me more theory. My question wasn't about traits. It was about Traits. There's a big difference between using a concept/pattern, and using a particular implementation, and I was asking about the latter. Yes, given that we use traits all the time, Traits ought to be a big win, but I'd love to see some evidence to confirm that.
Avi
On 12/1/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
There it is, a particular non-trivial implementation, in form of open heart surgery ;-)
Did you implement it? I'm looking for experiences, not artifacts. And since this was done as part of the implementation of Traits themselves, it's not the ideal example.
Avi
On Fri, 01 Dec 2006 23:59:15 +0100, Avi Bryant wrote:
On 12/1/06, Klaus D. Witzel wrote:
There it is, a particular non-trivial implementation, in form of open heart surgery ;-)
Did you implement it? I'm looking for experiences, not artifacts.
Stupid me. I should either better understand the difference or go to sleep :)
Sorry. But I'm shure the Traits developers will speak up.
And since this was done as part of the implementation of Traits themselves, it's not the ideal example.
IC.
/Klaus
Avi
The real problem is bootstrapping (not the language but the use). We could not use traits before 3.9 (if you want to have real experiences and not toys) And to get traits benefices you need to have multiple inheritance problems, ie not trivial cases.
Lukas you mentioned to me once a cool place in seaside where traits would really help. But again we cannot change seaside. So bootstrap.
Stef
Lukas you mentioned to me once a cool place in seaside where traits would really help. But again we cannot change seaside. So bootstrap.
The canvas framework has a lot of duplicated code and/or code that is defined too high in the hierarchy. The framework provides an implementation of the different XHTML tags as specified in [1]. The abstract element (WATagBrush) should only implement the relevant methods (#attributeAt:, #attributeAt:put:, etc.) that are specified in the W3C DOM [2] implementation.
Now XHTML has the so called generic attributes [2] (coreattrs, events, focus, ...). It also has a notion of what can be nested into each other. Moreover there is Seaside that defines different kinds of callbacks, unfortunately not all kinds of callbacks are valid on all elements. To keep it short, there is a lot of orthogonal things going on. Tough it would be easy to put these things into traits and compose them with the right elements. Like this you wouldn't get 11 mostly identical implementations of #callback:, 7 identical implementations of #on:of:, 4 identical implementations of #form:, #extnet:, #width:, #height:, ...
Cheers, Lukas
[1] http://www.w3.org/TR/2002/REC-xhtml1-20020801/dtds.html [2] http://www.w3.org/TR/REC-DOM-Level-1/idl-definitions.html
Now that you mention xhtml: Todd Blanchard's HTMLCSS is a very professional framework
- http://www.squeaksource.com/htmlcssparser
and to his HTML*Node class hierarchy I've added Traits, along the lines of
- http://www.w3.org/TR/xhtml-modularization/abstract_modules.html - http://www.w3.org/TR/html4/sgml/dtd.html
Not much to show, yet. Mainly because I wait for stronger tool support (lazy me ;-)
But send me an email if you want the source code.
/Klaus
On Sat, 02 Dec 2006 10:00:50 +0100, Lukas Renggli wrote:
Lukas you mentioned to me once a cool place in seaside where traits would really help. But again we cannot change seaside. So bootstrap.
The canvas framework has a lot of duplicated code and/or code that is defined too high in the hierarchy. The framework provides an implementation of the different XHTML tags as specified in [1]. The abstract element (WATagBrush) should only implement the relevant methods (#attributeAt:, #attributeAt:put:, etc.) that are specified in the W3C DOM [2] implementation.
Now XHTML has the so called generic attributes [2] (coreattrs, events, focus, ...). It also has a notion of what can be nested into each other. Moreover there is Seaside that defines different kinds of callbacks, unfortunately not all kinds of callbacks are valid on all elements. To keep it short, there is a lot of orthogonal things going on. Tough it would be easy to put these things into traits and compose them with the right elements. Like this you wouldn't get 11 mostly identical implementations of #callback:, 7 identical implementations of #on:of:, 4 identical implementations of #form:, #extnet:, #width:, #height:, ...
Cheers, Lukas
[1] http://www.w3.org/TR/2002/REC-xhtml1-20020801/dtds.html [2] http://www.w3.org/TR/REC-DOM-Level-1/idl-definitions.html
Hi avi
People could not test traits before the implementation was not totally good. Now we have it, there is a first browser that can help, but if nobody build systems with them we will not know. I did not want to refactor squeak to use traits so that people do not complain that we are ....
After the conclusions that we can draw are at the level of our experimentations. So I would love to see traits used (successfully or not). Adrian has a cs that allow you to flatten your code so the risk is quite low.
Stef
Hi Avi,
I do not believe that you haven't used the trait concept for real- world problems (no offense).
Klaus,
No offense, but I was asking for practice and you're giving me more theory. My question wasn't about traits. It was about Traits. There's a big difference between using a concept/pattern, and using a particular implementation, and I was asking about the latter. Yes, given that we use traits all the time, Traits ought to be a big win, but I'd love to see some evidence to confirm that.
Avi
Well honestly no. I have been working on smaller things at the moment so I haven't yet built anything big enough to run into the problems one has with single inheritance. My oppinion is purely based on the papers, but it did seem like the best fit I have seen yet.
In anger?
From: "Avi Bryant" avi.bryant@gmail.com Reply-To: avi@smallthought.com, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Traits in use (was Re: Re: Squeak and Namespaces) Date: Fri, 1 Dec 2006 11:05:38 -0800
On 12/1/06, J J azreal1977@hotmail.com wrote:
Yes, the inheritance model without them has some real problems. And finding a solution is tough. C++'s multiple inheritance? Too complicated. Java's interfaces? Too much work and code duplication. So now smalltalk has a solution, and IMO the best one.
Is that opinion based on real-world use of Traits? Now that they've been in the base image for a decent length of time, I'm curious to hear of any war stories from using Traits outside of a research context. I've never used them in anger myself, so it would be very interesting to hear from those who have.
Avi
_________________________________________________________________ View Athletes Collections with Live Search http://sportmaps.live.com/index.html?source=hmemailtaglinenov06&FORM=MGA...
On 12/1/06, J J azreal1977@hotmail.com wrote:
In anger?
I assume that expression comes from weapons - the difference between shooting at targets and shooting at people. If you'll forgive the bloodthirsty metaphor, Traits makes some nice holes in paper silhouettes but I'm looking for the bodies.
Avi
Haha. Comming from the USA, the land of South Park, etc., I don't get offended by bloodthirsty or even shocking metaphors. :)
Yes, at some point I hope to get in a project big enough to test drive them, but it could be a while. The closest thing I have seen (and what convinced me they were a good idea) was the description of how they are used with the Collection classes. And I was under the impression this was in on 3.9?
From: "Avi Bryant" avi.bryant@gmail.com Reply-To: avi@smallthought.com, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: RE: Traits in use (was Re: Re: Squeak and Namespaces) Date: Fri, 1 Dec 2006 14:01:11 -0800
On 12/1/06, J J azreal1977@hotmail.com wrote:
In anger?
I assume that expression comes from weapons - the difference between shooting at targets and shooting at people. If you'll forgive the bloodthirsty metaphor, Traits makes some nice holes in paper silhouettes but I'm looking for the bodies.
Avi
_________________________________________________________________ Get the latest Windows Live Messenger 8.1 Beta version. Join now. http://ideas.live.com
squeak-dev@lists.squeakfoundation.org
-
Avi Bryant -
J J -
Klaus D. Witzel -
Lukas Renggli -
Philippe Marschall -
stephane ducasse -
tim Rowledge