Re: Observations from a C++/Python developer that never used Perl5

[Brian Duggan]

The pair constructor seems to be in a different category than the other
quoting operators since the expression that it quotes must look like an
identifier:

https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Grammar.nqp#L1776

token fatarrow {

Re: Observations from a C++/Python developer that never used Perl5

[Aaron Sherman]

You cannot currently define your own quote-like operators. That will come
with true macros (though you could certainly do it via a slang...
everything is possible with a slang). But they are operators. Not only are
they operators, but they nest other operators. vis:

say "These are my args: {@*ARGS.join(',')}";




Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.


On Fri, Sep 9, 2016 at 8:59 PM, Joseph Garvin 
wrote:

> Wait, quotes *are an operator* ? If so how would I define them? If the
> operator returns string, what is the type of its argument? If so that's
> even stranger -- most languages they're a hard coded bit of syntax -- the
> closest thing I can think of is in C++11 you can add your own string
> literal types, but even with that the closest you could get would be:
>
> "Foo"_mytype => bar
>
> You still wouldn't be able to omit the quotes.
>
> On Sep 9, 2016 12:12 AM, "Aaron Sherman"  wrote:
>
>> it is combining too many new things at once:
>>
>>
>> Well, it is meant to be the up-front example of everything at once before
>> the step-by-step...
>>
>>
>>> * BUILD
>>> * new
>>
>>
>> These are the heart of construction. I don't think there's any avoiding
>> that in a class tutorial.
>>
>> * submethod
>>> * bless
>>
>>
>> These are simply necessary components of the above. BUILD is a submethod.
>> new uses bless. These are non-negotiable aspects of the tutorial.
>>
>> * named arguments syntax
>>> * slurping parameter syntax
>>
>>
>> Named arguments are pretty standard stuff. Slurpy args... I suppose it's
>> one more thing, but is it really that unusual that we expect someone
>> reading this not to understand variadic arguments?
>>
>>
>>> * code golfing cleverness of mapping arguments to identically named
>>> named arguments
>>
>>
>> Again, this is how you take arguments to BUILD that set attributes.
>> That's the correct form, not code golfing.
>>
>> Constructors in a language that supports a flexible metaobject protocol
>> aren't trivial beasts.
>>
>>
>> The real nail in the coffin though is that it's an example that doesn't
>>> need to use any of those features (nothing about Task really require
>>> special construction),
>>>
>>
>> This is, I think, the only really significant problem with that example.
>> The BUILD method is doing no work, and doesn't need to. An example where
>> new and BUILD were actually required would be vastly more useful.
>>
>>
>>> * If I have a member that is read-only, when am I allowed to initialize
>>> it and after what point must already be initialized? Can I assign to it in
>>> BUILD but not new or vice versa?
>>>
>>
>> You always get a free initializer, so if the user is going to provide it
>> or it's going to get a static default, you're good to go. But let's say you
>> have this:
>>
>> class Foo {
>>   has $.a;
>>   has $.b;
>>   submethod BUILD(:$!a) { $!b = $!a * 10 }
>> }
>>
>> In this case, you need the BUILD submethod because you wanted to have a
>> dynamic value for the .b attribute that is based on whatever the .a
>> attribute was set to.
>>
>> Now, that out of the way, let's make $.b readonly:
>>
>>   has $.b is readonly;
>>
>> This doesn't make $.b constant, it merely affects the automatically
>> generated constructors. So your BUILD routine keeps working. The private
>> form ($!b) only works within the class, but is not affected by such
>> strictures.
>>
>> * If I want a constructor that takes positional arguments, do I write new
>>> or BUILD?
>>>
>>
>> For positionals, you have to define a new. Here's another example that
>> does unecessary work, but in this case to show you what's going on:
>>
>> $ perl6 foo.p6
>> new(1, 2) pre-bless
>> BUILD(1, 2)
>> 12
>> $ cat foo.p6
>> class Foo {
>> has $.a;
>> has $.b is readonly;
>> multi method new($a, $b) {
>> say "new($a, $b) pre-bless";
>> self.bless(:$a, :$b);
>> }
>> submethod BUILD(:$!a, :$!b) {
>> say "BUILD($!a, $!b)";
>> }
>> }
>>
>> my $f = Foo.new(1,2);
>> say $f.a, $f.b;
>>
>>
>>
>>
>>>
>>> * If I need to do some computation when the object is constructed in
>>> order to properly initialize the members, do I write new or BUILD? What if
>>> one of the members I need to initialize is read-only?
>>>
>>
>> All best suited to BUILD.
>>
>>
>>> * Can either new or BUILD be a multimethod?
>>>
>>
>> Both, sort of. BUILD is a submethod, not a method. It's a sub that looks
>> like a method. But both can be multi.
>>
>>
>>
>>> Functions (including operators since they are just functions with a
>>> different calling syntax after all) normally just operate on their
>>> arguments without knowing anything about the context with the function was
>>> called.
>>>
>>
>> This is never a valid assumption in Perl. Perl is all about context.
>> That's why we have so many operators for enforcing a 

Re: Observations from a C++/Python developer that never used Perl5

[Brock Wilcox]

Quotes are almost a circumfix operator, but they act a bit more like a
macro by controlling the parsing of the contents. But you can do some weird
things like define your own quote-likes.

perl6 -e ' sub circumfix:<>($v) { "{$v}" } ; say B"foo"B ' #
output: foo

or more verbosely

perl6 -e ' sub circumfix:<>($v) { "{$v}" } ; say bold
"foo" endbold ' # output foo

That said, I think the quoting of the left side of => is understandably
startling. With normal quotes (single, double, etc) you read left to right
and you see a quote and you know that until you see another (unescaped)
quote something different is happening. With => you have to read from the
middle and go back to the left to get the whole picture. Very powerful and
handy and easy once you recognize it, but definitely different from pure
left-to-right.


On Fri, Sep 9, 2016 at 8:59 PM, Joseph Garvin 
wrote:

> Wait, quotes *are an operator* ? If so how would I define them? If the
> operator returns string, what is the type of its argument? If so that's
> even stranger -- most languages they're a hard coded bit of syntax -- the
> closest thing I can think of is in C++11 you can add your own string
> literal types, but even with that the closest you could get would be:
>
> "Foo"_mytype => bar
>
> You still wouldn't be able to omit the quotes.
>
> On Sep 9, 2016 12:12 AM, "Aaron Sherman"  wrote:
>
>> it is combining too many new things at once:
>>
>>
>> Well, it is meant to be the up-front example of everything at once before
>> the step-by-step...
>>
>>
>>> * BUILD
>>> * new
>>
>>
>> These are the heart of construction. I don't think there's any avoiding
>> that in a class tutorial.
>>
>> * submethod
>>> * bless
>>
>>
>> These are simply necessary components of the above. BUILD is a submethod.
>> new uses bless. These are non-negotiable aspects of the tutorial.
>>
>> * named arguments syntax
>>> * slurping parameter syntax
>>
>>
>> Named arguments are pretty standard stuff. Slurpy args... I suppose it's
>> one more thing, but is it really that unusual that we expect someone
>> reading this not to understand variadic arguments?
>>
>>
>>> * code golfing cleverness of mapping arguments to identically named
>>> named arguments
>>
>>
>> Again, this is how you take arguments to BUILD that set attributes.
>> That's the correct form, not code golfing.
>>
>> Constructors in a language that supports a flexible metaobject protocol
>> aren't trivial beasts.
>>
>>
>> The real nail in the coffin though is that it's an example that doesn't
>>> need to use any of those features (nothing about Task really require
>>> special construction),
>>>
>>
>> This is, I think, the only really significant problem with that example.
>> The BUILD method is doing no work, and doesn't need to. An example where
>> new and BUILD were actually required would be vastly more useful.
>>
>>
>>> * If I have a member that is read-only, when am I allowed to initialize
>>> it and after what point must already be initialized? Can I assign to it in
>>> BUILD but not new or vice versa?
>>>
>>
>> You always get a free initializer, so if the user is going to provide it
>> or it's going to get a static default, you're good to go. But let's say you
>> have this:
>>
>> class Foo {
>>   has $.a;
>>   has $.b;
>>   submethod BUILD(:$!a) { $!b = $!a * 10 }
>> }
>>
>> In this case, you need the BUILD submethod because you wanted to have a
>> dynamic value for the .b attribute that is based on whatever the .a
>> attribute was set to.
>>
>> Now, that out of the way, let's make $.b readonly:
>>
>>   has $.b is readonly;
>>
>> This doesn't make $.b constant, it merely affects the automatically
>> generated constructors. So your BUILD routine keeps working. The private
>> form ($!b) only works within the class, but is not affected by such
>> strictures.
>>
>> * If I want a constructor that takes positional arguments, do I write new
>>> or BUILD?
>>>
>>
>> For positionals, you have to define a new. Here's another example that
>> does unecessary work, but in this case to show you what's going on:
>>
>> $ perl6 foo.p6
>> new(1, 2) pre-bless
>> BUILD(1, 2)
>> 12
>> $ cat foo.p6
>> class Foo {
>> has $.a;
>> has $.b is readonly;
>> multi method new($a, $b) {
>> say "new($a, $b) pre-bless";
>> self.bless(:$a, :$b);
>> }
>> submethod BUILD(:$!a, :$!b) {
>> say "BUILD($!a, $!b)";
>> }
>> }
>>
>> my $f = Foo.new(1,2);
>> say $f.a, $f.b;
>>
>>
>>
>>
>>>
>>> * If I need to do some computation when the object is constructed in
>>> order to properly initialize the members, do I write new or BUILD? What if
>>> one of the members I need to initialize is read-only?
>>>
>>
>> All best suited to BUILD.
>>
>>
>>> * Can either new or BUILD be a multimethod?
>>>
>>
>> Both, sort of. BUILD is a submethod, not a method. It's a sub that looks
>> like a method. But both can be multi.
>>
>>
>>
>>> 

Re: Observations from a C++/Python developer that never used Perl5

[Joseph Garvin]

Wait, quotes *are an operator* ? If so how would I define them? If the
operator returns string, what is the type of its argument? If so that's
even stranger -- most languages they're a hard coded bit of syntax -- the
closest thing I can think of is in C++11 you can add your own string
literal types, but even with that the closest you could get would be:

"Foo"_mytype => bar

You still wouldn't be able to omit the quotes.

On Sep 9, 2016 12:12 AM, "Aaron Sherman"  wrote:

> it is combining too many new things at once:
>
>
> Well, it is meant to be the up-front example of everything at once before
> the step-by-step...
>
>
>> * BUILD
>> * new
>
>
> These are the heart of construction. I don't think there's any avoiding
> that in a class tutorial.
>
> * submethod
>> * bless
>
>
> These are simply necessary components of the above. BUILD is a submethod.
> new uses bless. These are non-negotiable aspects of the tutorial.
>
> * named arguments syntax
>> * slurping parameter syntax
>
>
> Named arguments are pretty standard stuff. Slurpy args... I suppose it's
> one more thing, but is it really that unusual that we expect someone
> reading this not to understand variadic arguments?
>
>
>> * code golfing cleverness of mapping arguments to identically named named
>> arguments
>
>
> Again, this is how you take arguments to BUILD that set attributes. That's
> the correct form, not code golfing.
>
> Constructors in a language that supports a flexible metaobject protocol
> aren't trivial beasts.
>
>
> The real nail in the coffin though is that it's an example that doesn't
>> need to use any of those features (nothing about Task really require
>> special construction),
>>
>
> This is, I think, the only really significant problem with that example.
> The BUILD method is doing no work, and doesn't need to. An example where
> new and BUILD were actually required would be vastly more useful.
>
>
>> * If I have a member that is read-only, when am I allowed to initialize
>> it and after what point must already be initialized? Can I assign to it in
>> BUILD but not new or vice versa?
>>
>
> You always get a free initializer, so if the user is going to provide it
> or it's going to get a static default, you're good to go. But let's say you
> have this:
>
> class Foo {
>   has $.a;
>   has $.b;
>   submethod BUILD(:$!a) { $!b = $!a * 10 }
> }
>
> In this case, you need the BUILD submethod because you wanted to have a
> dynamic value for the .b attribute that is based on whatever the .a
> attribute was set to.
>
> Now, that out of the way, let's make $.b readonly:
>
>   has $.b is readonly;
>
> This doesn't make $.b constant, it merely affects the automatically
> generated constructors. So your BUILD routine keeps working. The private
> form ($!b) only works within the class, but is not affected by such
> strictures.
>
> * If I want a constructor that takes positional arguments, do I write new
>> or BUILD?
>>
>
> For positionals, you have to define a new. Here's another example that
> does unecessary work, but in this case to show you what's going on:
>
> $ perl6 foo.p6
> new(1, 2) pre-bless
> BUILD(1, 2)
> 12
> $ cat foo.p6
> class Foo {
> has $.a;
> has $.b is readonly;
> multi method new($a, $b) {
> say "new($a, $b) pre-bless";
> self.bless(:$a, :$b);
> }
> submethod BUILD(:$!a, :$!b) {
> say "BUILD($!a, $!b)";
> }
> }
>
> my $f = Foo.new(1,2);
> say $f.a, $f.b;
>
>
>
>
>>
>> * If I need to do some computation when the object is constructed in
>> order to properly initialize the members, do I write new or BUILD? What if
>> one of the members I need to initialize is read-only?
>>
>
> All best suited to BUILD.
>
>
>> * Can either new or BUILD be a multimethod?
>>
>
> Both, sort of. BUILD is a submethod, not a method. It's a sub that looks
> like a method. But both can be multi.
>
>
>
>> Functions (including operators since they are just functions with a
>> different calling syntax after all) normally just operate on their
>> arguments without knowing anything about the context with the function was
>> called.
>>
>
> This is never a valid assumption in Perl. Perl is all about context.
> That's why we have so many operators for enforcing a context (e.g. the
> prefix ops ?, +, !, so, ~)
>
>
>> But the pair constructor operator **reaches back magically into the place
>> where it was called and changes the argument it was given into a string**
>>
>
> Not really. It's a quoting operator and a binary operator rolled into one.
> As such, it's no more strange that it has this "contextual" behavior than
> the more traditional quoting operators. You don't balk at the fact that the
> doublequotes "reach back" and change the way their parameter is parsed, do
> you? In Perl 6, it's just more explicit that quoting operators are actually
> operators and can be treated as such.
>
>
>

Re: Observations from a C++/Python developer that never used Perl5

[Aaron Sherman]

>
> it is combining too many new things at once:


Well, it is meant to be the up-front example of everything at once before
the step-by-step...


> * BUILD
> * new


These are the heart of construction. I don't think there's any avoiding
that in a class tutorial.

* submethod
> * bless


These are simply necessary components of the above. BUILD is a submethod.
new uses bless. These are non-negotiable aspects of the tutorial.

* named arguments syntax
> * slurping parameter syntax


Named arguments are pretty standard stuff. Slurpy args... I suppose it's
one more thing, but is it really that unusual that we expect someone
reading this not to understand variadic arguments?


> * code golfing cleverness of mapping arguments to identically named named
> arguments


Again, this is how you take arguments to BUILD that set attributes. That's
the correct form, not code golfing.

Constructors in a language that supports a flexible metaobject protocol
aren't trivial beasts.


The real nail in the coffin though is that it's an example that doesn't
> need to use any of those features (nothing about Task really require
> special construction),
>

This is, I think, the only really significant problem with that example.
The BUILD method is doing no work, and doesn't need to. An example where
new and BUILD were actually required would be vastly more useful.


> * If I have a member that is read-only, when am I allowed to initialize it
> and after what point must already be initialized? Can I assign to it in
> BUILD but not new or vice versa?
>

You always get a free initializer, so if the user is going to provide it or
it's going to get a static default, you're good to go. But let's say you
have this:

class Foo {
  has $.a;
  has $.b;
  submethod BUILD(:$!a) { $!b = $!a * 10 }
}

In this case, you need the BUILD submethod because you wanted to have a
dynamic value for the .b attribute that is based on whatever the .a
attribute was set to.

Now, that out of the way, let's make $.b readonly:

  has $.b is readonly;

This doesn't make $.b constant, it merely affects the automatically
generated constructors. So your BUILD routine keeps working. The private
form ($!b) only works within the class, but is not affected by such
strictures.

* If I want a constructor that takes positional arguments, do I write new
> or BUILD?
>

For positionals, you have to define a new. Here's another example that does
unecessary work, but in this case to show you what's going on:

$ perl6 foo.p6
new(1, 2) pre-bless
BUILD(1, 2)
12
$ cat foo.p6
class Foo {
has $.a;
has $.b is readonly;
multi method new($a, $b) {
say "new($a, $b) pre-bless";
self.bless(:$a, :$b);
}
submethod BUILD(:$!a, :$!b) {
say "BUILD($!a, $!b)";
}
}

my $f = Foo.new(1,2);
say $f.a, $f.b;




>
> * If I need to do some computation when the object is constructed in order
> to properly initialize the members, do I write new or BUILD? What if one of
> the members I need to initialize is read-only?
>

All best suited to BUILD.


> * Can either new or BUILD be a multimethod?
>

Both, sort of. BUILD is a submethod, not a method. It's a sub that looks
like a method. But both can be multi.



> Functions (including operators since they are just functions with a
> different calling syntax after all) normally just operate on their
> arguments without knowing anything about the context with the function was
> called.
>

This is never a valid assumption in Perl. Perl is all about context. That's
why we have so many operators for enforcing a context (e.g. the prefix ops
?, +, !, so, ~)


> But the pair constructor operator **reaches back magically into the place
> where it was called and changes the argument it was given into a string**
>

Not really. It's a quoting operator and a binary operator rolled into one.
As such, it's no more strange that it has this "contextual" behavior than
the more traditional quoting operators. You don't balk at the fact that the
doublequotes "reach back" and change the way their parameter is parsed, do
you? In Perl 6, it's just more explicit that quoting operators are actually
operators and can be treated as such.

Re: Observations from a C++/Python developer that never used Perl5

[Joseph Garvin]

On Thu, Sep 8, 2016 at 12:25 AM, Kaare Rasmussen  wrote:

> I wonder what you miss from https://docs.perl6.org/language/classtut. To
> me, it explains the hows and whys very thoroughly. Now, I now people have
> been hard at work improving the documentation, so if you can point to
> what's missing or unclear, I'm sure it will help a lot.


I forgot I looked at this before. The Task example doesn't really help a
newcomer because it is combining too many new things at once:

* BUILD
* submethod
* new
* bless
* named arguments syntax
* slurping parameter syntax
* code golfing cleverness of mapping arguments to identically named named
arguments

The real nail in the coffin though is that it's an example that doesn't
need to use any of those features (nothing about Task really require
special construction), so a quick read just makes it look like it's a very
verbose syntax for doing something you normally get for free, rather than
showing how it allows you to do things that you otherwise wouldn't be able
to do.

The rust developers talk about having a "strangeness budget", because if
you introduce too many strange things at once people give up. Every
object-oriented language I've used has one constructor-like method that you
define. That Perl6 has two is really strange and unusual (at least coming
from the background of somebody who has "only" been exposed to
C++/Java/Python/Lisp/Haskell). Strange and unusual enough that it seems
like there should be an example that specifically focuses on what you get
out of having two, and when you should be using one versus the other. And
frankly I'm not sure if it's actually two, because bless is also apparently
a method (that may be you can override as well?!), even though it is
supposed to be what you call to construct the object that hasn't yet been
constructed... see why this might be confusing? It would be especially
great if it contrasted with another language where you could demonstrate
that it's awkward to do something without the feature.

Here are some fairly simple things that I was left wondering how to do:

* If I have a member that is read-only, when am I allowed to initialize it
and after what point must already be initialized? Can I assign to it in
BUILD but not new or vice versa?

* If I want a constructor that takes positional arguments, do I write new
or BUILD?

* If I need to do some computation when the object is constructed in order
to properly initialize the members, do I write new or BUILD? What if one of
the members I need to initialize is read-only?

* Can either new or BUILD be a multimethod? Overloading constructors is
fairly common in C++ at least.

>> The pair operator is explained here https://docs.perl6.org/languag
e/operators#index-entry-pair_constructor and word quoting here
https://docs.perl6.org/language/quoting#Word_quoting:_qw - perhaps they're
more Perl 5-like, but both are very handy features. Perhaps you can expand
a little as to what you'd like explained. Coming from Perl 5, I'm certainly
damaged in that respect.

Functions (including operators since they are just functions with a
different calling syntax after all) normally just operate on their
arguments without knowing anything about the context with the function was
called. But the pair constructor operator **reaches back magically into the
place where it was called and changes the argument it was given into a
string** (because otherwise it would be an undeclared variable name).
That's the kind of thing that in most languages you either can't do or you
can only do by defining a macro. I've never seen anything like it. And
going with the strangeness theme none of the tutorials seemed to be the
least bit fazed by it, while I think somebody coming from a background
without Perl will be bewildered by it.

Re: Observations from a C++/Python developer that never used Perl5

[Will Coleda]

> As I recall it, macros where left out of the initial implementation. So you 
> have to wait for another Christmas Present :-)

The version of macros that was available in Rakudo when the 6.c spec
was cut was released with the compiler; It's marked experimental and
is therefore subject to change, but they are in there.

On Thu, Sep 8, 2016 at 1:25 AM, Kaare Rasmussen  wrote:
> Hi Joseph
>
> Welcome, and I hope you'll stick around.
>
> Now, I haven't had the time to dig into Perl 6 myself, only to poke at it
> from time to time. But, while waiting for people who know something to
> respond, I'll ask you to be a little concise in certain areas.
>>
>> * I can find no concise easy-to-understand explanation for how to define
>> what other languages would call constructors. Instead there is a mess of
>> bless, magic inside Mu, new, BUILD, BUILDALL... It's not clear when you
>> should prefer to override BUILD or new or both. I also assume there are some
>> benefits to teasing apart object construction this way, but right now I
>> don't know what they are. This is also an area where I think there are older
>> blog posts confusing the situation because they discuss semantics from an
>> older version of Perl6.
>
>
> I wonder what you miss from https://docs.perl6.org/language/classtut. To me,
> it explains the hows and whys very thoroughly. Now, I now people have been
> hard at work improving the documentation, so if you can point to what's
> missing or unclear, I'm sure it will help a lot.
>>
>>
>> * It would be nice for people coming from Python for a tutorial that
>> explained the basic module importing, the scope of things imported, and how
>> name collisions are avoided when importing from two modules that have the
>> same sub. The official documentation is trying to distinguish a bunch of
>> subtle and presumably useful for advanced users distinctions that are
>> completely lost on a newcomer. I just want to know what is the equivalent of
>> import, from foo import bar, and import foo as bar.
>
>
> It sounds like "arh, do it yourself", but I'd like to say that, coming from
> a Python background, you'd be the perfect person to do just that. At least
> take notes and post them, so it can go into a tutorial of some kind.
>
>> * Coming from almost any other language the => operator is dark magic
>> because of its implicit quoting of the left hand side. Likewise the implicit
>> quoting done by . Some explanation of why this is done, and how you
>> could write a sub or operator that does the same thing would probably go a
>> long way towards making it less confusing.
>
>
> The pair operator is explained here
> https://docs.perl6.org/language/operators#index-entry-pair_constructor and
> word quoting here https://docs.perl6.org/language/quoting#Word_quoting:_qw -
> perhaps they're more Perl 5-like, but both are very handy features. Perhaps
> you can expand a little as to what you'd like explained. Coming from Perl 5,
> I'm certainly damaged in that respect.
>
>> * I haven't been able to find any guidance on when I should be using a
>> role and when I should be using a class. The former seem to give you better
>> error messages when you forget to define a method from a base role... So
>> never use classes? I suspect it's more complicated than that.
>
>
> I guess this is something everybody can have an opinion about. There are a
> number of reasons to go one or the other way. Isn't it a topic for all
> modern languages?
>
>> * Types feel like second-class citizens. Without knowing the details of
>> the implementation it feels like the errors that Perl can statically detect
>> is chosen at random. It's generally useful
>
>
> I think your wording is misleading. The things that Perl 6 can detect when
> compiling shouldn't be a matter of choice, but of what's possible. Perhaps
> you can give some examples, I'm sure there are perfectly good reasons for
> the way things are. If not, it may be a bug, and the compiler can be
> improved.
>
>> argument constructors, are all pretty sweet as well. Macros look pretty
>> promising although again I had trouble finding good tutorials.
>
>
> As I recall it, macros where left out of the initial implementation. So you
> have to wait for another Christmas Present :-)
>
> /kaare
>



-- 
Will "Coke" Coleda

Re: Observations from a C++/Python developer that never used Perl5

[yary]

On Thu, Sep 8, 2016 at 6:41 AM, Kamil Kułaga  wrote:

> In perl6 default way is to not write new, BUILD or BUILDALL and also
> not to write accessors. When you create object you can provide
> attributes to initialize, default accessors are generated if field is
> declared with $. sigil.
>

Right, there's a default "new" method that takes care of attribute
initialization, and calling any ancestor class initializers.

To have your initializer pre-process the attributes before building the
object, or call other code on creation- declare a "submethod BUILD" - that
will get the arguments that "new" had and let you modify them, run code as
needed. Effectively it's intercepting the object creation process just
before the object is initialized.

That took me a long time to figure out when I was trying some Perl6 around
2013, and I didn't really get it until reading through the perl5 Moose
cookbook- and Moose is different enough from Perl6 that, while it helped me
get the big picture of Perl6 objects, it also took me a little more time to
unlearn some big details to get back into Perl6 (like how there is no
BUILDARGS). This paragraph is for anyone who is working on the docs- Perl6
could use an object tutorial and cookbook like Moose's!
https://docs.perl6.org/language/objects is actually pretty good, it just
wasn't around when I started- and Moose does have a lot of docs built up
from answering these kinds of questions.

 As for "new", I re-read https://docs.perl6.org/language/objects and see "if
you want a constructor that accepts positional arguments, you must write
your own new method: [example] ... However this is considered poor
practice, because it makes correct initialization of objects from
subclasses harder."

-y

Re: Observations from a C++/Python developer that never used Perl5

[Kamil Kułaga]

On Thu, Sep 8, 2016 at 4:00 AM, Joseph Garvin  wrote:
> * I can find no concise easy-to-understand explanation for how to define
> what other languages would call constructors. Instead there is a mess of
> bless, magic inside Mu, new, BUILD, BUILDALL... It's not clear when you
> should prefer to override BUILD or new or both. I also assume there are some
> benefits to teasing apart object construction this way, but right now I
> don't know what they are. This is also an area where I think there are older
> blog posts confusing the situation because they discuss semantics from an
> older version of Perl6.

In perl6 default way is to not write new, BUILD or BUILDALL and also
not to write accessors. When you create object you can provide
attributes to initialize, default accessors are generated if field is
declared with $. sigil. OOp was designed to not write the same code
everytime. When I started using perl6 the doc didn't told me it but
IMHO the best way to learn is read others code.

> I haven't been able to find any guidance on when I should be using a role and 
> when I should be using a class. The former seem to give you better error 
> messages when you forget to define a method from a base role... So never use 
> classes? I suspect it's more complicated than that.

Roles are similar to mixins. You can add something to class without
all complications of multi inheritance. IMHO *is* and *does* keywords
in most cases explain best whether you want class or role.  I
generally use classes for data and roles for code because I like  to
separate data form implementation. I hurt a lot of times while was
trying to do java programming with perl6 then I realized roles are not
interfaces and code is not compiled in static language sense.

-- 
Regards

Kamil Kułaga

Re: Observations from a C++/Python developer that never used Perl5

[Kaare Rasmussen]

Hi Joseph

Welcome, and I hope you'll stick around.

Now, I haven't had the time to dig into Perl 6 myself, only to poke at 
it from time to time. But, while waiting for people who know something 
to respond, I'll ask you to be a little concise in certain areas.
* I can find no concise easy-to-understand explanation for how to 
define what other languages would call constructors. Instead there is 
a mess of bless, magic inside Mu, new, BUILD, BUILDALL... It's not 
clear when you should prefer to override BUILD or new or both. I also 
assume there are some benefits to teasing apart object construction 
this way, but right now I don't know what they are. This is also an 
area where I think there are older blog posts confusing the situation 
because they discuss semantics from an older version of Perl6.


I wonder what you miss from https://docs.perl6.org/language/classtut. To 
me, it explains the hows and whys very thoroughly. Now, I now people 
have been hard at work improving the documentation, so if you can point 
to what's missing or unclear, I'm sure it will help a lot.


* It would be nice for people coming from Python for a tutorial that 
explained the basic module importing, the scope of things imported, 
and how name collisions are avoided when importing from two modules 
that have the same sub. The official documentation is trying to 
distinguish a bunch of subtle and presumably useful for advanced users 
distinctions that are completely lost on a newcomer. I just want to 
know what is the equivalent of import, from foo import bar, and import 
foo as bar.


It sounds like "arh, do it yourself", but I'd like to say that, coming 
from a Python background, you'd be the perfect person to do just that. 
At least take notes and post them, so it can go into a tutorial of some 
kind.


* Coming from almost any other language the => operator is dark magic 
because of its implicit quoting of the left hand side. Likewise the 
implicit quoting done by . Some explanation of why this is done, 
and how you could write a sub or operator that does the same thing 
would probably go a long way towards making it less confusing.


The pair operator is explained here 
https://docs.perl6.org/language/operators#index-entry-pair_constructor 
and word quoting here 
https://docs.perl6.org/language/quoting#Word_quoting:_qw - perhaps 
they're more Perl 5-like, but both are very handy features. Perhaps you 
can expand a little as to what you'd like explained. Coming from Perl 5, 
I'm certainly damaged in that respect.


* I haven't been able to find any guidance on when I should be using a 
role and when I should be using a class. The former seem to give you 
better error messages when you forget to define a method from a base 
role... So never use classes? I suspect it's more complicated than that.


I guess this is something everybody can have an opinion about. There are 
a number of reasons to go one or the other way. Isn't it a topic for all 
modern languages?


* Types feel like second-class citizens. Without knowing the details 
of the implementation it feels like the errors that Perl can 
statically detect is chosen at random. It's generally useful


I think your wording is misleading. The things that Perl 6 can detect 
when compiling shouldn't be a matter of choice, but of what's possible. 
Perhaps you can give some examples, I'm sure there are perfectly good 
reasons for the way things are. If not, it may be a bug, and the 
compiler can be improved.


argument constructors, are all pretty sweet as well. Macros look 
pretty promising although again I had trouble finding good tutorials.


As I recall it, macros where left out of the initial implementation. So 
you have to wait for another Christmas Present :-)


/kaare