View mode: basic / threaded / horizontal-split · Log in · Help
July 28, 2009
Re: properties
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
Re: properties
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
Re: properties
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
Re: properties
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
Re: properties
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
Re: properties
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
Re: properties
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
Re: properties
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
Re: properties
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
Re: properties
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
21 22 23 24 25 26 27 28 29
Top | Discussion index | About this forum | D home