In the doc it is pointed out that the syntax:

delete b["Hello"];

Actually removes the "Hello" entry from the array.

Then says:

This confusingly appears to delete the value of b["hello"], but does not, it removes the key "hello" from the associative array.

So why not intoduce a property type syntax:

b["Hello"].remove   ???

Or how about:

b["Hello"].delete

Just for the sake of consistancy.

-C. Sauls
-Invironz

Scott Egan wrote:
> In the doc it is pointed out that the syntax:
> 
> delete b["Hello"];
> 
> Actually removes the "Hello" entry from the array.
> 
> Then says:
> 
> This confusingly appears to delete the value of b["hello"], but does not, it
> removes the key "hello" from the associative array.
> 
> So why not intoduce a property type syntax:
> 
> b["Hello"].remove   ???

Since the keyword "in" can be used in an expression to test if a key is in the array then how about using the keyword "out" to remove the key:

 if ("Hello" in b)
  out b["Hello"];

Parsing shouldn't be a problem since currently "out" can only appear in function declarations (hmm, right?).

-Ben

On Sun, 18 Apr 2004 23:55:31 +1000, "Scott Egan" <scotte@tpg.com.aux> wrote:

>In the doc it is pointed out that the syntax:
>
>delete b["Hello"];
>
>Actually removes the "Hello" entry from the array.
>
>Then says:
>
>This confusingly appears to delete the value of b["hello"], but does not, it removes the key "hello" from the associative array.
>
>So why not intoduce a property type syntax:
>
>b["Hello"].remove   ???
>
>
>

Ben Hinkle <bhinkle4@juno.com> wrote:

> Since the keyword "in" can be used in an expression to test if a key is in the array then how about using the keyword "out" to remove the key:
> 
>  if ("Hello" in b)
>   out b["Hello"];

That would be using 'out' as a verb, as in "outing" someone :-)

I think .remove makes good sense. 'delete' is already overloaded (or, would be if used for removal as well), and indicates destruction of an object, as it does in C++ (and Walter would like D to be "familiar" to C++ programmers).


-- 
dave

Hear Hear!

While we're at it, I'd like to request a ".clear" or ".flush" or ".removeall" property. In addition, there's the related issue of not being able to pre-allocate AA space. Perhaps that's what an assignment to AA.length might do ?

- Kris


"Scott Egan" <scotte@tpg.com.aux> wrote in message news:c5u1ck$21kh$1@digitaldaemon.com...
> In the doc it is pointed out that the syntax:
>
> delete b["Hello"];
>
> Actually removes the "Hello" entry from the array.
>
> Then says:
>
> This confusingly appears to delete the value of b["hello"], but does not,
it
> removes the key "hello" from the associative array.
>
> So why not intoduce a property type syntax:
>
> b["Hello"].remove   ???
>
>
>
>

On Sun, 18 Apr 2004 17:25:35 +0000 (UTC), Dave Sieber
<dsieber@spamnot.sbcglobal.net> wrote:

>Ben Hinkle <bhinkle4@juno.com> wrote:
>
>> Since the keyword "in" can be used in an expression to test if a key is in the array then how about using the keyword "out" to remove the key:
>> 
>>  if ("Hello" in b)
>>   out b["Hello"];
>
>That would be using 'out' as a verb, as in "outing" someone :-)

or a command - as in "Out damn spot! Out, I say!"
Though it is true
 out damn["spot"];
reads like shouting. Going even further the ! from template
instantiation can be used for extra effect
 out damn["spot"]!;

... just kidding ...

>I think .remove makes good sense. 'delete' is already overloaded (or, would be if used for removal as well), and indicates destruction of an object, as it does in C++ (and Walter would like D to be "familiar" to C++ programmers).

Sure. If property/function is used it should be written like
 b.remove("Hello")
instead of
 b["Hello"].remove
since the property is for the assoc array. Otherwise what if
b["Hello"] evaluated to an object that had a .remove property?

Ben Hinkle <bhinkle4@juno.com> wrote:

> or a command - as in "Out damn spot! Out, I say!"
> Though it is true
>  out damn["spot"];
> reads like shouting. Going even further the ! from template
> instantiation can be used for extra effect
>  out damn["spot"]!;

couldn't we optimize it:

   inout damn["spot"]!;

(okay, this is getting silly :-)

> Sure. If property/function is used it should be written like
>  b.remove("Hello")
> instead of
>  b["Hello"].remove
> since the property is for the assoc array. Otherwise what if
> b["Hello"] evaluated to an object that had a .remove property?

Good point indeed. I bet this would become a newbie FAQ.

-- 
dave

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote:

> While we're at it, I'd like to request a ".clear" or ".flush" or ".removeall" property.

I like .clear, because I'm used to it from STL in C++ and it's not used for anything else. And I like the idea of being as consistent as possible, for obvious reasons.

> In addition, there's the related issue of not
> being able to pre-allocate AA space. Perhaps that's what an assignment
> to AA.length might do ?

I like that very much too.

-- 
dave

> While we're at it, I'd like to request a ".clear" or ".flush" or ".removeall" property.

.clear gets my vote

> In addition, there's the related issue of not being
> able to pre-allocate AA space. Perhaps that's what an assignment to
> AA.length might do ?

I'd prefer another property like "reserve" or "capacity" since
1) setting AA.length and then getting wouldn't return the set value
2) reserve/capacity should be available for dynamic arrays as well (setting
the length of dynamic arrays are resetting doesn't always work)

-Ben

"Ben Hinkle" <bhinkle4@juno.com> wrote:

> I'd prefer another property like "reserve" or "capacity" since
> 1) setting AA.length and then getting wouldn't return the set value
> 2) reserve/capacity should be available for dynamic arrays as well
> (setting the length of dynamic arrays are resetting doesn't always
> work)

Argh, cancel my earlier vote, Ben is right. I wasn't thinking clearly. We want to reserve space!


-- 
dave