Initial core port of "Squeak Traits"

[Brian Rice]

I just experienced a "big-picture moment" where I realized that the  
logical implication of having two Trait objects collaborate on a  
service means that the service installation should generate  
*multiple* methods.

This is obvious in the sense that each Trait object has multiple  
users which ultimately result in something concrete. So, say you have  
Trait objects T1 and T2 and N1 objects using T1 and N2 objects using  
T2. So you need N1*N2 methods for any service that dispatches and  
depends on both T1 and T2.

Now, with some inference, this number of method installations is  
actually dependent on M1*M2, where the M's count the number of  
distinct users of each Trait which do not inherit the Trait from any  
other concrete object. And obviously if the users of the two Trait  
objects intersect, that leads to a smaller M as well.

This seems much more straightforward, conceptually, even if heavier  
to use and implement. So this will be the eventual feature once I get  
to it.

On Nov 19, 2005, at 12:13 PM, Brian Rice wrote:

> On Nov 18, 2005, at 5:22 PM, Brian Rice wrote:
>
>> The consequence of this design is that you can perform multiple  
>> dispatch on any concrete objects, plus any number of uses of the  
>> Trait itself, so a binary = method that dispatches to the same  
>> type on both sides is possible. HOWEVER, use of a different Trait  
>> object is not possible yet.
>>
>> Also, the composition factor adds in a problem where the identity  
>> of the component is showing up as a placeholder in the top-level  
>> composition. So if you have A = B + C, then B and C's method are  
>> using B and C as placeholders, but my method of composing services  
>> doesn't replace the use of B and C with the use of A. I could do  
>> that, OR I could solve both problems at once by having every use  
>> of a Trait object in any signature at all go through a  
>> substitution process at the final moment of installation. But even  
>> then I have to know that B and C should translate to the same  
>> thing that A is trying to install to, whereas Trait objects used  
>> but found elsewhere should... I don't know, right now I'm leaning  
>> towards throwing an error and figuring out a sensible resolution  
>> later.
>
> Another solution that occurred to me and seems more natural is to  
> have an option at creation-time to have a "friends list" of Trait  
> objects which should be translated when performing the final build  
> step. I'm not sure what a good protocol for this translation  
> specification is, or whether it can be inferred. Note also that my  
> previous suggestion that I commented on above has this same issue.
>
> One variant approach to a "friends list" is simply to have a  
> TraitAggregation which is a "user" of all of its components and  
> therefore gets notified when they change, acting on it by  
> performing the specified collaborative-transformation. For example,  
> say X and Y refer to each other in the services' roles. We could  
> create a Z which is a pairing of them and whenever their services  
> change, Z goes in and looks for references to Y in X's services and  
> performs a translation to a target type. Z would have to generate  
> both target types, though, or at least know which ones were meant.  
> Consider all of this half-baked and tentative. :)
>
> Since this is apparently a difficult design point and not a  
> critical feature, I will be working on this slowly and mark TODO  
> points in the code. Maybe I'll contact the Trait authors and ask them.

--
-Brian
http://tunes.org/~water/brice.vcf