July 28, 2009
On Tue, Jul 28, 2009 at 10:20 AM, Steven Schveighoffer<schveiguy@yahoo.com> wrote:
> On Tue, 28 Jul 2009 12:30:00 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> Steven Schveighoffer wrote:

> What if the compiler allowed you to call functions as long as what you
> typed was an unambiguous prefix of the function name
> why don't we have a
> wonderful time-saving feature like this?  Because it would be a nightmare to
> read.
...
>> So now C# has two ways of providing a readonly field. Doesn't quite look like an example to follow.
>
> Just like D!
>
> Yes, that's right.  readonly is analogous to const.
...
>> That's what I'm saying: if it could do anything, at least don't pretend it's anything special. It's a function!
> ...
>  So would you argue that C# or D with operator overloading isn't
> better because operators are just functions, why call them something else?


Bravo!  Fine, rational arguments, Steve.


>>>> Well maybe you could change TimeSpan.
>>>
>>>  Lovely.  Force the developer to rename his functions because D is too weak to allow defining a correct interface.
>>
>> Or maybe because her use of name was too ambiguous.
>
> I want to use the parentheses or lack thereof as part of the human meaning for the function/property.  Making them optional means I can't do that.

I think Andrei's right here.
.seconds() really was too ambiguous a name to begin with.   Even if we
had properties I would be inclined to think that was just something
you forgot to mark as a property because a property-like meaning is
all that makes sense to me.   The meaning of .fromSeconds() is much
more obvious.

The example of adjectives or nouns that are also verbs is much better
--- .empty  vs .empty().    Others that come to mind:  clean, dirty,
end, begin.  (begin isn't really a noun but it's been used that way for so long in STL that C++ people think of it as a synonym for "beginning".)


--bb
July 28, 2009
On Tue, 28 Jul 2009 13:51:11 -0400, Bill Baxter <wbaxter@gmail.com> wrote:

> On Tue, Jul 28, 2009 at 10:20 AM, Steven
> Schveighoffer<schveiguy@yahoo.com> wrote:
>> I want to use the parentheses or lack thereof as part of the human meaning
>> for the function/property.  Making them optional means I can't do that.
>
> I think Andrei's right here.
> .seconds() really was too ambiguous a name to begin with.   Even if we
> had properties I would be inclined to think that was just something
> you forgot to mark as a property because a property-like meaning is
> all that makes sense to me.   The meaning of .fromSeconds() is much
> more obvious.

I think in the sense that 'seconds' is not a verb, and therefore, it's not obvious (perhaps to some) that

TimeSpan.seconds(5);

returns a TimeSpan that represents 5 seconds is a valid point.  But what happens in those cases is the user is slightly confused and looks up the docs (probably once).  The argument from Andrei is simply dodging the issue.

ts.seconds = 5;

