|
in reply to Re^2: The Corinna RFC for getting modern OO into the Perl core is taking shape
in thread The Corinna RFC for getting modern OO into the Perl core is taking shape
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.
|
Re^4: The Corinna RFC for getting modern OO into the Perl core is taking shape
by bliako (Monsignor) on Sep 14, 2021 at 18:48 UTC
|
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 | [reply] |
Re^4: The Corinna RFC for getting modern OO into the Perl core is taking shape
by shmem (Chancellor) on Sep 14, 2021 at 22:02 UTC
|
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] |
|
|
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.
| [reply] |
|
|
