Brent 'Dax' Royal-Gordon writes:
> Luke Palmer wrote:
> >I admit there's a certain interest to Larry's new idea.  I've been
> >looking for more distinction between $, @, and % in Perl 6, since they
> >start to become mostly irrelavent.  In the new proposal:
> >
> >    my @a = (1,2,3,4,5);
> >    my $a = @a;
> >
> >    say "@a";     # @a
> >    say "$a";     # 1 2 3 4 5   (perhaps?)
> 
> I think that's a bad kind of distinction, personally.  It breaks an
> obvious parallel.
> 
> >But I'll admit that I'm much more a fan of $() and @() than I am of {}.
> >Form.pm would get very angry at this decision indeed.
> 
> Amen.  Please don't steal unnecessary metacharacters in qq()
> strings--although I still think we should keep it, @ causes a lot of
> problems.
> 
> >On the other hand, this is another step unifying strings and regexes.  I
> >can say pretty confidently that that's a Good Thing. 
> 
> The equivalent regex syntax isn't interpolating, even to the extent that
> a bare $foo or @bar is, so this would be sort of a "false cognate"--IMHO
> another reason not to have interpolating {}.

Yeah, I agree with you.  I was stretching big time to find the merit in
the idea.

I suppose another good thing is that it makes unneccesary the balanced
brace rule in qq{} that was there in Perl 5: all braces need to be
backwhacked now.  However, all braces need to be backwhacked now. Ugh.

I was dreading code-generating heredocs, but with the inclusion of
\qq[], that turns out not to be a problem:

    my $code = eval <<'CODE';
    sub () {
        my \qq[$name] = 0;
        ...
    }
    CODE

> >>and what about "@a[1]('arg')[3]"?
> >
> >That probably wouldn't.
> 
> Actually, I have to wonder why &foo('bar', 'baz') wasn't on Larry's
> list.  Is there a reason for that?

Probably because &foo('bar', 'baz') isn't a function call.  All that
does is refer to a function &foo with a siglet ('bar','baz'), which
means either nothing or a syntax error.  The function call looks like
foo('bar', 'baz');

> >The New Way (tm) to do that would probably be sticking a role onto the
> >array object with which you're dealing:
> >
> >    my @foo does separator('//') = (1,2,3,4,5);
> >    say "[EMAIL PROTECTED]";   # 1//2//3//4//5
> >
> 
> I would think you'd use a property:
> 
>     my @foo = (1,2,3,4,5) but separator('//');
>
> [snip]
>
> Roles are nice, but don't forget about the other mechanisms in Perl for
> such things.

Erm, properties *are* roles.  Your example is the same as mine.

I was thinking in terms of roles because a role would obviously be the
fellow to modify the stringify method of the array.  Attributes work
too, but that all depends on how Array is designed.

Luke

Reply via email to