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

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

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

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

"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

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

"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

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

"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