Ooops, didn't hit reply all. ---------- Forwarded message --------- From: Bill Ricker <[email protected]> Date: Mon, Nov 25, 2024 at 12:17 PM Subject: Re: [Boston.pm] State of perl art for oo To: <[email protected]>
On Mon, Nov 25, 2024 at 10:10 AM <[email protected]> wrote: > I've heard of moose, and seen some examples, but never used it. > Ive never heard of corinna until Bill's email yesterday, > At which point i read some tutorials and watched at least 1 video, > And i love, love, love the compactness of corinna. > Yeah. Single inheritance is... eh... fine. > Right. Having done various forms of M.I. in several languages, the use of mix-in interfaces as a way to formalize duck-typing (so one can ask rather than $thing can 'stringify' instead ask if it (implicitly, its class) implements 'FreezeThaw' ). All the good parts of M.I. without the bad parts, really. The only thing that gives me pause is that its > experimemtal, and all things perl related seem to > take years to sort out whether they will last or not. > > Granted a lot of that is from the years and years of > talk about perl 6. I dont -think- corinna is amother > Perl6 development. Right. They're doing it iteratively with consensus instead of big-bang to avoid the previous nightmare. The current cabal are doing better about promoting things out of experimental <https://perldoc.perl.org/perlexperiment#Accepted-features>. I would NOT use experimental `use class` for client production work today, but would consider using Object::Pad via Feature::Compat::Class for greenfield client work. But workity-work-work typically has a legacy ORM class framework already so not an issue. I see sufficient momentum in the current cabal process that I think this is going to work, so starting using Corinna (via O:P &/or F:C:C or straight up) on personal projects seems to be sensible (as i documented in Boston PM meeting history linked up-thread). I think there are only 4 keywords. > So far. I except there maybe others, but minimizing keyword bloat seems an implicit requirement from the compiler stability lobby, so likely to continue. One thing i like about Corinna (*use feature 'class'*) is that it plays nicely with modern subroutine signature <https://perldoc.perl.org/perlsub#Signatures> declarations (*use feature 'signatures'*). Since it's layered upon modern Perl, Corrina didn't need to implement syntax filtering to implement signatures. (Why did it take so long to get proper signatures in Core? Because we had to adopt* :attributes *in Core to have a way to avoid losing prototypes when enabling signatures first.) But i read posts from 2 years ago about corinna being > A thing, and its still not a thing. I dont have a good > sense for how much longer it might be to complete. It will be a LONG time before Corinna shipped in core is 'done' (e.g., capable of introspection, no features in experimental). But it is time to start tracking it. -- Bill Ricker [email protected] https://www.linkedin.com/in/n1vux _______________________________________________ Boston-pm mailing list [email protected] https://mail.pm.org/mailman/listinfo/boston-pm
