On 12/1/06, J J <[hidden email]> 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 <[hidden email]> 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; [hidden email]; 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 -- Lukas Renggli http://www.lukas-renggli.ch |
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; [hidden email]; http://www.rowledge.org/tim Logic: The art of being wrong with confidence... |
In reply to this post by Lukas Renggli
2006/12/1, Lukas Renggli <[hidden email]>:
> > 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 |
In reply to this post by Avi Bryant
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 <[hidden email]> 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 > > |
In reply to this post by Avi Bryant
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" <[hidden email]> >Reply-To: [hidden email], The general-purpose Squeak developers >list<[hidden email]> >To: "The general-purpose Squeak developers >list"<[hidden email]> >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 <[hidden email]> 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 AthleteÂ’s Collections with Live Search http://sportmaps.live.com/index.html?source=hmemailtaglinenov06&FORM=MGAC01 |
In reply to this post by timrowledge
>From: tim Rowledge <[hidden email]>
>Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: [hidden email], The general-purpose Squeak developers >list<[hidden email]> >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 <[hidden email]> 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; [hidden email]; 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://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk |
In reply to this post by Klaus D. Witzel
On 12/1/06, Klaus D. Witzel <[hidden email]> 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 |
In reply to this post by J J-6
On 12/1/06, J J <[hidden email]> 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" <[hidden email]> >Reply-To: [hidden email], The general-purpose Squeak developers >list<[hidden email]> >To: "The general-purpose Squeak developers >list"<[hidden email]> >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 <[hidden email]> 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 |
In reply to this post by Avi Bryant
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 <[hidden email]> 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 <[hidden email]> 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 > > |
In reply to this post by Avi Bryant
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 > > |
In reply to this post by Klaus D. Witzel
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 -- Lukas Renggli http://www.lukas-renggli.ch |
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 > |
Free forum by Nabble | Edit this page |