On 02/10/2011 04:34 PM, Max Samukha wrote:
On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
On 2/10/11 12:30 AM, Olivier Pisano wrote:
Le 09/02/2011 21:08, Ary Manzana a écrit :
On 2/9/11 3:54 PM, bearophile wrote:
- There is no need to learn to use a function with a weird syntax
like
iota, coming from APL. This makes Phobos and learning D a bit
simpler.
I would recommend stop using "weird" names for functions. Sorry if
this
sounds a little harsh but the only reason I see this function is
called
"iota" is to demonstrate knowledge (or to sound cool). But programmers
using a language don't care about whether the other programmer
demonstrates knowledge behind a function name, they just want to get
things done, fast.
I mean, if I want to create a range of numbers I would search "range".
"iota" will never, ever come to my mind. D has to be more open to
public, not only to people who programmed in APL, Go or are
mathematics
freaks. Guess how a range is called in Ruby? That's right, Range.
Another example: retro. The documentation says "iterates a
bidirectional
name backwards". Hm, where does "retro" appear in that text? If I want
Path: digitalmars.com!not-for-mail
From: Regan Heath <[email protected]>
Newsgroups: digitalmars.D
Subject: Re: Lookup conventions: [Was Re: Get vs Test method naming
convention]
Date: Thu, 15 Jul 2004 12:25:06 +1200
Organization: Netwin LTD
Lines: 145
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
X-Trace: digitaldaemon.com 1089851223 33174 210.54.44.56 (15 Jul 2004
00:27:03 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 15 Jul 2004 00:27:03 +0000 (UTC)
User-Agent: Opera7.23/Win32 M2 build 3227
Xref: digitalmars.com digitalmars.D:6162
On Thu, 15 Jul 2004 09:47:52 +1000, Matthew
<[email protected]> wrote:
"Sean Kelly" <[email protected]> wrote in message
news:[email protected]...
In article <[email protected]>, Matthew says...
>
>Fair point
>
>What about:
>
> - value_type getXyz(key_type key) returns the requested element, or
throw
>InvalidKeyException
> - bool containsXyz(key_type key) returns true/false, indicating
presence
>of element
> - value_type findXyx(key_type key, value_type defaultValue) returns
the
>requested element, or the given default
>
> - opIndex() is a synonym for getXyz where the container has only a
single
>value_type, or its primary value_type is obviously delineated from any
secondary
>value_types.
>
>I'm pretty happy with this picture. Votes?
I don't like the new findXyz semantics. The new function requires that I
either
set aside a potentially valid value to signal lookup failure, do two
lookups
(one for containsXyz and another for findXyz), or wrap getXyz in a
try block.
Another possibility would be to offer two versions of findXyz, one
accepting a
default and one returning a pointer?
Can you provide a quick sample of using a findXyz() that illustrates your
requirement?
Ok, assuming that everyone's on board with testing (by opIn and/or
contains()
and/or containsXyz()) and getting (opIndex and/or get() and/or
getXyz()), then
it's finding that's the trouble.
What are our requirements for finding:
To be able to determine presence (testing) and retrieve the element in
the case of its being present.
To determine presence we must either return a boolean or sentinel
value (e.g.
null). Given the dichotomy between null being a good (but not perfect)
sentinel
for object types, and 0/NaN being a bad sentinel for built-in types,
I'd now
suggest that we don't do that. Hence, presence should be indicated
either by
return value, or by an out parameter.
Retrieval can similarly be return value or out parameter.
Thus, for finding, we have two options
1. Return the value, pass the presence as an out parameter
value_type findXyz(key_type key, out bool bPresent);
2. Return the presence, pass the value as an out parameter
bool findXyz(key_type key, out value_type value);
I like #2, it allows this...
if (findXyz("regan",value)) {
}
#1 would be
value = findXyz("regan",r);
if (r) {
}
I'd suggest here and now that neither of these are going to satisfy all
circumstances. I'd further suggest, however, that we need to decide on
one and
stick to it.
My vote is for #2 above.
btw, considering all this, it now seems to me that the above
definition of
findXyz(), incorporating a default value, is quite wrong. That should
be called
something else, findWithDefault[Xyz](), or something less ugly.
True, having a default value requires being able to pass 'no default',
which is the null/0/NaN problem all over again.
Do we need this at all, consider:
if (!findXyz("regan",value)) value = "default";
..use value here..
Leaving us with the following lookup "conventions":
to iterate it backwards, or to reverse the order, the first thing I
would write is reverse(range) or backwards(range), "retro" would never
come to my mind.
(and no, replies like "you can always alias xxx" are not accepted :-P)
Hi,
I agree iota is a bad name.
Fifth result of simply googling the entire Web for "iota":
http://www.sgi.com/tech/stl/iota.html
Andrei
Google search takes your preferences into account. They must be
tracking your
search history, peeking into your gmail accounts etc. I searched for
'iota' and
couldn't find the STL link on the first 5 pages.
Even then, noone forces D2 to blindly reproduce stupid naming from
APL/C++, I guess. Or what?
