OK I did, but I meant something different.

The full quote is

> Most of us are stuck with an older version of Perl before the team decides to upgrade, so it would be very important for acceptance if the "sexy" syntax could already be run there.

My job environment used to work with 5.16 until 1-2 years ago, we are now on 5.24 and may upgrade with the same cycle.

The "halfbacked" OO model² I'm showing is a demo for my macro system which should already work with 5.8 or at least 5.10.

I know of people who are stuck with 5.6 (AIX?) but "I never said" or meant to say that most of us are stuck with < 5.14 or something similar.

(UPDATE: What I meant is that if we add a new OO syntax into Perl5, it would be a huge advantage if older versions (last 10 years?) could easily emulate it right away! )

My approach of minimal dependencies is based on the assumption of

• a tested and debugged technology because of long use
• a safe fallback if a component of the (minimal) tool-chain fails
• an appeal for module authors who want to address older versions °
• maximum security that the features won't be deprecated soon
• Last but not least: I lost faith into the operability P5P

let me give you examples

• has

my TYPE $instance_var :has

might look uglier in your eyes than

has TYPE $instance_var

But in the next step I could introduce a macro has which simply translates the later syntax into the former.

That's a very simply transform:

has TYPE $var REST -> my TYPE $var :has REST

• Keyword::Simple

Or I like to use Keyword::Simple to activate macro SOMETHING but I love to be sure that I can always fall back to use macro SOMETHING if Lukas stops maintaining Keyword::Simple for whatever reason.

I have big problems with all* these big projects which are "far ahead" by recombining many different technologies like Devel::XDeclare or was it Xdevel::Declare and meddle extremely with the parser.

These are predisposed to have conflicts with other extensions and create possible maintenance nightmares.

So these are my strategical thoughts.

Saying this I'm irritated by your approach of trying to tell me that I rather have to work on other projects which don't follow my philosophy.

To the degree that you participated at one of my talks about function signatures and criticized me for not knowing your favorite signature module. I did extensive research on 10+ other sig-modules on CPAN and nobody else in the audience seemed to have heard of your kafka-something.

In short: my approach is technological yours is political.

You want me to follow your agenda of reviving advanced but abandoned modules with huge dependencies chains.

Sorry, wont happen ;-P

footnotes

°) If I remember correctly did Corion just write a source filter to support the experimental function signatures, just because he wanted his code to work with older versions.

*) how many are there already???

²) I'm very far from being a M[o[o[se]]] expert