Front page | perl.perl5.porters |
Postings from April 2018
On Sat, Apr 21, 2018 at 02:10:05PM -0700, L A Walsh wrote:
> Two answers. The first answer: it never gets that far.
>
> PERL5OPT="" perl /tmp/ovld.pl
> Not an unblessed ARRAY reference at /tmp/ovld.pl line 9.
That's because specifically to get round the problem of the overloading
ambiguity, the perl autodedef ref implementation was changed so that it
croaked on blessed refs. This made things even worse - you could never
use the new syntax in any place where there was a possibility that the
ref you get passed may have been blessed. This was a big motivation for
eliminating the feature.
> 2nd answer -- this was brought up by Dan Brook. I answered:
> In any case where there is ambiguity, the compiler must throw an error(like):
>
> Ambiguous dereference @ line 13: Sigil required.
>
> My suggestion was to auto-dereference references where perl knew the type
> of the reference. If it reference is ambiguous, it can't know the type.
Since perl almost never knows the type of a reference at compile-time,
how can this ever work? Can you give a more concrete example?
> The 2nd part was to allow a scalar that holds 'undef' to be
> auto-vivified where only 1 solution would work. I.e.
>
> my $ref
> push $ref, 1;
>
> would autovivify a temporary array pointed to by '$ref', as push requires
> an array.
>
> Similarly:
> my $ref;
> my $val=pop $ref;
>
> would act identically to:
>
> my $val=pop @$ref;
>
> Any case where perl has an ambiguous choice, must be flagged as an
> error. I can't see any other option being correct.
Do you mean as a compile-time error or a run-time error?
--
The Enterprise successfully ferries an alien VIP from one place to another
without serious incident.
-- Things That Never Happen in "Star Trek" #7
Thread Next