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 -- KentThread Previous | Thread Next