develooper Front page | perl.perl5.porters | Postings from August 2013

Re: postfix dereference syntax

Thread Previous | Thread Next
Brian Fraser
August 30, 2013 16:08
Re: postfix dereference syntax
Message ID:
On Fri, Aug 30, 2013 at 12:43 PM, Aristotle Pagaltzis <>wrote:

> * Ricardo Signes <> [2013-08-30 14:45]:
> > You know, I have been so consumed with faith in this feature for years
> > that I felt it could just drop right in. I will admit that I may be
> > biased. If there is consensus that all or part of this feature should
> > be experimental (which seems reasonable) then okay.
> I don’t foresee problems with postfix deref, but then I didn’t foresee
> the edge cases in the maximally minimal signature proposal either, which
> started to turn up once it was really scrutinized. The interaction
> between the `each @array` and `each $autoderefed` features weren’t
> foreseen either. Etc etc. Everyone so far has been sure that their pet
> feature would work great.
> P5p’s track record for collective piecemeal language design is… middling
> to put it mildly. And I don’t just mean the 5.10 disaster, it goes back
> way farther – think pseudohashes, say. In fact every non-trivial feature
> I can think back to turned out to have major caveats to work out – if it
> wasn’t entirely ill-conceived.

__SUB__? s///r? The callchecker? \&CORE::? Not saying that you don't have a
point, but the picture is nowhere near as grim as you've depicted it.
(It's too early to tell for my personal favorite, /(?[])/)

> We really don’t have much grounds for confidence.
> So I was kinda assuming that now that we have the mechanism, *all* major
> new features would have to make a round as an experimental feature, as
> a matter of policy, to avoid the kind of clusterfuck/embarrassment of
> the likes of smartmatch.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About