Re^2: The Corinna RFC for getting modern OO into the Perl core is taking shape

[Radiola]

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.)

1. 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.

2. 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

[Ovid]

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.

[bliako]

I am neutral to Corinna (on the principle of "let all flowers blossom" and respecting others creative effort).

I think that the following statement is simplistic:

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

[shmem]

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.

[Ovid]

You wrote:

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.

The Corinna MVP is designed to support composition, delegation, and roles. It almost sounds like you're suggesting we're taking this away, but we're not, so I must be misunderstanding what you're saying. And if you absolutely need multiple inheritance, we have a special syntax for this very edge case.

Corinna's not taking anything away. It's simply that the MVP is designed to be cautious by nature rather than risk all the missteps Perl has had with given/when, smartmatch, pseudohashes, indirect object syntax, the SUPER bug, and so on. I'm not saying we haven't made mistakes, but rather than shove too many things into Corinna precipitously, we need to understand how the MVP will play out.

After we work out the kinks in the MVP (and we will have them), if you want native MI support in Corinna, lobby for it and start and RFC. You don't even have to implement it yourself. Win enough people to your position and convince someone on P5P to sponsor the work.

[haj]

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).

[Radiola]

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?

[Ovid]

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 wiki is out of date. Specifically, the front page of the repo (the actual RFC part) states:

Anything in the Wiki should be considered "rough drafts."

I've now updated the wiki pages with this text. Sorry for the confusion!

[haj]

So it looks like that's been changed? Or am I missing something else?

Actually, I have missed the special case to set the name of the writer to the reader's, thanks for pointing that out. The README has a guideline about Wiki vs. RFC inconsistencies:

You may be looking for the Wiki as that has much historical discussion of this project. However, the documents in the rfc/ folder will be considered the canonical ones.

There is ongoing discussion on IRC (#cor on libera.chat) and on various GitHub issues. I'd guess that the borderline between "as small as possible" and "make migration of existing code easier" will continue to shift back and forth for some time. Allowing reader=writer is targeted at the Moo* default naming for accessors, but also considered "messy", and the "testbed" Object::Pad (which I'm using for experiments) does not allow it.

Nothing is cast in stone yet.