Means the same thing (even with Andrei's new rule), and not because I poorly named the function, but because I happened to name it the same as a member function.  That you can call a static function via an instance is one bug IMO, and the other is that the function is even considered as a property.

> The example of adjectives or nouns that are also verbs is much better
> --- .empty  vs .empty().    Others that come to mind:  clean, dirty,
> end, begin.  (begin isn't really a noun but it's been used that way
> for so long in STL that C++ people think of it as a synonym for
> "beginning".)

I was using a real-life example, I think that has some power to it.  But you are right, naming the static method differently was probably the right move anyways, and there are better theoretical examples.  There was some pressure to make the usage less verbose...

-Steve
July 28, 2009
Bill Baxter wrote:
> On Tue, Jul 28, 2009 at 10:20 AM, Steven
> Schveighoffer<schveiguy@yahoo.com> wrote:
>> On Tue, 28 Jul 2009 12:30:00 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Steven Schveighoffer wrote:
> 
>> What if the compiler allowed you to call functions as long as what you
>> typed was an unambiguous prefix of the function name
>> why don't we have a
>> wonderful time-saving feature like this?  Because it would be a nightmare to
>> read.
> ...
>>> So now C# has two ways of providing a readonly field. Doesn't quite look
>>> like an example to follow.
>> Just like D!
>>
>> Yes, that's right.  readonly is analogous to const.
> ...
>>> That's what I'm saying: if it could do anything, at least don't pretend
>>> it's anything special. It's a function!
>> ...
>>   So would you argue that C# or D with operator overloading isn't
>> better because operators are just functions, why call them something else?
> 
> 
> Bravo!  Fine, rational arguments, Steve.

I don't think it's a good argument. Operators are functions with a specific syntax, is all. D is not even pretending any different: it simply rewrites the usual syntax into function calls. We should do the same with properties.


Andrei
July 28, 2009
On Tue, 28 Jul 2009 14:19:49 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Bill Baxter wrote:
>> On Tue, Jul 28, 2009 at 10:20 AM, Steven
>> Schveighoffer<schveiguy@yahoo.com> wrote:
>>> On Tue, 28 Jul 2009 12:30:00 -0400, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>>> Steven Schveighoffer wrote:
>>
>>> What if the compiler allowed you to call functions as long as what you
>>> typed was an unambiguous prefix of the function name
>>> why don't we have a
>>> wonderful time-saving feature like this?  Because it would be a nightmare to
>>> read.
>> ...
>>>> So now C# has two ways of providing a readonly field. Doesn't quite look
>>>> like an example to follow.
>>> Just like D!
>>>
>>> Yes, that's right.  readonly is analogous to const.
>> ...
>>>> That's what I'm saying: if it could do anything, at least don't pretend
>>>> it's anything special. It's a function!
>>> ...
>>>   So would you argue that C# or D with operator overloading isn't
>>> better because operators are just functions, why call them something else?
>>   Bravo!  Fine, rational arguments, Steve.
>
> I don't think it's a good argument. Operators are functions with a specific syntax, is all. D is not even pretending any different: it simply rewrites the usual syntax into function calls. We should do the same with properties.

I was using this as an example of how your arguments against property definitions sound to me.

Operators are not the same as properties -- the definition syntax is the same word, every time.  So once you learn that the non-english term opAdd defines what happens when you type +, you can repeatedly use that knowledge.

For example, I know that for the following code:

x + y;

I know this means "add x to y," and it might call opAdd or it might be a builtin operation, I don't care, but I know it means to add.  It might even execute arbitrary code that does something completely different, but it's not my fault because the author didn't follow the standard convention.

I don't have to look it up, or know what the author of object x meant, the meaning is not subject to debate or English ambiguity.

However, when I see:

x.empty;

I can't tell what is implied here.  empty could be a field or property, in which case the user made a logic error, or it could be a function that empties x, or it could be some code that does something completely different.  I assume the author is going to name his functions after what they do, similarly to how opAdd should be used for addition.  English is not precise, and can have multiple meanings for the same exact word.  Context is important.

But it gets worse.  Now I see this:

y.empty;

Oh, I learned what empty meant before, right?  WRONG!  y could be written by a completely different author, and could have the opposite meaning.  The problem is, you can't come up with a non-prejudiced definition of what empty should always mean, because the English term itself is ambiguous.  All you can do is use conventions that can be defined, such as () performs an action, but lack of () denotes a field, or come up with java-like conventions (e.g. doXxx means it's a function).  So if I can couple the term empty with the context of lack of parentheses meaning field, I can deduce the meaning of empty *without looking it up*.  The advantage is not having to look up what code means because the author did a good job of naming the function/property.  This is currently impossible with D.

Coming up with bizarre rules  that require pairs of functions doesn't make things any easier.  I still have to look up the usage of empty every time I encounter a new usage of it, because it could mean one of two things.

-Steve
July 28, 2009
Andrei Alexandrescu wrote:
> Steven Schveighoffer wrote:
>> The presence or absence of parens is a hard-coded accepted meaning of field vs. function.
> 
> I understand how some people want to derive meaning from obj.foo() versus obj.foo. I think they shouldn't in D. I mean D has had for years the behavior that you could drop the trailing empty parentheses.
> 
<sarcasm>
	And of course, D has such a huge number of users already that
anyone who comes from another language can just go to hell as far as
we're concerned...
</sarcasm>

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr



