Front page | perl.perl5.porters |
Postings from May 2012
On Mon, May 14, 2012 at 12:44:45PM -0700, Linda W wrote:
> Dave Mitchell via RT wrote:
> >
> >>Yes, because regardless of whether it might have been nice to have when
> >>perl was first designed, perl has for years been interpreting those
> >>barewords as function calls:
> >>
> >> sub foo { print "foo called\n"; 0 }
> >> sub bar { print "bar called\n"; 0 }
> >> @h{foo,bar};
> >>
> >> outputs
> >>
> >> foo called
> >> bar called
> >>
> >>If we changed it now it wouldn't be backwardly compatible.
> ----
> sub retrieve_user_name(){"sally}
> my $p={retrieve_user_name => owner};
>
> Was changed when someone decided to go through and
> clean up the need for quotes in many places on hash keys.
>
> That wasn't backwards compatible. So Why is it that all these
> non backward compatible changes were doable -- but only got done half
> way -- and now it's not ok to make the language consistent.
Our policy on backwards-incompatible changes has evolved over the past
20 years.
> There have been many non-backward compat changes -- barewords used
> to give no warnings.. but now do -- that's not backwards compat.
Don't know what you're referring to here.
> The idea that backwards compat is a deal breaker hasn't seemed to stop
> alot of changes -- so explain to me what's different...
> Like in such an expression, a warning would issued for non-decorated
> functions. (stage 1),
> then in next version, a use 5.2.0 would default to those being
> statics without
> decorations...
We could certainly start a deprecation cycle for a change, if it was
thought to be an improvement to the language. Pointing at something and
saying "well this other thing changed in a backwards-incompatible way,
why can't you do the same thing here?" isn't an argument.
> Father Chrysostomos via RT wrote:
> >It’s conceptually simpler the way it is: bareword or expression. If
> >it’s not a single bareword, then it’s an expression parsed the same way
> >expressions are parsed anywhere else.
>
>
> So how does that fit in with my $a = {read=>1,printf=>2}; That
> isn't a simple
> expression. Instead, another special case was made for that format.
>
> Seems like each format required a new special rule. If both of the
> special cases each required their own special rule, then why is
> there an issue with
> a similar construct also having a special rule?
>
> Seem hypocritical to call a an implementation that follows
> established precedent "not simple" -- one could just as easily see
> it as you asking for a new special rule to NOT do it the way it has
> been done before and break precedence.
This is not a special case at all.
my $foo = {
a => 1,
b => 2,
};
is legal syntax (it autoquotes 'a' and 'b', rather than calling
functions named 'a' or 'b'), and this is the exact same syntax that is
being used in $foo{a=>1,b=>2}. This derives directly from the definition
of the => operator. There is no special casing anything at all. If you
think this is a reasonable change to make, you will need to explain why
adding a new special case where none currently exists will make things
easier to use or understand.
-doy
Thread Previous
|
Thread Next