Feedback on the Moo/se to Corinna porting guide

[Ovid]

I have an incomplete guide to porting Moo/se to Corinna: https://github.com/Ovid/Cor/wiki/Porting-from-Moose-or-Moo

Please leave feedback here.

Yes, it will eventually need to be several documents.

[abraxxa]

Can a class attribute (I hate the term 'field'!) be passed to the constructor by adding :param to its definition?

[Ovid]

@abraxxa By default, no. Constructor args are for creating an instance. You can get make this work with an alternate constructor, but generally, it's good practice—if you must use class data—to have it be immutable if classes use it. Otherwise, you can get nasty "action at a distance."

[jgamble]

I had no idea about the make_immutable method. First, thank you. Second, I had to search with a few keywords, could a direct link be provided, like to https://metacpan.org/dist/Moose/view/lib/Moose/Cookbook/Basics/Immutable.pod ?

[Ovid]

@jgamble Done! Thanks for the suggestion.

Also, there's another doc I'm not linking it in the guide because it would be a distraction, but you might find the make_immutable options to be of interest, too.

[jjn1056]

@Ovid maybe we could start by trying to port the Moose tutorial?

[jjn1056]

Since Moose doesn't do class attributes in its core feature maybe that bit should be left out. There's actually controversy on the best way to handle class attributes, maybe people don't use MooseX::ClassAttribute. I would suggest if this is a porting guide that we focus more on Moose features, how they are handled in Cor and workarounds for things the Cor doesn't do.

[jjn1056]

Can a class attribute (I hate the term 'field'!) be passed to the constructor by adding :param to its definition?

@abraxxa I like 'field'. I'm glad they decided to not use 'has'. That way we can write a "Cor::MooseLike" that does define a 'has' to help smooth over differences and make porting easier. I remember with Moose we created MooseX::Emulate::Class::Accessor::Fast to help speed along porting of code that used Class::Accessor, which was very popular pre Moose days.

[jjn1056]

We'll probably need a separate guide for handling the more common MooseX extensions. There's tons of those but a lot of them are not particularly popular. I wonder how to figure out which ones are a big deal and need to be discussed.

[abraxxa]

Can a class attribute (I hate the term 'field'!) be passed to the constructor by adding :param to its definition?

@abraxxa I like 'field'. I'm glad they decided to not use 'has'. That way we can write a "Cor::MooseLike" that does define a 'has' to help smooth over differences and make porting easier. I remember with Moose we created MooseX::Emulate::Class::Accessor::Fast to help speed along porting of code that used Class::Accessor, which was very popular pre Moose days.

I wouldn't suggest 'has' but 'attribute', as that's what every OO coding guide and other languages calls it.

[Grinnz]

attribute is unfortunately out of the question, because it is already a Perl feature (which Corinna itself uses).

[abraxxa]

I don't see a keyword named 'attribute' there.

[leonerd]

I don't see a keyword named 'attribute' there.

class Ball :isa(Toy) :does(Roundness) { ... }

^-- :isa and :does are attributes.

field $size :reader :writer :param;

^-- as are :reader, :writer and :param

These things are all called "attributes" and have been for the past ~20 or so years that Perl has had them.

[abraxxa]

Yes, and how does that prevent us from defining attributes using the keyword attribute?

[leonerd]

It would be very very confusing to have two totally-distinct concepts, both called "attributes". Especially if these object fields can have attributes themselves. How would you distinguish

attribute $name :reader :writer;

is $name an attribute here? What are :reader and :writer? Are they attributes of that attribute?

Distinct concepts must have distinct names - this is an essential part of any language; computer or otherwise.