Front page | perl.perl5.porters |
Postings from July 2013
On 3 July 2013 05:35, David Golden <xdg@xdg.me> wrote:
> (6) Versus more of an autobox approach
>
> Does it have to be punctuation?
>
> $array->flatten
>
> This could get tricky just like auto-deref if objects with overloading
> are also to be supported (which I would just say "no" to). But I do
> wonder how much circumfix deref would go away in practice with
> autoboxing-style methods:
>
> $array->push( $other_array->flatten );
> $array->map( sub { ... } );
> $hash->keys;
>
I would myself much rather the more autobox style interface than extra
punctuation-based magic.
Mostly, because when I see things like
$foo->$*
Being discussed, it interferes with how I visually parse things, and it
makes me think that its a permutation of
$foo->$bar
And hence, without knowing of the special deref syntax, I would go looking
for the variable in the same scope called
$*
And then get confused when I couldn't find it.
Similar happens when I see
$foo->@*
My brain is already looking for the "variable" part of "@variable" and is
just getting confused, and it doesn't make sense why somebody would try to
call a method on some kind of invocant with an array as a list of methods
to call, or something like that.
I'd be far more in favour of a more IO::Handle approach, where basic types
have autobox style methods on them.
Hell, I'd even like a minimalist deref syntax like
push $foo->list, 'value';
which is much more intuitive to me, and works on my present mental model of
Perl. Much more so than
push $foo->@*, 'value';
Which my mental model just goes "SYNTAX ERROR".
Granted, you can freely add this feature and I don't have to use it.
But I'd rather never have to use it, and I don't really see what value this
particular syntax offers, and it just strikes me that this particular
choice of syntax is covered with weird parsing edge cases that result from
sharing tokens with other significant syntax features.
There's only two downsides I presently see of doing it via a 'method' style
deref:
1. If $foo is a bless, $foo->list would invoke (blessed $object)->list, not
ARRAY->list , which meant you'd have to use a different syntax if you were
inside a class definition.
2. ->@ could be imagined to be easily overloaded for, so bless()'d objects
that **arent** arrays could still implement list deref overloads, so that
they'd still work as arrays with things that need them to.
In essence,
my $foo = bless('SOMECLASS',{});
push $foo->list # would have to bypass SOMECLASS::list if it existed to
call the overloaded '@{}'
push $foo->@ # no such problem
--
Kent
Thread Previous
|
Thread Next