I'm sticking with the old.

From what I read, the rationale for this new thing is to be an MVP of OO syntax for those familiar with other languages to port stuff easily to core Perl without having to worry about Moo, etc. While that's fine, it isn't my use case.

Probably 90% of the OO code I write is classic bless() stuff. When I need/want a bit more it's Class::Tiny for maybe 8% and on those rare occasions even more is wanted then it's Moo for that final 2%. It really doesn't feel like I'm missing out on anything by continuing with this approach.

I'm also sticking with bless() for now. For my use cases, it is still the most flexible way of doing things. I often need to run code before and after SUPER::new(), and i have quite a few modules that have multiple new() functions, depending on how i want/need to initialize them. And factory classes, multiple inheritance, etc...

Not to mention that rewriting a lot of my (tested and proven to work) codebase would be a huge undertaking, and mixing OO systems within a project seems like a very bad idea.

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
Also check out my sisters artwork and my weekly webcomics

I am using perlclass syntax whenever I write a new module, and I often rewrite an existing one when I make other changes to it.

I had moved from blessed classes to Moose long ago and found it rewarding to rewrite when I touched old code. I find Moo(se) classes easier to read and Moo(se) brings a lot of convenience (validation, delegations, coercions) so that I could eliminate some subroutines.

The new core OOP still lacks most of these convenience features, I just shrug it away... because I can afford it.

Some random observations:

• I prefer the core OOP keywords to Moo(se) syntax. Moose was a game changer, and also a showcase what you can do with the Perl interpreter, but it is bound to Perl syntax with its imported routines. Moose took care for that by defining conventions:
  has 'x' => (is => 'rw', isa => 'Int');
  That is a clever use of the fat comma and superfluous parentheses. To the Perl interpreter it looks the same as the less readable alternatives
  

  has('x','is','rw','isa','Int');
  has(qw/x is rw isa Int/);
  [download]

  In core OOP, you write:
  field $x :reader :writer; # no types (yet)
  To be fair, this has its own quirks due to the way attributes are parsed by the interpreter. One can write that like that:
  field $x : reader writer;
  This is quite a challenge for syntax-aware editors...
• Core OOP has no roles (yet). I usually work around that by converting the role to a class and making its objects fields of the class "consuming" the role. Several times I found that I actually prefer this "has-a" relationship.
• The Perl debugger and various data dumpers and serializers do not (yet) work on core objects. I like to use the debugger, my approach is cheating: I use Feature::Compat::Class and let it fall back to Object::Pad which provides a meta object protocol which can be used by the debugger.

While I have to admit that the new syntax looks a lot nicer, a downside is that I feel obligated to indent everything inside the class{} block which means my entire implementation ends up with an extra layer of indent.

Combined with the version requirements (and how most of my CPAN modules aim for older compatibility) and the fact that I'm constantly using lazy-build and coerce, I don't think I'll be using it any time soon.

As an old-school, stubborn bless adherer I'm not going to advocate for the new class system. But I don't think that

a downside is that I feel obligated to indent everything inside the class{} block

is an issue. class can be used the same way as package in block or statement syntax. See class.

Greetings,
🐻

$gryYup$d0ylprbpriprrYpkJl2xyl~rzg??P~5lp2hyl0p$

I feel the same about package with a block.

Oh interesting, I hadn't seen that syntax option before. Clearly I'm not keeping very close tabs on the progress of the feature.

To me the project to come up with a new OOP system and integrate it into core Perl always seemed like a solution in search of a problem. And the problem that it aimed at had already been solved, over and over.

Personally and at $work I use Moo any time I need a class or a role, since I find it to be the perfect balance between functionality and simplicity. The new stuff lacks the majority of the functionality I use Moo for and doesn't appear to be significantly simpler to use, if at all. And having it be in core is irrelevant to me. I embrace a plethora of well-made modules from CPAN to get my programming done, and that's definitely not going to change. So I'm going to pass.

Correction: Feature::Compat::Class claims to support 5.14, but depends on Object::Pad which requires a minimum of 5.18.

I usually use classic perl bless for my object code, though I have been very excited about the new class feature and have written lots of private code and a few small modules on CPAN using it. I was a very vocal fan of the feature back when Ovid was posting updates about his studies on the methodology of OO systems that were the foundation for the Corinna project.

However, I have not been using the class feature as much lately. Simply because implementation is slow and perl devs keep saying "don't use it in production". At this pace, it's looking like a 10-year implementation, ala Perl6-style problem. There is a chicken-egg mentality that seems to be happening. Comments about being uncertain about moving forward because devs are not sure if people are actually using it or testing it vs comments about how it's "not ready for production use" all from the same people. I would like to see the pace picked up quite a bit. Otherwise, the fanfare will continue to decline, and even I will lose interest in it. Certainly, there are fine modules that implement OO systems like moo(se) and even more concise ones like H2O.

In my personal view, core class development needs to increase its pace to implement the most highly anticipated features that many are hopeful for. This would make it more viable for common programmers to implement. Also, there needs to be some sort of real expectation as to when some portion (and what portion?) will move out of experimental so that end users can see light at the end of this tunnel.

Regarding, Util::H2O, I created Util::H2O::More originally because I thought it'd be nice to have a bless that gave accessors like h2o. This is where baptise came from. I feel like of p5p provided just that, a "bless that gave accessors," there'd be little need for much else core-related to OOP.