I was just reading through the spec and noticed that delete foo["key"] deletes
the key and not the value.
This seems very very very bad.  What if it's a sparse array?  delete arr[2] and
delete arr2[2] could do
completely different things!  Seems to me there should be separate syntax for
deleting a key from an
associative array.

-Sha

"Sha Chancellor" <Sha_member@pathlink.com> wrote in message news:d77bsn$1n47$1@digitaldaemon.com...
> I was just reading through the spec and noticed that delete foo["key"] deletes
> the key and not the value.
> This seems very very very bad.  What if it's a sparse array?  delete arr[2] and
> delete arr2[2] could do
> completely different things!  Seems to me there should be separate syntax for
> deleting a key from an
> associative array.
>
> -Sha
>
>

Not sure eactly what you mean.
Any chance you could give the address (or page name) of the
documentation page that you were looking at,
and a little more detail about what you mean, please?

TZ

"TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d79n43$l8l$1@digitaldaemon.com...
> "Sha Chancellor" <Sha_member@pathlink.com> wrote in message
> news:d77bsn$1n47$1@digitaldaemon.com...
> Not sure eactly what you mean.
> Any chance you could give the address (or page name) of the
> documentation page that you were looking at,
> and a little more detail about what you mean, please?

Say you have two arrays.  One is an AA, one is a regular arry.  A is a class:

A[] arr1;
A[int] arr2;

Now, let's add some things:

arr1.length=2;
arr1[0]=new A;
arr2[1]=new A;

arr2[0]=new A;
arr2[1]=new A;

Now let's try deleting something:

delete arr1[1];
delete arr2[1];

Now here's the thing:  delete arr1[1] deletes the class instance held at that location.  There is still an element at arr1[1]; it's just not a valid reference;

But delete arr2[1] deletes the key-value pair in the AA.  The class instance that was pointed to by that key still exists (though if there were no other references to it, it would be GCed).  This is inconsistent and *gasp* context-sensitive grammar!  Normally, arr2[1] returns the value of that key; but delete arr2[1] functions differently.

The solution would be to have a .remove() property for AAs, such as:

arr2.remove(1);

Which would remove key 1 from the AA, while

delete arr2[1];

Would delete the class ref pointed to by arr2[1].  The key would still exist.

The problem, I think, comes with deprecating the delete syntax and bringing in the new; all the existing delete arr[i] would still be valid syntax, but would have a different effect.  There would be no way for the compiler to say "hey, this syntax has been deprecated, change it to .remove()."  Perhaps there would have to be a few transition versions where the delete syntax would be illegal altogether, to allow people to port their code to the new .remove() syntax, and then the delete could be brought back.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d7a545$v1g$1@digitaldaemon.com...
> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d79n43$l8l$1@digitaldaemon.com...
> > "Sha Chancellor" <Sha_member@pathlink.com> wrote in message
> > news:d77bsn$1n47$1@digitaldaemon.com...
> > Not sure eactly what you mean.
> > Any chance you could give the address (or page name) of the
> > documentation page that you were looking at,
> > and a little more detail about what you mean, please?
>
> Say you have two arrays.  One is an AA, one is a regular arry.  A is a class:
>
> A[] arr1;
> A[int] arr2;
>
> Now, let's add some things:
>
> arr1.length=2;
> arr1[0]=new A;
> arr2[1]=new A;
>
> arr2[0]=new A;
> arr2[1]=new A;
>
> Now let's try deleting something:
>
> delete arr1[1];
> delete arr2[1];
>
> Now here's the thing:  delete arr1[1] deletes the class instance held at that location.  There is still an element at arr1[1]; it's just not a valid reference;
>
> But delete arr2[1] deletes the key-value pair in the AA.  The class instance that was pointed to by that key still exists (though if there were no other references to it, it would be GCed).  This is inconsistent and *gasp* context-sensitive grammar!  Normally, arr2[1] returns the value of that key; but delete arr2[1] functions differently.
>
> The solution would be to have a .remove() property for AAs, such as:
>
> arr2.remove(1);
>
> Which would remove key 1 from the AA, while
>
> delete arr2[1];
>
> Would delete the class ref pointed to by arr2[1].  The key would still exist.
>
> The problem, I think, comes with deprecating the delete syntax and bringing in the new; all the existing delete arr[i] would still be valid syntax, but would have a different effect.  There would be no way for the compiler to say "hey, this syntax has been deprecated, change it to .remove()."  Perhaps there would have to be a few transition versions where the delete syntax would be illegal altogether, to allow people to port their code to the new .remove() syntax, and then the delete could be brought back.
>
>

Okay, so then the concern is over the fact that the delete function,
when used on an element of an array, is intercepted and used to
effect the array itself rather than that element, if and only if that array
happens to be associative.

Okay, that makes sense.  Yes, I agree.  A separate "remove" function would most likely have been better... but there is the issue of how a change could be safely introduced at this point.

Having "delete" cause an error whenever used in accosiative arrays for some arbitrary number of
DMD versions would have unpredictable results since there's no way to know how much (or which) source
code would be updated and/or tested durring that time.  This may be a case where some loss has to be
accepted in order for progress to happen.  DMD is afterall, still technically in beta testing of pre-1.0 versions,
and the D specifications are still being evolved into a first release draft as I understand it.

I personally have no problem with the current functionality,
and would therefore guess that many other D programmers
also have not ran into problems with the delete function working the way it currently does,
but your argument makes sense, and I also recognize that a problem for
any D programmer is in the long run a problem for the D language,
and therefore a potential problem for all D programmers...

So with that in mind,
here's my recommendation...
First, add a "remove" function for removal of a key and it's associated element from an associative array,
to replace the current functionality of "delete" in that context.
Let delete continue to work as it does in cases where no other meaning of "delete" would be possible,
(for backward compatibility, and also because it makes sense in that context)
and replace delete's current functionality in other cases with a functionality that is
more consistant with how it works when used on an element of an ordinary array.

Or, another possibility would be to deprecate the use of "delete" and
replace it with "del" and "remove" for different current uses of delete...
but I would not recommend this option since I see the other as a better choice.

TZ