|
in reply to The Corinna RFC for getting modern OO into the Perl core is taking shape
I’m very happy to see this. Thank you Ovid and TheDamian and stvn and everyone else. A fast implementation of meta-object programming in the Perl core? Way cool.
I think we can afford to focus on the positives right now; it’s too early to say that there will be long-term negatives. It’s early days, and whatever the first results of Corinna are, they’ll be built upon. I think Ovid & Co. have been very up-front about the plan to start somewhat smaller and limited and why it has to be that way. Think about where we might be in 5 years. If this project goes well, what will the active Perl world be doing for OO? I suspect it’ll be a mixture of:
Building software directly on what Corinna has become by then. Building software on one or more new, extended frameworks that use Corinna under the hood (in somewhat the same way as our existing frameworks use “Classic” Perl OO under the hood). Building new software and maintaining existing software on Moose/Moos/Moo/Mo, Class::Accessor and friends, Class::MethodMaker, Object::InsideOut, Object::Tiny, Class::Prototyped, Class::YourFavoriteHere, and whatever else people feel like using, because all that’s still going to be around.
I feel there’s no reason any Perl fan should be worried about Corrina. Corinna isn’t going to harm Moose or Moo and the many codebases that use them, any more than they harmed Class::Accessor and friends. Classic Perl OO will never go away.
This isn’t to say that I love the current MVP design. I don’t. But that’s OK. (For one thing, nobody asked me.) If Corrina is a success, it will naturally — if not in Core-inna then by way of CPAN extensions — come to somehow support most of what is in the mainstream of current development practice. That’s just the way of things, but also I suspect that only a minority of developers are quite as opinionated as the MVP design is. However, if Corinna proves to be a rock-solid base with speed and power, then other developers will build what they want on that base if Corinna itself doesn’t have what they want. Those extensions will still garner all the advantages that Corrina brings, besides what they (opinionatedly) reject. What’s not to like?
I’ll reply elsewhere with my armchair objections to bits of the MVP.
– Aaron
Preliminary operational tests were inconclusive. (The damn thing blew up.)
|
Re^2: The Corinna RFC for getting modern OO into the Perl core is taking shape
by Radiola (Monk) on Sep 13, 2021 at 05:20 UTC
|
Edit: I know I'm not the first person to say any of this. In particular, the immutability
topic is huge, and its proponents have good arguments. I just don't think they're as universally
applicable as some do.
A couple armchair thoughts about where I think Corinna MVP design is too
opinionated, bearing in mind that it is an MVP. (I’m more interested in
thinking about the larger philosophical issues than quibbling about the MVP
proper. I’m nobody, I’m not working on Corrina, I’m not trying to change
Corinna.)
Only supporting v1.2.3 triplet semantic versioning. It seems to me
there are two main versioning patterns among Perl modules: v-string-like version
triplets (semantic or not), and decimal numbers like 1.23 (e.g. MAJOR.MINOR
where both are integers of arbitrary size, usually small). I understand not
wanting to support every variation in Perl module versioning. However, there’s
nothing wrong with decimal, and if it’s not the most common method it’s surely
close. I don’t think Corinna has to translate one to the other, just support
both styles on their own terms and croak if something tries to compare
v1.2.3 to 1.23. Not supporting decimal numbers right off the bat seems like
a gratuitous incompatibility. No native way to support read/write accessors. (Yes, I understand you
can make them with methods if you want them even now.) I wholeheartedly reject
that mere use of a read/write accessor is necessarily a “code smell”. It’s a
natural way to program and in itself is neutral. (You have to train yourself to
think in terms of immutable objects; I’m pretty sure it’s the training that
makes most of the difference in the end, not the immutable objects, or separate
accessors, or what-have-you.)
That said, not allowing it does prevent certain mistakes when having to
program it manually, but the whole point of a framework is so we don’t have to
program it manually. Multi-method dispatch would be cool, but it’s still a
cop-out.
I suspect that if Corinna is a success (and I truly
hope it will be) those things will be added, the MVP spec notwithstanding. I kinda
doubt it’ll get into the Perl core otherwise.
Neither issue dampens my excitement about the project as a whole. I very
much look forward to using version 2.0. :D
– Aaron
Preliminary operational tests were inconclusive. (The damn thing blew up.)
| [reply]
[d/l]
[select] |
|
|
You were concerned about Corinna MVP only supporting semver. Please see the README's Principle of Parsimony:
Many things in the proposal are deliberately restrictive, such as Corinna only allowing single inheritance. This is to allow Corinna to be cautious in not promising too much. If we later find this too restrictive, we can allow multiple inheritance. However, if we start with multiple inheritance and discover we don't need or want multiple inheritance, we would break existing code by taking it away. Any proposals to change the RFC must consider the principle of parsimony.
Semver falls under this. If we allow more than semver and it's a mistake, it may be too late to change it. If it's too restrictive, it's trivial to say "we can add support for more version formats."
The MVP isn't designed to take anything away. It's designed to offer something we can play with and find out what works and what doesn't.
| [reply] |
|
|
If we later find this too restrictive, we can allow multiple inheritance. However, if we start with multiple inheritance and discover we don't need or want multiple inheritance, we would break existing code by taking it away.
It sounds (EDIT: adding MI) simple but it is not, not only technically but also in terms of managing users who adopted it already. Neither option (EDIT: later adding or removing MI) is, actually. (Personally I think it would be way too complex to have MI: semantics, rules of inheritance and implementation on ancient (right?) Perl interpreter internals. I have never used it with C++ and never missed it with Java. But my point is not about MI, EDIT: i.e. let's not have a discussion if MI is needed right now and here, on this subthread)
bw (and good luck with Corinna), bliako | [reply] |
|
|
Many things in the proposal are deliberately restrictive, such as Corinna only allowing single inheritance. This is to allow Corinna to be cautious in not promising too much. If we later find this too restrictive, we can allow multiple inheritance. However, if we start with multiple inheritance and discover we don't need or want multiple inheritance, we would break existing code by taking it away. Any proposals to change the RFC must consider the principle of parsimony.
In practical perl, multiple inheritance is used, composition is used, delegation is used, roles are used. None of these concepts or their usages are going away.
Making use of two backronyms, I'd say that you are too much inclined towards the "Pathologically Eclectic Rubbish Lister" notion and not so towards the "Practical Extraction and Report Language".
To put it bluntly: I'm just your average programming Joe, with no degree in Math or CS whatsoever. If I was to adopt a better perl OO in-core approach, I'd like very much to take it piecemeal, adopting each part as I am fit to do so. I want guidance, not restrictions. Your approach is far too much academic to my taste and needs, and it imposes a learning curve too steep for me to climb, at that age. After all, python might be a better choice, boring as it might be.
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] |
|
|
|
|
Only supporting v1.2.3 triplet semantic versioning.
I wouldn't go as far as to call it a "gratuitous incompatibility" since there are no Corinna classes right now which would break because of this. But I agree with you that having decimals would be good: Semantic versioning can be an obstacle in early Corinna adoption. If I want to migrate an existing old-style OO class to Corinna while keeping the API, I would need to change from decimal to semantic - and, worse, users of the class might need to change their code, too.
No native way to support read/write accessors.
I'm not sure what you're expecting here? Corinna attributes can be declared to create reader and writer methods, for example:
slot $name :reader :writer
This creates a ->name method to read, and a set_name($new_name) method to overwrite the value, much in the style of MooseX::SemiAffordanceAccessor. You can not use the same name for reader and writer, though (which in my opinion is a good thing).
| [reply]
[d/l] |
|
|
Only supporting v1.2.3 triplet semantic versioning.
I wouldn't go as far as to call it a "gratuitous incompatibility" since there are no Corinna classes right now which would break because of this. But I agree with you that having decimals would be good: Semantic versioning can be an obstacle in early Corinna adoption. If I want to migrate an existing old-style OO class to Corinna while keeping the API, I would need to change from decimal to semantic - and, worse, users of the class might need to change their code, too.
It's the latter concerns that I consider to be incompatibilities. Corinna isn't coming onto a blank stage. It's part of Perl and has to interoperate with what's out there. Particularly if it ever is going to be able to subclass existing modules (which I don't believe is on the table for the MVP) it needs to support the versioning scheme that those modules use.
No native way to support read/write accessors.
I'm not sure what you're expecting here?
Yeah, I let myself confound the issue of immutability with read/write accessors using the same name. To be fair, the overview (which is what I had read most recently) takes the opportunity to take shots at both at about the same time, too.
But now I think I didn't read the RFC carefully enough, because it appears to be at odds with the Overview on the subject of :reader/:writer on attributes. The Overview says under Helper Attributes:
The writer creates a method called set_$name to avoid overloading the meaning of the method name, and will return the invocant. Setting :reader($name) and :writer($name) to the same $name would be an error.
Whereas the RFC section 6.2.3.3 says:
If you explicity (sic) set the name of the writer to the name of the slot, there will be a special case to allow ->method for reading and ->method($new_value) for writing
So it looks like that's been changed? Or am I missing something else?
– Aaron
Preliminary operational tests were inconclusive. (The damn thing blew up.)
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
