Re: exists $foo[7] and delete $foo[7]

[Gurusamy Sarathy <gsar@ActiveState.com>]

On Thu, 13 Jan 2000 15:56:28 EST, Ted Ashton wrote:
>Thus it was written in the epistle of Bart Schuller,
>> On Thu, Jan 13, 2000 at 01:08:52PM -0700, Tom Christiansen wrote:
>> > This is nice and parallel.  splice() to an array is delete() to a
>> > hash.  Well, I sure thought it was.  Isn't it?  I don't really
>> > understand how to modify this for the proposed behaviour of delete
>> > $array[1].  Please help me out here.
>> 
>> Stop!
>> 
>> You can't be serious, splice changes half of your keys. There's no
>> equivalent with hashes.
>
>But he is serious.  And ought to be.  Undefined is a state of being.  That it 
>is implemented by a specific value is of significance to those who have their
>hands in the guts of perl and to this point has been of much less significance
>to the average perl programmer.  That is, to say "I defined that to be
>undefined" is a very strange twist.  This "uninitialized"--as distinct from 
>"undefined" is rather unsettling.  
>
>What Tom's talking about is that delete gets rid of a key-value pair in a 
>hash.  Eliminates it.  Deletes it if you will.

The patch I showed does the exact same thing for arrays.

>                                               Takes one of the pieces of the
>hash and stops it's existence.  The logical thing for delete to do on arrays 
>is, by my call, to do the same thing for arrays.

But, but my call, it _is_ in fact the same thing for arrays.

>                                                       Well, then, what happens 
>when a piece of an array goes away?  Is there a hole left?

Yes.  (It's just that if you try to look in the hole and try to "get" what's
not there, you get the undefined value back.  Just like for hashes.)

>                                                            No.

I disagree (obviously).

>                                                                 An array is a
>solid chunk of space.

I think your mental model about perl's arrays is too rigid.

>                      Any "holes" are undefined.

They still are, in practice.

>                                                 There isn't another option.
>Either they have something or they don't and "don't" is undef.

As I said, this part hasn't changed.  If you insist on peering through a
hole and grabbing it by its voidness, you'll still materialize an undef.

>                                                               I say make
>delete on an array element do the same thing as splicing it out (there's a 
>strange phrase :-).  

I don't understand how splice() got mixed up in all this.

splice(), push(), pop(), shift(), unshift() affect the ordering of
aggregate elements.

delete() and exists() deal with existence of those elements.

keys(), values() and each() are useful for enumerating them.

Three different, orthogonal traits.

>Oh, and let's sit on pseudo-hashes until there's been some more discussion of
>them.  So, I guess I vote 2.  Or 4. if the above definition of delete on array
>elements strikes everyone's fancy.

I'm not quite naive enough to believe there is _anything_ under the sun
that will "strike everyone's fancy" around here. :-)


Sarathy
gsar@ActiveState.com

---

References to:

Ted Ashton <ashted@southern.edu>

---

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

---