|Syntactic Confectionery Delight|
<generic cop-out>I was kind of limiting my thoughts to Perl:) </generic cop-out>
Aspect Oriented Programming is an obvious fifth direction that some people are taking.
That said, from my limited (and hastily reviewed), understanding of AOP, it isn't an means of implementation (be done), it's a ... um ... philosophy.
It doesn't even have to involve objects (their claim). It basically says that the logical architecture doesn't have to be either a single-rooted tree nor a multi-root tree, it can be a graph. Which, as far as my math goes means that you can stick things in anywhere and cross-connect them however you like.
There is (are?) concrete implementation(s) of AOP (Aspectj and ?). I don't know how they are implemented, but I suspect that it basically comes down to essentially the same as mixins/traits in that extra methods get attached directly or indirectly to the vtable.
The difference is the logical view rather than the physical implementation. The basic goals are the same as mixins: The separation and re-use of common functionality without imposing super-dependant structure on the logical view of the system.
Creating a new language that incorporated the cross-cutting concern (in AOP speak) as part of the core language would be a sixth.
Isn't that exactly what the :trait notation of P6 is doing?
Sticking the common behaviour in a meta-class in those languages that support them would be a seventh.
I think that I would view this as the same as my second option; "Built-in to the base (universal) Object class", if the meta-class is the base meta-class.
If your not proposing sticking the common behaviour in the base meta-class, but into meta-classes for each of your real classes, then all you've done is move the goal posts. You would still end up with cut&paste re-use, or one of the four options.
Examine what is said, not who speaks."Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail