Also, including use utf8;
causes a lot of Malformed UTF-8 warnings.
Super excited to use this though! Looks so awesome.
]]>MooX::Pression is just a wrapper around the much faster MooX::Press though. If you do use MooX::Pression debug => 1
, you can see what MooX::Pression is passing to MooX::Press.
Just too bad that Corinna doesn't use the syntax proposed in Dios (and used in Raku). That would have been simpler for people living in both worlds.
]]>I think Dios is fantastic. However, making it and its syntax work for core in a way that P5P would be willing to commit to means stripping it down to an MVP, probably rewriting most of it in XS, and, ironically (which I'll explain in a moment), the twigils would likely be a blocker for adoption when it was first proposed—many people are violently against twigils.
The last point is ironic because we might adopt twigils for Corinna simply because they make life so much easier in terms of syntax highlighting, Huffman encoding of meaning, and avoiding variable shadowing.
When I started on Corinna, I had never considered Dios for core because of the scope of Dios (clearly not an MVP) and twigils. And yet here we are, potentially on the cusp of adding twigils (but the Perl parser had no support for the twigil syntax, so that's a huge change to add just for an experimental object system).
Best,
Ovid
I just hope that differences to Raku syntax won't we a requirement for the actual implementation ;-) (not talking about you)
]]>> Corinna doesn't use the syntax proposed in Dios (and used in Raku).
I wonder if it's closer than you think?
First, the names of attributes (fields). Consider this Raku code:
class Account {
has $balance = 0;
method deposit ($amount) {
$balance += $amount;
}
}
my $account = Account.new;
say $account.deposit(5); # 5
say $account.deposit(5); # 10
In Raku, attributes declared `has $foo` are aliased to `$!foo`. (I could have written `$!balance` in the `deposit` method.)
(I would be happy to see Cor stick with `has $foo`. Especially if Perl did a better job with `our` variables than Raku has thus far, double especially if it was done in cooperation with Rakoons so Raku could pick up the same solution(s) to Raku's `our` problems.)
----
The second syntactic difference is also perhaps closer than you realize. This Cor code:
has $foo :bar :baz ...
uses what, in Raku, is called "colon pair" notation. But it strikes me as consistent with Raku in just the right way, and *in*consistent in just the right way too.
First, it would be invalid syntax in Raku, and it jumps out as such. A nice reminder that one is reading Perl code.
Second, the Raku equivalent is to put something in exactly the same grammatical slot, but instead of writing a colon pair, write a verb (eg `is`) followed by... a colon pair! (With the leading colon omitted.)
So one just needs to translate from whatever Cor folk decide to name their colon pairs to what Raku folk decide. I agree it would be nice if they considered, for example, supporting `:rw` as short for `:read :write`. I mean, why not?
----
That all said, Raku *was* carefully designed. I'd say it would really behove Ovid et al to just ask Damian and Larry what they think about things the Cor team are wondering about.
I daresay Larry would feel a great deal of love if Ovid at least asked him about such things.
And if it's about the issue of huffmanizing attribute declarations to keep them private, and anything else that means syntax and semantics consistent with the actor model are embedded into Perl, I daresay it would not only pay back enormously in years to come in respect to love, but also to Perl's great technical advantage.
]]>My idea is
package Foo is class {
}
or
package Foo : class {
}
How about this?
We're trying very hard to avoid overloading the meaning of existing Perl features, so we deliberately didn't go with the word package
. The package
keyword simply declares something as being in a given namespace. The class
keyword in Corinna does the same thing, but it's a historical accident in Perl that classes and packages are sort of the same thing.
In reality, a class
is a data type, not a namespace. They're fundamentally different. While I don't know if it can be fixed, in the long-term, I would love to see the two ideas fully separated in Perl.
Best,
Ovid
https://en.wikipedia.org/wiki/Argument_from_authority
If these people have genuine authority gained from years of hard experience in this field then they will be able to tell us in a few cogent words why Corinna is so much better than Moose and all the other OO systems available on CPAN. They will be able to tell us the mathematical theorems that underlie their work. They will be convincing. But a bald appeal to authority, is not only not convincing, it is also demeaning because it divides Perl people in to two classes, the "hoi poloi" whose thoughts on OO are not thought worth considering and a small remainder whose thoughts, apparently are so valuable that they do not even have to back up their ideas with indefeasible argumentation.
Please could you rewrite the start of this article so that we all know the compelling reasons why Corinna is so good: then the issues can be weighed on their merits genuine or otherwise rather relying on the mere assumption of authority.
]]>Of course, that is not an exhaustive list of all the benefits of the Corinna proposal, but I felt it was enough for a single article.
As for arguing from authority at the start of the article, I don't believe that's what I'm doing. Sure, I do mention that the project is a collaboration by a large number of people who are acknowledged experts in OO Perl, but I specifically say that I mention those contributors merely to reassure the reader, not as an argument in favour of Corinna.
After all, why would I expect the reader to even consider my subsequent arguments for this project, without first establishing that the proposal is likely to be worth their time and effort? Specifically, that it is not some random crazy idea, but has been designed by a group of people with a proven track record in the field.
Yes, arguing from authority is unquestionably fallacious. And, yes, if I had written (or even implied): "This proposal should be adopted because X, Y, and Z worked on it", then that would certainly be an invalid argument.
But simply pointing out that this project has the participation and support of a large number of experts is not the same as arguing for it from authority.
Rather, it's a way of quickly establishing that the project is a serious one, with a wide variety of experienced and credible contributors...before I launch into providing half a dozen actual reasons why it's worth your time to consider. And then conclude by explicitly urging you (and all my readers) to apply the only truly compelling assessment available to you: to investigate it yourself.
]]>Nevertheless, there are some interesting ideas here that I may explore (in lieu of using Knuth-Plass) for PDF::Builder paragraph shaping code.
]]>