I'd like to solicit opinion on method naming conventions.

In C++, std::map's entry access is via the following methods:

    - operator[] (key_type key) - this returns the element for the given key, or
creates it if it does not exist. It never returns a "does-not-exist" value
    - find(key_type key) - this returns an iterator for the element, or the end()
iterator if it does not exist

In Ruby, we have the useful syntactic convention of ? for testing:

    - include?(val)

For D, we don't have iterators - of which more, later ... - and we don't have the ? postfix. I'd like to suggest a simple convention:

    - opIndex, where appropriate never returns null. Always returns the requested
element, or throws an InvalidKeyException (or similar)
    - getXyz() - same semantics as opIndex.
    - findXyz() - tests the existence of the element, or returns null.

The alternatives to this are, IMO, far less attractive. We can either:

A. Only have the getXyz() version, which means the client code that wants to test
existence has to have try-catch clutter
B. Have getXyz(key_type key) and getXyz(key_type key, out bool bExists)
overloads, which is confusing and also precludes the opIndex form.

There are two downsides to my proposed approach:

1. People might get confused. That's the reason I'm proposing that we address
this now, by adopting a common convention.
2. We can't return a null-value for built-in types. I would suggest that this
isn't a problem for most cases, since we aren't storing built-in types in most
cases. However, there are some cases where they are used, so maybe we should also
include a hasXyz() method, which returns a boolean indicator.

Responses?

Matthew wrote:
<snip>
> For D, we don't have iterators - of which more, later ... - and we don't have the ? postfix. I'd like to suggest a simple convention:
> 
> - opIndex, where appropriate never returns null. Always returns the requested element, or throws an InvalidKeyException (or similar)
> - getXyz() - same semantics as opIndex.
> - findXyz() - tests the existence of the element, or returns null.

At the moment, associative arrays return the value or the value type's .init, which is of course null for classes.  But in general, a value can itself be null, and sometimes it's useful to be able to distinguish between the two cases.

But yes, I guess it can be useful to have null indicating absence of the element.  But AAs versus LAs are already inconsistent here, and you could say we're stuck with this now.  Guess it's a matter of remembering to documenting your class....

> The alternatives to this are, IMO, far less attractive. We can either:
> 
> A. Only have the getXyz() version, which means the client code that wants to test existence has to have try-catch clutter
> B. Have getXyz(key_type key) and getXyz(key_type key, out bool bExists) overloads, which is confusing and also precludes the opIndex form.
<snip>

C. the approach you suggested further down.

We ought to have an opIn.  But because it's really the RHS type of such an expression that wants to control the behaviour, there are complications with naming/priority.  Meanwhile, mine uses contains.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <cd30iv$17m8$1@digitaldaemon.com>, Matthew says...

>Responses?

what on Earth is wrong with

#    if (a in map)
#    {
#        //...
#    }

?

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:cd32i7$1af9$1@digitaldaemon.com...
> Matthew wrote:
> <snip>
> > For D, we don't have iterators - of which more, later ... - and we don't have the ? postfix. I'd like to suggest a simple convention:
> >
> > - opIndex, where appropriate never returns null. Always returns the
> > requested element, or throws an InvalidKeyException (or similar)
> > - getXyz() - same semantics as opIndex.
> > - findXyz() - tests the existence of the element, or returns null.
>
> At the moment, associative arrays return the value or the value type's .init, which is of course null for classes.  But in general, a value can itself be null, and sometimes it's useful to be able to distinguish between the two cases.
>
> But yes, I guess it can be useful to have null indicating absence of the element.  But AAs versus LAs are already inconsistent here, and you could say we're stuck with this now.  Guess it's a matter of remembering to documenting your class....
>
> > The alternatives to this are, IMO, far less attractive. We can either:
> >
> > A. Only have the getXyz() version, which means the client code that
> > wants to test existence has to have try-catch clutter
> > B. Have getXyz(key_type key) and getXyz(key_type key, out bool
> > bExists) overloads, which is confusing and also precludes the opIndex
> > form.
> <snip>
>
> C. the approach you suggested further down.
>
> We ought to have an opIn.  But because it's really the RHS type of such an expression that wants to control the behaviour, there are complications with naming/priority.  Meanwhile, mine uses contains.
>

opIn would be really great (although it is now a part of an expression and
not an operator)
And having "in" work for arrays would be cool (just like it works for
associative arrays), it happens sometimes that you need to check
if something is in the array and i find my self rewriting something that the
compiler could do instead of me.

bool found=false;
foreach(T t; array)
{
    if(myElem==t)}{found =true;break;}
}
if(found)...

It would rally nice if i could just write:
if(myElem in array)
instead of the above.

I use contains also :)


