On Tue, Jul 28, 2009 at 06:19:53PM -0400, Steven Schveighoffer wrote:
>   else
>     b.yyy;
> }
> 
> Assuming you have no idea what type Box is, what of the following options looks most natural for xxx in order to test to see if b has an element in it?
> 
> a) if(b.empty)
> b) if(b.empty())

Both of those look equally fine. My top preference would probably be:

e) if(b.isEmpty)

though.

> c) b.clear;

This one. You are just ordering it to be cleared out.

> Which of the following functions looks incorrect?

> void c(Box box)
> {
>     if(box.clear)
>        box.fill(5);
>     else
>        box.empty;
> }

This looks weirdest, since I'm assuming clear clears it out.


>     if(box.clear())
>        box.fill(5);
>     else
>        box.empty();
> }

Not in love with that either, but it isn't as bad.

> Now knowing what the actual meaning of clear and empty are, indicate which version(s) of the function in the previous question would surprise you if it compiled.

None of them. Maybe it is just because I've been using D as my main language for long enough already that I don't see the difference between

x;

and x();

(After all, "x;" is just stupid to write if it is a variable or property, since it doesn't do anything, so logically, it must be a function.)

> Do you think the meaning of a symbol with parentheses suggests something different than that same symbol without parentheses for the following symbols:

None.


-- 
Adam D. Ruppe
http://arsdnet.net

Steven Schveighoffer:

> Assuming you have no idea what type Box is, what of the following options
> looks most natural for xxx in order to test to see if b has an element in
> it?
> a) if(b.empty)
> b) if(b.empty())
> c) if(b.clear)
> d) if(b.clear())

Probably the most explicit in an OOP language is:
if (b.isEmpty()) {...}
Another solution for D code (that I have used in my Set data structure. But it contains a negation):
if (!b.length) {...}
If the standard opBool() gets added then I can may just (as done in Python to test empty collections):
if (b) {...}


> What would you guess looks most natural for yyy in order to remove all
> elements from b?
> a) b.empty;
> b) b.empty();
> c) b.clear;
> d) b.clear();

b.clear();


> Which of the following functions looks incorrect?

This looks like a redundant redundant question. I like none of them, because I have just said that empty() doesn't look clear enough to me.
Among those four b c and d look worse.


> Now knowing what the actual meaning of clear and empty are, indicate which version(s) of the function in the previous question would surprise you if it compiled.

It's a ugly API, so I may refuse to use that Box.
Generally I want both of them to end with a ().


> Do you think the meaning of a symbol with parentheses suggests something
> different than that same symbol without parentheses for the following
> symbols:
> a) select
> b) rock
> c) keyboard
> d) elevate

The first and last look like verbs, so I'm used to see a () after them.


> Thank you for taking the poll.  I tried to be as objective as possible, if you don't think I was, please indicate why:

The test is objective but I don't like it much, because the shown example doesn't have a good enough API.

Bye,
bearophile

Just ask directly:
a) Would you like for their to be a distinction between .foo, an
access, and .foo(), an action?
Or b) would you prefer .foo and .foo() to be interchangeable?

And I will answer I would like for there to be a distinction.

--bb

Steven Schveighoffer Wrote:

> Please respond to this poll before reading other responses.
> 
> Read the following function:
> 
> void foo(Box b)
> {
>    if(b.xxx)
>      b.fill(5);
>    else
>      b.yyy;
> }
> 
> Assuming you have no idea what type Box is, what of the following options looks most natural for xxx in order to test to see if b has an element in it?
> 
> a) if(b.empty)
> b) if(b.empty())
> c) if(b.clear)
> d) if(b.clear())
> 
> Answer:
> =============

A

> =============
> 
> What would you guess looks most natural for yyy in order to remove all elements from b?
> 
> a) b.empty;
> b) b.empty();
> c) b.clear;
> d) b.clear();
> 
> Answer:
> =============

D

> =============
> 
> Which of the following functions looks incorrect?
> 
> void a(Box box)
> {
>     if(box.empty())
>       box.fill(5);
>     else
>       box.clear();
> }
> 
> void b(Box box)
> {
>     if(box.empty)
>       box.fill(5);
>     else
>       box.clear;
> }
> 
> void c(Box box)
> {
>      if(box.clear)
>         box.fill(5);
>      else
>         box.empty;
> }
> 
> void d(Box box)
> {
>      if(box.clear())
>         box.fill(5);
>      else
>         box.empty();
> }
> 
> 
> Answer:
> ==============

The last 2.

