www.digitalmars.com         C & C++   DMDScript  

D - Assoc Array delete syntax

reply "Scott Egan" <scotte tpg.com.aux> writes:
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   ???
Apr 18 2004
next sibling parent "C. Sauls" <ibisbasenji yahoo.com> writes:
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   ???
Apr 18 2004
prev sibling next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
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   ???
Apr 18 2004
parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
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
Apr 18 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
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?
Apr 18 2004
parent Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
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
Apr 18 2004
prev sibling next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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   ???
Apr 18 2004
next sibling parent Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"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
Apr 18 2004
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
 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
Apr 18 2004
next sibling parent Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"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
Apr 18 2004
prev sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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
Apr 18 2004
prev sibling next sibling parent reply "Scott Egan" <scotte tpg.com.aux> writes:
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   ???
Apr 18 2004
next sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"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
Apr 18 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Assoc arrays and normal arrays already do sophisticated things. Consider
.dup

If we are to have some containers built-in to the language, I don't see any
reason to shy away from a good, succinct albeit minimally comprehensive set
of operations.

After all, the

    delete aa[elem];

syntax is positively dreadful, and it still carries out a non-trivial
action.

"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.




 "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   ???
Apr 20 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
.remove (1) and .clear (all) have my vote

I will be using clear() in DTL, so it's consistent.

"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   ???
Apr 20 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
Apr 18 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Apr 18 2004
next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Hauke Duden wrote:

[...]

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


Yeah. That's the way to Fort Knox.

So long!
Apr 19 2004
prev sibling parent reply "Scott Egan" <scotte tpg.com.aux> writes:
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
Apr 19 2004
parent reply Andy Friesen <andy ikagames.com> writes:
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
Apr 19 2004
parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
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
Apr 19 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message
news:Xns94D051AA3F0F6dsiebersbc 63.105.9.61...

 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.


Aha! The light's gone on!

.dup does not modify the object (or receiver, in Ruby-speak; I've been
dazzled by its multi-faceted beauty), so it does not need to be shown as a
(modifying) method.

But I would suggest that .clear, .reserve, .dup and .remove all need method
call syntax.
Apr 20 2004
parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote:


 .dup does not modify the object (or receiver, in Ruby-speak; I've been
 dazzled by its multi-faceted beauty), so it does not need to be shown
 as a (modifying) method.


I have a Ruby book here on the shelf, but alas have not taken the time to 
dig into it. I was interested in it as prototyping/proof-of-concept 
language (a need which I still have).  Your enthusiasm makes me want to go 
get the book out again :-)

-- 
dave
Apr 20 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message
news:Xns94D198173912Ddsiebersbc 63.105.9.61...

 "Matthew" <matthew.hat stlsoft.dot.org> wrote:


 .dup does not modify the object (or receiver, in Ruby-speak; I've been
 dazzled by its multi-faceted beauty), so it does not need to be shown
 as a (modifying) method.


 I have a Ruby book here on the shelf, but alas have not taken the time to
 dig into it. I was interested in it as prototyping/proof-of-concept
 language (a need which I still have).  Your enthusiasm makes me want to go
 get the book out again :-)


I did the July instalment of my CUJ column while I was in England. My
brother-in-law happened to have a Ruby book, and I started reading it, and
decided that would be the subject of the next column. It was really easy,
and really enjoyable, and I now think that Ruby will be my scripting
language of choice. It's like the best bits of Perl and Python in one, with
other great stuff as well, such as mixins.

I'm very pleased with the utility, especially now it has a decent recursive
file-system search module. ;)

I was able to insert unittesting code into all 300 STLSoft library files
with a relatively simple script. I felt like the cat with the cream.

For anyone interested in using the recls-Ruby mapping, it'll be with version
1.4 onwards, which I expect to release on the recls website
(http://recls.org/) sometime in the next few weeks.
Apr 20 2004
parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote:


 I did the July instalment of my CUJ column while I was in England. My
 brother-in-law happened to have a Ruby book, and I started reading it,
 and decided that would be the subject of the next column. It was
 really easy, and really enjoyable, and I now think that Ruby will be
 my scripting language of choice. It's like the best bits of Perl and
 Python in one, with other great stuff as well, such as mixins.


Yes, that's why I bought the Ruby book -- didn't like Perl from day one, 
and Python is too weird :-) Although I have a friend who loves Python...