> Stewart.
>
> --
> My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cd34as$1dct$1@digitaldaemon.com...
> In article <cd30iv$17m8$1@digitaldaemon.com>, Matthew says...
>
> >Responses?
>
> what on Earth is wrong with
>
> #    if (a in map)
> #    {
> #        //...
> #    }
>
> ?

Is this a genuine, considered response, or are you just seeking to waste my eye-time?

I take it you feel built-in associative arrays represent the totality of associative containers we'll ever consider for D. I disagree, and am hoping to get some useful feedback in that regard.

I like opIn, but that's only useful when a given "container" can contain only one type of element.

I'm currently working on a mapping to D of my Open-RJ library (shortly to be
released on SF, under BSD) which is an implementation of the Record-Jar format.
(And only 5KB!)

A database contains records, and records contains fields. However, it's also useful to be able to treat a database as a collection of fields. Hence, the Database class allows access to Fields and/or to Records. As such, opIn (or contains) would only work for Record (since record is the value_type of Database). When wanting to to deduce whether a given field was in the database, I'm suggesting I'd the findField() syntax.

I'm just as happy to call it containsField() as findField(), in fact I like that a bit better. The point I want to discuss is that we have an identified convention for the two forms of index/key based retrieval: return null-value on failure, and throw-exception on failure.



"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cd34m0$1e01$1@digitaldaemon.com...
> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:cd32i7$1af9$1@digitaldaemon.com...
> > Matthew wrote:
> > <snip>
> > > For D, we don't have iterators - of which more, later ... - and we don't have the ? postfix. I'd like to suggest a simple convention:
> > >
> > > - opIndex, where appropriate never returns null. Always returns the
> > > requested element, or throws an InvalidKeyException (or similar)
> > > - getXyz() - same semantics as opIndex.
> > > - findXyz() - tests the existence of the element, or returns null.
> >
> > At the moment, associative arrays return the value or the value type's .init, which is of course null for classes.  But in general, a value can itself be null, and sometimes it's useful to be able to distinguish between the two cases.
> >
> > But yes, I guess it can be useful to have null indicating absence of the element.  But AAs versus LAs are already inconsistent here, and you could say we're stuck with this now.  Guess it's a matter of remembering to documenting your class....
> >
> > > The alternatives to this are, IMO, far less attractive. We can either:
> > >
> > > A. Only have the getXyz() version, which means the client code that
> > > wants to test existence has to have try-catch clutter
> > > B. Have getXyz(key_type key) and getXyz(key_type key, out bool
> > > bExists) overloads, which is confusing and also precludes the opIndex
> > > form.
> > <snip>
> >
> > C. the approach you suggested further down.
> >
> > We ought to have an opIn.  But because it's really the RHS type of such an expression that wants to control the behaviour, there are complications with naming/priority.  Meanwhile, mine uses contains.
> >
>
> opIn would be really great (although it is now a part of an expression and
> not an operator)
> And having "in" work for arrays would be cool (just like it works for
> associative arrays), it happens sometimes that you need to check
> if something is in the array and i find my self rewriting something that the
> compiler could do instead of me.
>
> bool found=false;
> foreach(T t; array)
> {
>     if(myElem==t)}{found =true;break;}
> }
> if(found)...
>
> It would rally nice if i could just write:
> if(myElem in array)
> instead of the above.
>
> I use contains also :)
>
>
> > Stewart.
> >
> > --
> > My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.
>
>

In article <cd359e$1f32$1@digitaldaemon.com>, Matthew says...

>Is this a genuine, considered response, or are you just seeking to waste my eye-time?

Is this a genuine, considered question, or are you just in a bad mood for some reason?

I assume you don't SERIOUSLY imagine that I would deliberately seek to waste your "eye-time". If you do imagine that, you must be a very paranoid individual. Why on /Earth/ would I do that? I've never even met you. Chill out, man. Go and have a cup of tea and stop taking everything so seriously.


>I take it you feel built-in associative arrays represent the totality of associative containers we'll ever consider for D.

No you don't. You just said that to be sarcastic. R-e-l-a-x.

When I said:

>what on Earth is wrong with
>
> #    if (a in map)
> #    {
> #        //...
> #    }

perhaps I should have said, what on Earth is wrong with

#    if (myContainer.contains(a))
#    {
#        //...
#    }

but it's the same difference. Now come on, be nice to me...

Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cd37j6$1j7b$1@digitaldaemon.com...
> In article <cd359e$1f32$1@digitaldaemon.com>, Matthew says...
>
> >Is this a genuine, considered response, or are you just seeking to waste my eye-time?
>
> Is this a genuine, considered question, or are you just in a bad mood for some reason?

Not in a bad mood. Short on time. Short on patience.

Your response smacked of being half-considered, and more rejoinder for rejoinder's sake. It still seems like that now.