> ==============
> 
> You read the documentation for Box, and it looks like this:
> 
> /**
>   * check to see if a box is clear
>   */
>   bool clear();
> 
> /**
>   * empty a box, returning true if the box had contents before emptying
>   */
>   bool empty();
> 
> Now knowing what the actual meaning of clear and empty are, indicate which version(s) of the function in the previous question would surprise you if it compiled.
> 
> Here are the functions again for reference:
> 
> void a(Box box)
> {
>     if(box.empty())
>       box.fill(5);
>     else
>       box.clear();
> }
> 
> void b(Box box)
> {
>     if(box.empty)
>       box.fill(5);
>     else
>       box.clear;
> }
> 
> void c(Box box)
> {
>      if(box.clear)
>         box.fill(5);
>      else
>         box.empty;
> }
> 
> void d(Box box)
> {
>      if(box.clear())
>         box.fill(5);
>      else
>         box.empty();
> }
> 
> Answer:
> ==============

Looks like they all should compile, but I'm assuming we are using D.

> ==============
> 
> Do you think the meaning of a symbol with parentheses suggests something different than that same symbol without parentheses for the following symbols:
> 
> a) select

I would assume select has parameters. If it doesn't, it means nothing to me with or without parenthesis

> b) rock

Hard place, oh, wrong game. Means nothing without context

> c) keyboard

Nope.

> d) elevate

Nope

> ==============
> 
> Thank you for taking the poll.  I tried to be as objective as possible, if you don't think I was, please indicate why:

On Tue, Jul 28, 2009 at 4:16 PM, bearophile<bearophileHUGS@lycos.com> wrote:

> Another solution for D code (that I have used in my Set data structure. But it contains a negation):
> if (!b.length) {...}

The rationale for .empty is that .length could be an O(n) operation
for some containers, but .empty should always be O(1).  So, the
negation of  .length is not a general replacement for .empty.

--bb

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.uxstnfvpeav7ka@localhost.localdomain...
> Please respond to this poll before reading other responses.
>

Ok :)

> Assuming you have no idea what type Box is, what of the following options looks most natural for xxx in order to test to see if b has an element in it?
>
> a) if(b.empty)
> b) if(b.empty())
> c) if(b.clear)
> d) if(b.clear())

a) if(b.empty)

> What would you guess looks most natural for yyy in order to remove all elements from b?
>
> a) b.empty;
> b) b.empty();
> c) b.clear;
> d) b.clear();

d) b.clear();

> Which of the following functions looks incorrect?

All of the above, but "a" looks best.

> Now knowing what the actual meaning of clear and empty are, indicate which version(s) of the function in the previous question would surprise you if it compiled.

"b" and "c", because "clear" and "empty" are both defined as functions that return bool. But regardless, I'd consider it a poorly designed API for a number of different reasons.

> Do you think the meaning of a symbol with parentheses suggests something different than that same symbol without parentheses for the following symbols:
>
> a) select
> b) rock
> c) keyboard
> d) elevate

Absolutely.

Steven Schveighoffer wrote:
> ...

The number of people taking this seriously worries me.

Bill Baxter:
> The rationale for .empty is that .length could be an O(n) operation
> for some containers, but .empty should always be O(1).  So, the
> negation of  .length is not a general replacement for .empty.

I didn't know isEmpty() or opBool() must be O(1).
But I remember Andrei (and maybe other people too) strongly refuse my len() function that sometimes returns length (in O(1)) and sometimes iterates all items of a lazy iterable and returns their number in O(n) or more. So you may be wrong.

Bye,
bearophile

bearophile wrote:
> Bill Baxter:
>> The rationale for .empty is that .length could be an O(n) operation
>>  for some containers, but .empty should always be O(1).  So, the negation of  .length is not a general replacement for .empty.
> 
> I didn't know isEmpty() or opBool() must be O(1). But I remember
> Andrei (and maybe other people too) strongly refuse my len() function
> that sometimes returns length (in O(1)) and sometimes iterates all
> items of a lazy iterable and returns their number in O(n) or more. So
> you may be wrong.

The way Phobos does things is the following:

a) You must define .empty which completes in O(1).

b) If you can define .length with O(1), define it, otherwise don't.

Then Phobos defines walkLength() on a best-effort basis which is guaranteed to finish in O(n) but may finish faster. It uses .length if defined, or else it just iterates the range to exhaustion.

I think this is cleaner than what STL does.


Andrei

Bill Baxter wrote:
> On Tue, Jul 28, 2009 at 4:16 PM, bearophile<bearophileHUGS@lycos.com> wrote:
> 
>> Another solution for D code (that I have used in my Set data structure. But it contains a negation):
>> if (!b.length) {...}
> 
> The rationale for .empty is that .length could be an O(n) operation
> for some containers, but .empty should always be O(1).  So, the
> negation of  .length is not a general replacement for .empty.

Exactly.

Andrei