More Undef vs. Null...
Will Coleda
$ cat foo.pir
.sub main
load_bytecode 'dumper.pir'
$P1 = new .Hash
$P2 = $P1['bork']
_dumper ($P2)
$P1 = new .ResizablePMCArray
$P1[200] = 'zdrasti'
$P2 = $P1[201]
_dumper ($P2)
$P2 = $P1[100]
_dumper ($P2)
.end
$ ./parrot foo.pir
"VAR1" => null
"VAR1" => undef
"VAR1" => undef
--
Will "Coke" Coleda
wi...@coleda.com
Leopold Toetsch
> Are Hash and Array supposed to have different results on unset keys?
The .Undefs returned by Arrays are IMHO and unfortunate leftover of he early
PerlArrays. We've managed to change the return result of hashes to .Null, so
this should be possible with arrays too.
leo
Jonathan Worthington
an undef back and testing for it that's the issue.
Patch attached that cleans up the code to return PMCNULL instead of
undef anyway. I don't really want to apply this until I hear a design
decision though, and preferably have time to fix some of the code in the
repository that depends on the difference (or have other people say they
are willing to help in that).
Thanks,
Jonathan
Patrick R. Michaud
> Leopold Toetsch wrote:
> >Am Mittwoch, 20. Dezember 2006 05:59 schrieb Will Coleda:
> >
> >>Are Hash and Array supposed to have different results on unset keys?
> >>
> >
> >The .Undefs returned by Arrays are IMHO and unfortunate leftover of he
> >early PerlArrays. We've managed to change the return result of hashes to
> >.Null, so this should be possible with arrays too.
> >
> Changing the PMCs ain't hard. It's changing all the code that is getting
> an undef back and testing for it that's the issue.
And once again, PGE, PAST-pm, perl6, and others may have a lot of
places that expect to get Undef back instead of PMCNULL. We
can certainly see about updating them to check for PMCNULL instead
of undef, but they certainly exist.
I asked about this particular discrepancy a couple of months ago
(on IRC, I think), and IIRC the conclusion I was given then was
something to the effect of "since ResizablePMCArray is auto-extendable
it should return undefs for non-existent values." Leo is correct
that this is probably coming from an original perl5-ish
interpretation of how things work.
I'm not strongly in favor or opposed to a particular design --
just pointing out that changing RPA to return NULL will probably
impact a fair bit of PGE, PAST-pm, perl6, abc, etc. But if there's
going to be a change, it'll be easier to fix it now rather than
later.
Pm
jerry gay
this requires a coordinated effort. my suggestion is to dedicate a day
to this fix. we've already seen what successes come from hackathons
and bug days--i shouldn't need to justify this. this is a *perfect*
candidate for something similar.
let's pick a day within the next month to do this. we can either
dedicate the day to trunk changes, or perhaps create a special branch.
then we can apply, get smoke reports of breakage, analyze, assign
tasks, fix, review patches of non-committers, apply, and retest. the
most direct route to fixing this anomaly is by involving the
community.
~jerry
Allison Randal
>>
>> Patch attached that cleans up the code to return PMCNULL instead of
>> undef anyway. I don't really want to apply this until I hear a design
The design decision is: let's be consistent and use null.
jerry gay wrote:
> let's pick a day within the next month to do this. we can either
> dedicate the day to trunk changes, or perhaps create a special branch.
> then we can apply, get smoke reports of breakage, analyze, assign
> tasks, fix, review patches of non-committers, apply, and retest. the
> most direct route to fixing this anomaly is by involving the
> community.
This is a good solution. Branches are cheap, so we might as well make
one, and then roll it in at the end of the day if all goes smoothly.
In the mean time, add a note about the change to DEPRECATED.pod now.
Allison