> I assume you don't SERIOUSLY imagine that I would deliberately seek to waste your "eye-time". If you do imagine that, you must be a very paranoid
individual.
> Why on /Earth/ would I do that? I've never even met you. Chill out, man. Go and have a cup of tea and stop taking everything so seriously.

Well, it was a sarcastic way of saying "what an ill-considered response". I guess I was being gutless in doing the former, rather than saying the latter. I've girded my loins, and told you what I think. No longer gutless smartass. Now patronising prig. Which do you prefer?

> >I take it you feel built-in associative arrays represent the totality of associative containers we'll ever consider for D.
>
> No you don't. You just said that to be sarcastic. R-e-l-a-x.
>
> When I said:
>
> >what on Earth is wrong with
> >
> > #    if (a in map)
> > #    {
> > #        //...
> > #    }
>
> perhaps I should have said, what on Earth is wrong with

Perhaps

> #    if (myContainer.contains(a))
> #    {
> #        //...
> #    }
>
> but it's the same difference. Now come on, be nice to me...

This is nice. :)

But you've still jumped straight in without considering my point.

The in / contains returns a boolean. That's nice, and a useful feature. But I was talking about a syntactic convention for differentiating between two different value-returning types. In one case, we want an exception to be thrown, so we can write client code to not have to care about missing elements. In the other, we want a get-existing-or-return-null semantic.

I do like opIn, and I do like the contains method. But I want comment on the naming for two value-returning types.

I suggested getXyz and opIndex for the get-existing-or-throw-exception type, and findXyz (could be testXyz instead) for the get-existing-or-return-null type.

This is what I'm interested in everyone's thoughts about.

The reason I case is that such a thing can only be a convention, not a "law", and
I want to avoid the crappy naming mess that is the C++ standard library: "empty()
=> is_empty?", "clear() => make_empty()" !!

Hence, concensus is important.

Thoughts everyone?

Ivan Senji wrote:

<snip>
> opIn would be really great (although it is now a part of an expression and
> not an operator)

What do you mean by this?

> And having "in" work for arrays would be cool (just like it works for
> associative arrays), it happens sometimes that you need to check
> if something is in the array and i find my self rewriting something that the
> compiler could do instead of me.
> 
> bool found=false;
> foreach(T t; array)
> {
>     if(myElem==t)}{found =true;break;}
> }
> if(found)...
> 
> It would rally nice if i could just write:
> if(myElem in array)
> instead of the above.
<snip>

You've just contradicted yourself.  In AAs, it works by checking if a _key_ is in the array.  You've given a code snippet that checks if a _value_ is in the array.

You are referred back to

http://www.digitalmars.com/drn-bin/wwwnews?D/24177
http://www.digitalmars.com/drn-bin/wwwnews?D/24217

And anyway, that has nothing to do with the OP's question.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:cd3930$1lhc$1@digitaldaemon.com...
> Ivan Senji wrote:
>
> <snip>
> > opIn would be really great (although it is now a part of an expression
and
> > not an operator)
>
> What do you mean by this?

I meant to say that having opIn would be great, but "in" is not an operator.

RelExpression -> RelExpression in ShiftExpression

It would be nice if it was an operator.


> > And having "in" work for arrays would be cool (just like it works for
> > associative arrays), it happens sometimes that you need to check
> > if something is in the array and i find my self rewriting something that
the
> > compiler could do instead of me.
> >
> > bool found=false;
> > foreach(T t; array)
> > {
> >     if(myElem==t)}{found =true;break;}
> > }
> > if(found)...
> >
> > It would rally nice if i could just write:
> > if(myElem in array)
> > instead of the above.
> <snip>
>
> You've just contradicted yourself.  In AAs, it works by checking if a

I don't think i have. You use associative arrays to store the keys, so it
makes sence to check if a value of the key is in it or not.
int[char[]] AA1; //this stores char[]'s

And you use normal arrays to store that type:
float[] normalArray; //i store a float here

I might wan't to know if a certain float is in the array.

> _key_ is in the array.  You've given a code snippet that checks if a _value_ is in the array.
>
> You are referred back to
>
> http://www.digitalmars.com/drn-bin/wwwnews?D/24177 http://www.digitalmars.com/drn-bin/wwwnews?D/24217

Yes i remember those posts.

>char []  x = "a string";
>if ( "string" in x ) puts("matched");

I agree that this makes no sence, but i don't agree that if it was defined for normal arrays that it would have to check for the index bounds.

Mathew posted then:
>char []  x = "a string";
> if ( ' ' in x )
>   {
>       puts("matched");
>   }

And this is what i would like.

Associative arrays are for storing the key type, and normal arrays are for storing the type of array.

>
> And anyway, that has nothing to do with the OP's question.

Whose question? :)

>
> Stewart.
>
> --
> My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.