July 28, 2009
On Tue, Jul 28, 2009 at 11:19 AM, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
> Bill Baxter wrote:
>>
>> On Tue, Jul 28, 2009 at 10:20 AM, Steven Schveighoffer<schveiguy@yahoo.com> wrote:
>>>
>>> On Tue, 28 Jul 2009 12:30:00 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>>> Steven Schveighoffer wrote:
>>
>>> What if the compiler allowed you to call functions as long as what you
>>> typed was an unambiguous prefix of the function name
>>> why don't we have a
>>> wonderful time-saving feature like this?  Because it would be a nightmare
>>> to
>>> read.
>>
>> ...
>>>>
>>>> So now C# has two ways of providing a readonly field. Doesn't quite look like an example to follow.
>>>
>>> Just like D!
>>>
>>> Yes, that's right.  readonly is analogous to const.
>>
>> ...
>>>>
>>>> That's what I'm saying: if it could do anything, at least don't pretend it's anything special. It's a function!
>>>
>>> ...
>>>  So would you argue that C# or D with operator overloading isn't
>>> better because operators are just functions, why call them something
>>> else?
>>
>>
>> Bravo!  Fine, rational arguments, Steve.
>
> I don't think it's a good argument. Operators are functions with a specific syntax, is all. D is not even pretending any different: it simply rewrites the usual syntax into function calls. We should do the same with properties.

I think I basically agree with you on that except:

1) The function call syntax should be disabled on properties to avoid ambiguities like returned delegates or things with opCall.

2) the function name that properties are rewritten into should be hidden from the programmer.

With opAdd etc, the function you are trying to write corresponds to a
symbol, so you can't have it be your identifier.  So goofy names like
opAdd are necessary and unavoidable.
With properties, the thing in question has a name, so it is more
pleasing to actually use it.
But certainly, property accesses will still be rewritten as functions.
 It could even be opGet_foo internally.  But who wants to look at a
dozen functions with names like opGet_ opSet_?  Yes, my main argument
against opGet_ is that it is butt-ugly.  The problem is that most
every class has multiple properties.  So every class will have to
sprout this ugliness.  But sprouting a few property {...} blocks or
even "property:" sections is not so bad.

In fact I seen no reason why you couldn't just make the rule be that we rewrite the properties both at point of use *and* at point of declaration.

   property int foo()  { return x_; }

would be rewritten

   int opGet_foo()  { return x_; }

And I suppose I don't see any reason to stop anyone from writing the latter if they somehow find it more aesthetically pleasing.  Or find it more useful for code generation or something.

--bb
July 28, 2009
Jérôme M. Berger wrote:
> Andrei Alexandrescu wrote:
>> Steven Schveighoffer wrote:
>>> The presence or absence of parens is a hard-coded accepted meaning of field vs. function.
>>
>> I understand how some people want to derive meaning from obj.foo() versus obj.foo. I think they shouldn't in D. I mean D has had for years the behavior that you could drop the trailing empty parentheses.
>>
> <sarcasm>
>     And of course, D has such a huge number of users already that anyone who comes from another language can just go to hell as far as we're concerned...
> </sarcasm>

But then they'd expect a number of improvements wouldn't they. To me, the space-wasting and uncomfortable-to-type parens have always been unpleasant noise. I like some of the values of the old village I grew up in, but please pave the darn road, I could do without the mud.

Andrei
July 28, 2009
Steven Schveighoffer wrote:
> However, when I see:
> 
> x.empty;
> 
> I can't tell what is implied here.

You can. In either C# or D language it could execute arbitrary code that you better know what it's supposed to do. D simply doesn't make it "bad style" as C# stupidly does.


Andrei
July 28, 2009
On Tue, 28 Jul 2009 16:08:58 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Steven Schveighoffer wrote:
>> However, when I see:
>>  x.empty;
>>  I can't tell what is implied here.
>
> You can. In either C# or D language it could execute arbitrary code that you better know what it's supposed to do. D simply doesn't make it "bad style" as C# stupidly does.

still not getting it, are you...

Just forget it, I think this is a lost cause, I keep making the same points over and over again, and you keep not reading them.

-Steve
July 28, 2009
Steven Schveighoffer wrote:
> On Tue, 28 Jul 2009 16:08:58 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Steven Schveighoffer wrote:
>>> However, when I see:
>>>  x.empty;
>>>  I can't tell what is implied here.
>>
>> You can. In either C# or D language it could execute arbitrary code that you better know what it's supposed to do. D simply doesn't make it "bad style" as C# stupidly does.
> 
> still not getting it, are you...
> 
> Just forget it, I think this is a lost cause, I keep making the same points over and over again, and you keep not reading them.

I do read them and understand them. I mean, it's not rocket surgery. At the end of the day you say "x = a.b;" looks more like sheer access because that's what happens for fields already. Then you say "a.b()" in any context looks more like an action because it's clear that there's a function call involved. But your arguments are not convincing to me, and in turn I explained why. What would you do if you were me?

Andrei