|Just another Perl shrine|
Re^2: Open to debate on mixins and traits.by BrowserUk (Pope)
|on Jun 03, 2004 at 09:53 UTC||Need Help??|
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.
Examine what is said, not who speaks."Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail