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 <joseph.h.gar...@gmail.com>
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" <a...@ajs.com> 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.
>>
>>
>>
>
