Re^2: Open to debate on mixins and traits.

[BrowserUk]

I don't actually see the namespace issue being a major problem, it was just something that came up whilst I was reading/thinking about mixins/traits/roles.

I think I envisage that there would be a dozen (or two at most) major mixin APIs along the lines of those I mentioned in the OP.

For the most part, these APIs would override the names of built-ins. Eg. The is Compressed and is Encrypted Roles would override the readline() and writeline() built-ins such that reading from a file would cause the data to be decompressed and/or deencrypted with printing to a file reversing the process.

If both are used on the same file, then the overrides would nest in whichever order the Roles are initially loaded? Configuration parameters to the Role would be passed as arguments to the use line? After which there would be little need for further direct interaction between the host class and the Role?

In effect, most Roles would be similar to ties in that they would present predefined APIs with "well-known names" to their callers. Hence my inviting comparison with Java interfaces.

There would probably be many implementations of each Role, (zip, gzip arc etc.), but each would comply to the same API thereby allowing the substitution of one implementation for another without the need for the hosting module to change.

It's not clear to me how a particular implementation of a Role would be selected for a given application nor how you would select a specific implementation (perhaps also through the use time configuration). Harder to envisage is how one might use two or more implementations of the same Role simultaneously, but that will probaly become clearer once we get a bit more information (E12?).

It will be quite interesting to observe the debate on what 'standard# Roles shoudl exist and what there APIs should be. It will become quite fundemental that these are 'done right first time' as once they becomes established, they will effectively becomes standard extensions to the language with all the hysterysis against change and evolution that that implies.

It's fun to think about how they might evolve, but I guess I am being somewhat premature in my thinking and will need to wait for LW, TheDamian et al to publish more information before trying to draw any real conclusions.

[bsb]

I think you and I are on different trips here. I don't know what the real story is though.

I don't see why Perl needs interfaces in any form, they're just there to satisfy the compiler in statically typed languages, aren't they?

I think of roles as reuseable partial classes. So they add generic behaviour, customized by the state accessors they use (or metadata). I'm more going from the paper than A12, though.

[chromatic]

I don't see why Perl needs interfaces in any form, they're just there to satisfy the compiler in statically typed languages, aren't they?

Barring my opinion that Java interfaces are so far broken they're almost worse than not even attempting to solve the problem, no.

Type systems aren't only for statically typed languages. They're useful in dynamic systems as well as systems which can't do every type check at compile time. (These two categories overlap a bit.)

The nice thing about having language support for interfaces in your type system is being able to check that an object you've received somehow conforms to the interface you expect to use with it. It's a little nicer if the language can check that for you (whether statically, at compile time, dynamically, or at runtime), but at worse, you can also check it yourself.

[adrianh]

I don't see why Perl needs interfaces in any form, they're just there to satisfy the compiler in statically typed languages, aren't they?

No they're not ;-) Not if we're using the term as used in Java land anyway. They're a way of talking about common behaviour that cuts across class hierarchy boundaries.

In Perl 6 they're subsumed by roles (a Java interface would the equivalent to a role without any implementation code.)

(Note: Apply my standard "I've not read A12 properly yet" disclaimer to the previous sentence, but I'm sure chromatic will correct me if I'm wrong :-)

[BrowserUk]

I don't see why Perl needs interfaces in any form, they're just there to satisfy the compiler in statically typed languages, aren't they?

Sorry! My fault. It doesn't. It won't. It can't. Never, never, never. Forget I used the words!