Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

Thanks for your feedback! I'll try to address your points as clearly as I can. You've stated your positions fairly strongly and I may not convince you, but I need to address this for others.

Before I address your points, there's an overriding point which must be taken into account. Barring something going horribly wrong, it's going to be part of the Perl language. People can work to support it or improve it, but stopping it isn't likely. So rather than focus on what you think should be done, maybe focus on what can be done? Help improve it instead of throwing stones.

I see no need to clutter the Perl core with this or any other OO framework.

Perl's core OO facilities are so primitive that there are around 100 or so OO systems on the CPAN trying to "improve" it. Most of them are to scratch personal itches (usually around attribute access) and fall far short of what a robust system needs. What's worse is that most of them are broken in numerous ways.

When I work for clients, one of the main problems they face is the time it takes for their developers to get up to speed on whatever OO system they're using (I often stumble on brand-new OO systems that, again, developers have to learn). Even Python 2, whose OO system is abominable, manages to have just enough of a sugar layer that people have stuck with it. We need that "just enough" sugar layer, but "good enough" isn't good enough if we want to offer something compelling to new developers.

The current options including bless, which is in the core, are more than adequate, and offer choice to the Perl programmer.

bless isn't going away. If you want to drop to that level, go ahead! We're not taking anything away.

The syntax is unfamiliar and IMHO unPerlish.

New syntax is always unfamiliar. I still remember when our was introduced and people were confused about how to use it. And let's not even begin to discuss the debates around Moose, even though Moose and its spin-offs have clearly won the OO war.

As for whether or not it's "unPerlish", that's very subjective. I've worked hard to try to not make it too different and I've been onboarding advice from both new developers and old. The general consensus has been "ok, that leverages things we already know." The objections have been technical. The syntax generally doesn't scare them. I realize that not everyone will agree.

The name is awful, combination of cutsey 21st Century non-word and the British euphemism for God.

The name is not a "combination of cutsey 21st Century non-word and the British euphemism for God." It's short for "Corinna", a love interest of the poet Ovid. But this isn't a real objection and, over time, it will no longer exist because this will be part of the language.

What's wrong with Moo?

Oh, where do I start? Where do I stop?

The Moo/se family of languages have generally won the "OO wars" in the language, but that's only because they were so much better than the alternatives, not that they were the "right" way to approach things. Stevan Little, the creator of Moose, agrees that there were tons of design mistakes made, but that's to be understood in creating something new. Matt Trout, the creator of Moo, agrees, in principle, with many of the design directions of Cor (though we often disagree on implementation details). Let me list some issues.

  • Moo/se conflates instance data and data access. This is terrible for maintenance of large-scale systems.
  • Method modifiers for roles break the associative/commutative contract that roles were supposed to offer.
  • Method modifiers in general are a lazy way to avoid thinking about how and when to actually call methods.
  • Moo/se must use heuristics and helper modules to distinguish between methods and subroutines.
  • Moo/se is complicated enough that it's harder to optimize because so many edge cases would have to be pushed down to the C level were it to go core.
  • Moo->meta is sort of a no-op, but allows calling the MOP, requiring an inflation of Moo to Moose, thus requiring Moose and its myriad dependencies to be in core.

The above list isn't exhaustive and it's not well-explained because I don't feel like retyping the wiki, many emails, or extensive IRC communications on the topic.

And looking at Moo, it's trivial to add attributes with ro, rw, or rwp. All of those offer the wrong affordance for minimizing the public contract of your object. I'm designing something that's easier for beginners to use, but it also easier for large-scale codebases to manage. Just create a DBIx::Class instance in your debugger and type m $result and be amazed at how many methods it offers. Many of them are helper functions and not methods. Many of them should be private methods that you should never call. Real developers get bit by those things all the time. It's time to end the madness of 100+ object systems and make something that not only works, but offers the right affordances for building solid code.

I realize I may not have satisfied you and that's OK. I don't expect everyone to agree. But even amongst my detractors who are heavily, publicly involved in the language, there's general agreement that Cor is a good way to go.


In reply to Re^2: Cor—An object system for the Perl core by Ovid
in thread Cor—An object system for the Perl core by Ovid

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (3)
As of 2024-03-29 02:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found