It may be superseded by more recent p5p discussions about a "postfix dereference" operator.

Which would be an even more useless, fad-driven, change-for-change's-sake, distraction to nowhere than auto-dereferencing.

The justifiction for this: @{ $ref } becoming: $ref->@* or $ref->[] (empty brackets) or dog-knows what else is: Blech

I ask you. The technical justifiction is "Blech".

Funnily enough, I agree that this: push @{ $x->{foo}->[0]->m }, $y; is a bit ugly.

But who writes code like that anyway? And what would it mean if they did?

Let's break that mother down:

1. $x is a reference
2. to a hash that has a key 'foo'
3. who's value is an array
4. of objects that have a method 'm'
5. that takes no arguments and returns a reference to an array
6. onto which we need to push values.

Why would anyone invent an api that requires you to call a method to get a reference to an (internal) array onto which we are to push values; rather than just passing the values to be pushed to a method that does it for us?

Yes, I know it is an invented, over-the-top example to make a point.

And that's my point. If you have to use an invented, over-the-top example to justify something; you've failed.

Cos, $x{foo}[0]->push( $y ) is clean, simple and obvious. And it works right now.

Speaking of aesthetics, I find that example ambiguous. It's not obvious to me whether push is a method that just so happens to have the same name as the push keyword (the one which works on arrays) or whether it's an alternate way of writing that keyword. Is that a method which operates on a container (the array) or an object (not really a container)?

In my mind, one of Perl's OO flaws is unnecessarily confusing containers and objects. An object may have containers, but should it be one?

Speaking of aesthetics, I find that example ambiguous. It's not obvious to me whether push is a method that just so happens to have the same name as the push keyword (the one which works on arrays) or whether it's an alternate way of writing that keyword. Is that a method which operates on a container (the array) or an object (not really a container)?

First, I'm not suggesting that the example makes perfect sense. I didn't chose it, I just matched it.

That said, I have absolutely no problem with an object, (regardless of the internal representation), (re)using a perl keyword for one of its methods, provided that the semantic of that method match those of the keyword. After all, isn't the separation of namespaces one of the primary benefits of OO?

In fact, given that keyword 'push' has been used for the semantics of (various) ADTs (stacks, FIFOs, LIFOs, etc.) in many languages that long pre-dated Perl; and is still the opcode mnemonic used for the equivalent hardware stack operation in (probably) every assembler and hardware manual for every processor going; I think it would be quite silly not to use that well understood term for objects that implement semantically equivalent operations.

In my mind, one of Perl's OO flaws is unnecessarily confusing containers and objects. An object may have containers, but should it be one?

I'm of almost the diametrically opposed position. I think that reusing the familiar and well understood semantics of containers for for classes that represent collections is both eminently sensible and infinitely preferable to everyone inventing their own disparate terms and semantics.

Other languages are perfectly happy to reuse container semantics for OO-classes. In the case of C++ its just a shame that it took the language standard so long to catch up with the rest of the world; with the knock on affect that they've had to invent verbose terms -- push_back, push_front, pop_back, pop_front etc. -- to avoid conflicts with previous 'unsanctioned' libraries.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

And it works right now.

Not in core, it doesn't. (Though I wish it did.)

But anyway, you're missing (or intentionally misdirecting) the point that the justification is not technical, but aesthetic.

And what do you care? If you don't like a given feature (and there's no global performance cost involved in implementing it in the first place), just don't use it.

Some people like new features and some don't. Some like evolution and some like stability. Fine.

My point was that these are individual decisions to be made by individual developers. Expecting "everyone" or "no one" to use a given feature is unrealistic. There's an adoption curve. It happens. No big deal.

-xdg

_{Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.}

Not in core, it doesn't. (Though I wish it did.)

Wish granted.

Really, it does:

#! perl -slw
use strict;

package Thing;

sub new { bless [], $_[0] };
sub push { push @{ shift() }, @_ }

package main;
use Data::Dump qw[ pp ];

my %x = ( foo => [ map Thing->new, 1 .. 10 ] );

$x{foo}[0]->push( 1,2,3 );

pp \%x;

__END__
C:\test>junk66
{
  foo => [
           bless([1, 2, 3], "Thing"),
           bless([], "Thing"),
           bless([], "Thing"),
           bless([], "Thing"),
           bless([], "Thing"),
           bless([], "Thing"),
           bless([], "Thing"),
           bless([], "Thing"),
           bless([], "Thing"),
           bless([], "Thing"),
         ],
}
[download]

That's 5.10, but it's worked right back to 5.6.1 (and probably before, but that's before my time with Perl.)

(And if aesthetics is the current, important criteria for the future of Perl5, there are plenty of other areas that definitely rate attention long before this.)

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.