Initial core port of "Squeak Traits"

[Brian Rice]

Some more thoughts follow, after I had time to sleep on it.

On Nov 18, 2005, at 5:22 PM, Brian Rice wrote:

> On Nov 16, 2005, at 6:23 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.
>
> One solution I had considered was to somehow make services query  
> methods that could be dispatched on multiple objects, so that  
> interactions could be defined. But this seems complicated and  
> nebulous.

It also seems like it would create implicit interpretations, which is  
generally not something I want to subject people to, so I'm dropping  
this idea. To explain, I don't want services to ever be confused with  
actual methods installed on Trait objects, should the user choose to  
use Trait objects this way.

> On the other hand, having written this explanation now, raising it  
> as an error does seem like a viable option, just to say "I wasn't  
> composed of this Trait, so it doesn't resolve with me - figure out  
> what it should be yourself".

On further thought, this is not really an error condition, but  
perhaps might be a warning.

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.

> Does this make sense to anyone? Are there conclusions reached here  
> that don't make sense or could make more sense given a change in  
> perspective? Let me know so I get a better perspective on all of this.

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