I've now pulled the Ruby book out. I think I'll start looking into it 
again. Always good to learn some new languages!

-- 
dave
Apr 20 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Did into the Enumeration module. I predict we'll be seeing some of that in D
sometime soon ... ;)

"Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message
news:Xns94D1BD64511dsiebersbc 63.105.9.61...

 "Matthew" <matthew.hat stlsoft.dot.org> wrote:


 I did the July instalment of my CUJ column while I was in England. My
 brother-in-law happened to have a Ruby book, and I started reading it,
 and decided that would be the subject of the next column. It was
 really easy, and really enjoyable, and I now think that Ruby will be
 my scripting language of choice. It's like the best bits of Perl and
 Python in one, with other great stuff as well, such as mixins.


 Yes, that's why I bought the Ruby book -- didn't like Perl from day one,
 and Python is too weird :-) Although I have a friend who loves Python...

 I've now pulled the Ruby book out. I think I'll start looking into it
 again. Always good to learn some new languages!

 -- 
 dave
Apr 20 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
I meant to say "dig", not "did".

Jet-lag ...

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c64jrp$1lak$1 digitaldaemon.com...

 Did into the Enumeration module. I predict we'll be seeing some of that in


D

 sometime soon ... ;)

 "Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message
 news:Xns94D1BD64511dsiebersbc 63.105.9.61...

 "Matthew" <matthew.hat stlsoft.dot.org> wrote:


 I did the July instalment of my CUJ column while I was in England. My
 brother-in-law happened to have a Ruby book, and I started reading it,
 and decided that would be the subject of the next column. It was
 really easy, and really enjoyable, and I now think that Ruby will be
 my scripting language of choice. It's like the best bits of Perl and
 Python in one, with other great stuff as well, such as mixins.


 Yes, that's why I bought the Ruby book -- didn't like Perl from day one,
 and Python is too weird :-) Although I have a friend who loves Python...

 I've now pulled the Ruby book out. I think I'll start looking into it
 again. Always good to learn some new languages!

 -- 
 dave
Apr 20 2004
parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote:


 I meant to say "dig", not "did".


Yep, my book has a section on Enumerable (it's the "Programming Ruby" book, 
by Thomas & Hunt).  I would really love to see some of these concepts work 
their way into D!


 Jet-lag ...


Or maybe a rare form of Let-Jag...? :-)

-- 
dave
Apr 20 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message
news:Xns94D1C50285ACEdsiebersbc 63.105.9.61...

 "Matthew" <matthew.hat stlsoft.dot.org> wrote:


 I meant to say "dig", not "did".


 Yep, my book has a section on Enumerable (it's the "Programming Ruby"


book,

 by Thomas & Hunt).  I would really love to see some of these concepts work
 their way into D!


It's looking pretty likely at this point.


 Jet-lag ...


 Or maybe a rare form of Let-Jag...? :-)


Could be. The little man just came and switched me off again for a couple of
hours. Not sure I feel better ... <yawn> ... I may go back again. ;)
Apr 20 2004
prev sibling next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
 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
Apr 18 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:c5urke$7c0$1 digitaldaemon.com...

 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.


Yes. When I said in an earlier post that I support .clear and .remove, I
meant with the .clear() and .remove(elem) syntax.

For that matter, therefore, I guess .dup should be .dup() to indicate it's
taking an action.

Unless we go with Ruby, and indicate modifying "attribute" methods with a
trailing !, as in

    int [int]    aa = ...;

    aa.size;
    aa.dup!
    aa.clear!
    aa.remove!(10)

Personally, I really like this, but I've just fallen head over heels in love
with Ruby, so I may not be particularly dispationate at this juncture. :)

It also has "query" attributes with a trailing ?, as in

    aa.empty?

However, I recognise that both these things will upset the pure parser guys,
so maybe we stick with the method call syntax, as in

    aa.size;
    aa.dup();
    aa.clear();
    aa.remove(10);
Apr 20 2004