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   ???

This is all getting very frightening.  It looks like a useless attribute read, but it's an operation?  At the very least, it should look like a function application. (ie b.remove("Hello") )  It's more readable, generic, and consistent with the rest of the language.

Maybe the right thing is to simply remove associative arrays from the language.  They're certainly not needed now that D templates have come of age, as it were.

 -- andy

Yes, ".reserve" is a better notion.

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:c5ul2t$2v8j$1@digitaldaemon.com...
>
> > 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
>
>

Although I can see a good reason why Walter would not want to do this.

Thus far there appears to be only simple properties used.. If Walter starts attaching methods suddenly tou end up with complex classes and lots of baggage.




"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c5uhj6$2qbl$1@digitaldaemon.com...
> 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   ???
> >
> >
> >
> >
>
>

"Scott Egan" <scotte@tpg.com.aux> wrote in message news:c5utsv$asm$1@digitaldaemon.com...
> Although I can see a good reason why Walter would not want to do this.
>
> Thus far there appears to be only simple properties used.. If Walter
starts
> attaching methods suddenly tou end up with complex classes and lots of baggage.

I would agree in principle Scott; but in this case we're talking about AAs, which are indeed a bunch of (somewhat complex) helper methods.

I think what we're saying here is that the AA functionality is not fleshed-out quite enough. I'm already using Ben's nifty hack for pre-allocating space, and for clearing an AA, because I'm not interested in producing my own AA implementation. Needless to say, those hacks are not the ideal way to accomplish the necessary functionality. Hence, we're looking for a resolution.

Besides, none of the AA properties (except .size) represent the simple property you describe; each of them would surely have to traverse the construct?

- Kris

Andy Friesen wrote:
>> So why not intoduce a property type syntax:
>>
>> b["Hello"].remove   ???
> 
> 
> This is all getting very frightening.  It looks like a useless attribute read, but it's an operation?  At the very least, it should look like a function application. (ie b.remove("Hello") )  It's more readable, generic, and consistent with the rest of the language.

Besides, b["Hello"].remove is just as ambiguous as the current delete. Do you want to remove the object at "Hello", or do you want to access that object's remove property?

I only see two ways to solve this. Either there has to be a new operator, or associative arrays need an intrinsic method to remove an element. I vote for the latter, since it IS just another operation on the array. It'd also make it easier to be code-compatible with a custom class that mimics an assiciative array (a useful property for templates).

So I vote for
b.remove("Hello");



Hauke

> Maybe the right thing is to simply remove associative arrays from the language.  They're certainly not needed now that D templates have come of age, as it were.

That is tempting. It's also tempting to just document the implementation as a dynamic array of pointers and let users have access to them and let other data structures go into the library. For example, if a property .dynamic was added that effectively cast to void*[] then we'd be able to write things like

 int[char[]] b;
 b.dynamic.length = 100000; // pre-allocate pointer array
 b.dynamic[] = null;        // remove all keys from b
 void*[100] ptrs;
 b.dynamic = ptrs[0 .. 100];

I don't know if properties are flexible enough to handle these kinds of things, though. Can a property return a reference to the object? I don't think it can, but I'm not sure. Also a drawback of this approach would be that the nodes aren't documented - ie the type of the pointers is void*. Anyway, it's an option.

-Ben

Hauke Duden wrote:

[...]
> So I vote for
> b.remove("Hello");

Yeah. That's the way to Fort Knox.

So long!

So to summerise the opinions expressed so far:

aa.remove("Colour")
aa.clear
aa.reserve = 354

Happy that I was wrong to suggest aa.["Colour"].remove for all the reasons offered.


"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:c5uv45$cnf$1@digitaldaemon.com...
> Andy Friesen wrote:
> >> So why not intoduce a property type syntax:
> >>
> >> b["Hello"].remove   ???
> >
> >
> > This is all getting very frightening.  It looks like a useless attribute read, but it's an operation?  At the very least, it should look like a function application. (ie b.remove("Hello") )  It's more readable, generic, and consistent with the rest of the language.
>
> Besides, b["Hello"].remove is just as ambiguous as the current delete. Do you want to remove the object at "Hello", or do you want to access that object's remove property?
>
> I only see two ways to solve this. Either there has to be a new operator, or associative arrays need an intrinsic method to remove an element. I vote for the latter, since it IS just another operation on the array. It'd also make it easier to be code-compatible with a custom class that mimics an assiciative array (a useful property for templates).
>
> So I vote for
> b.remove("Hello");
>
>
>
> Hauke

Scott Egan wrote:
> So to summerise the opinions expressed so far:
> 
> aa.remove("Colour")
> aa.clear
> aa.reserve = 354
> 
> Happy that I was wrong to suggest aa.["Colour"].remove for all the reasons
> offered.

I'd be happier if clear and reserve looked like methods too.  Operations should not look like attributes.

(ie aa.clear() and aa.reserve(354) )

 -- andy

Andy Friesen <andy@ikagames.com> wrote:

> I'd be happier if clear and reserve looked like methods too. Operations should not look like attributes.
> 
> (ie aa.clear() and aa.reserve(354) )

With a long C/C++ background, I like to see them as methods too, but array's in D have .dup, .reverse, .sort, all of which "do something", and .length is a getter/setter. I think it's the D style, and I'll get used to it.  I like .reserve as a property, which would be analogous to .length, so that you could query its current value, for instance.

-- 
dave