[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

Re: On Pseudohashes



Tom Christiansen writes:
> I propose that we collectively consider the needs that pseudohashes
> were designed to meet, then assess the extent to which those needs
> have been adequately met.  This might help those of us who aren't
> completely fond of them to appreciate them a bit better.  More
> importantly, it offers a process we can explore to help decide
> whether the experiment should be deemed a success or a failure--or
> more likely, some admixture of the two.

Thanks for a valuable suggestion.

> What are their real problems?  I think for many of you, their biggest
> problem is that they expose their underlying implementation as mere
> arrays to the programmer's prying eyes.  They further clutter
> themselves by placing details of their internal structure right
> there for all to see by keeping their valid field names in their
> zeroth element.

Exhibitionism was always Perl's way of living.  I think most people
hate is not the fact of exhibiting internals, but the choice of zeroth
element to keep these pesky guys.

2/3 seriously: what if we keep them at $array[-1]:

  @foo = ( { %keys }, 1, 2, 3 );
  shift_and_mark_as hash(@foo);		# Now the access to @foo sees (1,2,3)

Basically, this adds a flag to PVAV which means "AvARRAY is shifted
wrt AvALLOC, but the element is still there".  This will also will
force minor changes in av.c where AvARRAY != AvALLOC logic is
concerned, but since one does not shift/unshift/splice pseudohashes,
simply prohibiting these operations on pseudohashes should be OK.

Or something similar.

Ilya


Follow-Ups from:
Dan Sugalski <dan@sidhe.org>
References to:
Tom Christiansen <tchrist@chthon.perl.com>

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]