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

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

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?

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"]!;

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?

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,

removes the key "hello" from the associative array.
So why not intoduce a property type syntax:
b["Hello"].remove ???

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

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)

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

it

removes the key "hello" from the associative array.
So why not intoduce a property type syntax:
b["Hello"].remove ???

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

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

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

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

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

it

removes the key "hello" from the associative array.
So why not intoduce a property type syntax:
b["Hello"].remove ???

.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

it

removes the key "hello" from the associative array.
So why not intoduce a property type syntax:
b["Hello"].remove ???

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

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

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

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

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,

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.

.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

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

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

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

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

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

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

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);