Per TAG vote, moved to Public Discussion. http://lang.lucee.org/t/tag-meeting-minutes-november-24th-8pm-utc/259/2

My position has drifted somewhat since I raised this.

1. The CFML implementation should not do anything ColdFusion doesn't do. So this should not be considered in that context.

2. One of the challenges this would have mitigated in CFML is that included functions don't contribute to interface compliance (should that be what the mix-in is being used for). However for .lucee you probably shouldn't bother implementing interfaces anyhow, so it's moot.

3. One handy thing with mix-ins is that one can have standardised function names in the mix-in, and then rename them during the mixing-in process to match the requirements of the class they're being mixed-in to. Also method access can be controlled too. This is the one area they trump dumb includes. However I dunno how much benefit this is.

4. I have close to zero interest in .lucee (the mooted "language", not the general LAS project), so it seems "inappropriate" for me to be suggesting feature requests for it.

So can I downvote my own ticket?

I created a language forum topic in which to discuss the topic here: http://lang.lucee.org/t/implementing-native-mixin-functionality-for-components/262

We should carry on the conversation there (happy to modify the topic description too, please DM me if you feel its off).

Based on Kai's input, moving to Public Consultation (with the expectation, at least from me, that we'll find the existing functionality to be satisfactory and will reject this ticket

Since Lucee allows multiple definitions of a function with last-definition-wins, you have control over whether "local" definitions (in the CFC) override the mixin or not, based on the position of the include (although someone should verify that). I'd be fairly certain – pending Adam's investigations – that including a CFC would override inherited methods, since the include is going to bring in method definitions at runtime.

I think we'd agree that from a functionality point of view, a simple include in CFML can do very similar things to what Traits and Modules in their respective languages do.

Traits seem to have a quite a bit of rules and definitions around what happens when it comes to overriding methods for instance - I'm not sure what would happen in various of the scenarios listed here http://php.net/manual/en/language.oop5.traits.php when trying to rebuild them with CFML includes.

I'm not fundamentally opposed to investigating such a concept, however, I'd like someone (maybe ) to investigate a bit further what's currently possible with CFML, how the current "implementation" with includes would work for those example cases with Traits in PHP and if there's anything that can't be easily done at the moment.