View mode: basic / threaded / horizontal-split · Log in · Help
January 18, 2012
Re: byKey and byValue: properties or methods?
On 18-01-2012 21:26, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:jf6e7a$1929$1@digitalmars.com...
>>
>> method:
>> no parameters - parentheses are optional
>
> FWIW, I always do a double-take when I see code like:
>
> functionName;
> //or
> object.functionName;
>
> It sets off all mannar of "no-effect expression!" bells and buzzers in my
> head every time I look at it, which I then have to silence.
>
>
>

Indeed! It's so unnatural in a C-based language. See, if the semicolon 
wasn't there, it would be a different story (see most ML-style 
functional languages).

-- 
- Alex
January 18, 2012
Re: byKey and byValue: properties or methods?
Alex Rønne Petersen wrote:
> if the semicolon wasn't there
... it would look like a parameterless command in a shell:
   pwd, ls, du, df, date, uptime, ...

-manfred
January 19, 2012
Re: byKey and byValue: properties or methods?
On 18/01/12 12:52 AM, Timon Gehr wrote:
> On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
>> On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
>>> Nick Sabalausky:
>>>> Without properties, member function access *ANY* many value
>>>> accesses are "a.b()". Is this member value a plain-old-var or a
>>>> function?
>>>> Who knows! It's a leeked out implementation detail, hooray!
>>>
>>> I have a partially related question.
>>>
>>> Currently this code compiles even with -property:
>>>
>>> void main() {
>>> int[int] aa = [1:2];
>>> auto byval = aa.byValue();
>>> }
>>>
>>> But I think byValue is a property, so isn't it right to give a
>>> compilation
>>> error if you add () after the name of a property?
>>
>> Definitely a bug. Strict enforcement requires that parens be used on all
>> function calls and that no properties use parens. If you use parens on
>> them,
>> that would mean that you're using them on the return value of the
>> property
>> (e.g. opCall) - and in fact, that's one of the main reasons that
>> @property was
>> added in the first place, since without enforcement, property
>> functions which
>> return a delegate result in an ambiguity.
>>
>> - Jonathan M Davis
>
> A related and way more embarrassing problem is that lazy function
> parameters have the same issue.
>
> This program prints nothing:
> import std.stdio;
> void foo(lazy void delegate() dg){
> dg();
> }
> void main(){
> foo({writeln("hello");});
> }

Perhaps I'm wrong, but this issue is different.

The code you have written is something that would be written by someone 
that doesn't understand how lazy works. You have to use () to un-lazy 
it, and then () again to invoke the delegate. There is no ambiguity like 
there is with property delegates.
January 19, 2012
Re: byKey and byValue: properties or methods?
On 19-01-2012 01:41, Peter Alexander wrote:
> On 18/01/12 12:52 AM, Timon Gehr wrote:
>> On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
>>> On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
>>>> Nick Sabalausky:
>>>>> Without properties, member function access *ANY* many value
>>>>> accesses are "a.b()". Is this member value a plain-old-var or a
>>>>> function?
>>>>> Who knows! It's a leeked out implementation detail, hooray!
>>>>
>>>> I have a partially related question.
>>>>
>>>> Currently this code compiles even with -property:
>>>>
>>>> void main() {
>>>> int[int] aa = [1:2];
>>>> auto byval = aa.byValue();
>>>> }
>>>>
>>>> But I think byValue is a property, so isn't it right to give a
>>>> compilation
>>>> error if you add () after the name of a property?
>>>
>>> Definitely a bug. Strict enforcement requires that parens be used on all
>>> function calls and that no properties use parens. If you use parens on
>>> them,
>>> that would mean that you're using them on the return value of the
>>> property
>>> (e.g. opCall) - and in fact, that's one of the main reasons that
>>> @property was
>>> added in the first place, since without enforcement, property
>>> functions which
>>> return a delegate result in an ambiguity.
>>>
>>> - Jonathan M Davis
>>
>> A related and way more embarrassing problem is that lazy function
>> parameters have the same issue.
>>
>> This program prints nothing:
>> import std.stdio;
>> void foo(lazy void delegate() dg){
>> dg();
>> }
>> void main(){
>> foo({writeln("hello");});
>> }
>
> Perhaps I'm wrong, but this issue is different.
>
> The code you have written is something that would be written by someone
> that doesn't understand how lazy works. You have to use () to un-lazy
> it, and then () again to invoke the delegate. There is no ambiguity like
> there is with property delegates.

But couldn't that be considered leaking an implementation detail of lazy 
values? Or is this intentional design?

-- 
- Alex
January 19, 2012
Re: byKey and byValue: properties or methods?
On 01/19/2012 01:41 AM, Peter Alexander wrote:
> On 18/01/12 12:52 AM, Timon Gehr wrote:
>> On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
>>> On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
>>>> Nick Sabalausky:
>>>>> Without properties, member function access *ANY* many value
>>>>> accesses are "a.b()". Is this member value a plain-old-var or a
>>>>> function?
>>>>> Who knows! It's a leeked out implementation detail, hooray!
>>>>
>>>> I have a partially related question.
>>>>
>>>> Currently this code compiles even with -property:
>>>>
>>>> void main() {
>>>> int[int] aa = [1:2];
>>>> auto byval = aa.byValue();
>>>> }
>>>>
>>>> But I think byValue is a property, so isn't it right to give a
>>>> compilation
>>>> error if you add () after the name of a property?
>>>
>>> Definitely a bug. Strict enforcement requires that parens be used on all
>>> function calls and that no properties use parens. If you use parens on
>>> them,
>>> that would mean that you're using them on the return value of the
>>> property
>>> (e.g. opCall) - and in fact, that's one of the main reasons that
>>> @property was
>>> added in the first place, since without enforcement, property
>>> functions which
>>> return a delegate result in an ambiguity.
>>>
>>> - Jonathan M Davis
>>
>> A related and way more embarrassing problem is that lazy function
>> parameters have the same issue.
>>
>> This program prints nothing:
>> import std.stdio;
>> void foo(lazy void delegate() dg){
>> dg();
>> }
>> void main(){
>> foo({writeln("hello");});
>> }
>
> Perhaps I'm wrong, but this issue is different.
>
> The code you have written is something that would be written by someone
> that doesn't understand how lazy works.

It is written by someone who understands how it should work.

> You have to use () to un-lazy

What would 'un-lazying' be and what is supposed to be its effect?

> it, and then () again to invoke the delegate. There is no ambiguity like
> there is with property delegates.

The code has exactly the same semantics whether or not you write the 
parens after a lazy variable except for the case when it is a delegate 
or function pointer.
January 19, 2012
Re: byKey and byValue: properties or methods?
On 01/19/2012 01:38 AM, Alex Rønne Petersen wrote:
> On 19-01-2012 01:41, Peter Alexander wrote:
>> On 18/01/12 12:52 AM, Timon Gehr wrote:
>>> On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
>>>> On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
>>>>> Nick Sabalausky:
>>>>>> Without properties, member function access *ANY* many value
>>>>>> accesses are "a.b()". Is this member value a plain-old-var or a
>>>>>> function?
>>>>>> Who knows! It's a leeked out implementation detail, hooray!
>>>>>
>>>>> I have a partially related question.
>>>>>
>>>>> Currently this code compiles even with -property:
>>>>>
>>>>> void main() {
>>>>> int[int] aa = [1:2];
>>>>> auto byval = aa.byValue();
>>>>> }
>>>>>
>>>>> But I think byValue is a property, so isn't it right to give a
>>>>> compilation
>>>>> error if you add () after the name of a property?
>>>>
>>>> Definitely a bug. Strict enforcement requires that parens be used on
>>>> all
>>>> function calls and that no properties use parens. If you use parens on
>>>> them,
>>>> that would mean that you're using them on the return value of the
>>>> property
>>>> (e.g. opCall) - and in fact, that's one of the main reasons that
>>>> @property was
>>>> added in the first place, since without enforcement, property
>>>> functions which
>>>> return a delegate result in an ambiguity.
>>>>
>>>> - Jonathan M Davis
>>>
>>> A related and way more embarrassing problem is that lazy function
>>> parameters have the same issue.
>>>
>>> This program prints nothing:
>>> import std.stdio;
>>> void foo(lazy void delegate() dg){
>>> dg();
>>> }
>>> void main(){
>>> foo({writeln("hello");});
>>> }
>>
>> Perhaps I'm wrong, but this issue is different.
>>
>> The code you have written is something that would be written by someone
>> that doesn't understand how lazy works. You have to use () to un-lazy
>> it, and then () again to invoke the delegate. There is no ambiguity like
>> there is with property delegates.
>
> But couldn't that be considered leaking an implementation detail of lazy
> values? Or is this intentional design?
>

I suppose it is an implementation relic.
January 19, 2012
Re: byKey and byValue: properties or methods?
On Thursday, January 19, 2012 01:38:23 Alex Rønne Petersen wrote:
> But couldn't that be considered leaking an implementation detail of lazy
> values? Or is this intentional design?

The language requires that lazy parameters be accessed with (). That leaks the 
fact that the variable is lazy into the function body, but whether it leaks 
how lazy parameters are implemented is debatable. The same syntax could be 
used with a different implementation underneath the hood.

But the fact that you have to use double parens on a lazy delegate isn't 
leaking any kind of implemenatation detail. It's the natural extension of the 
syntax for lazy. var() gives you the value of the lazy parameter var, and so 
if you want to call var (or use opCall or it), then you need another set of 
parens - var()().

Whether requiring parens on lazy parameters is a good design decision is 
debatable, but I don't see any leaking of implementation details in it. The 
syntax chosen was probably chosen because it's implemented with a delegate, 
but the fact that it's implemented with a delegate is still an implementation 
detail which could theoretically be changed.

- Jonathan M Davis
January 19, 2012
Re: byKey and byValue: properties or methods?
On 01/19/2012 01:52 AM, Jonathan M Davis wrote:
> On Thursday, January 19, 2012 01:38:23 Alex Rønne Petersen wrote:
>> But couldn't that be considered leaking an implementation detail of lazy
>> values? Or is this intentional design?
>
> The language requires that lazy parameters be accessed with (). That leaks the
> fact that the variable is lazy into the function body, but whether it leaks
> how lazy parameters are implemented is debatable. The same syntax could be
> used with a different implementation underneath the hood.
>
> But the fact that you have to use double parens on a lazy delegate isn't
> leaking any kind of implemenatation detail. It's the natural extension of the
> syntax for lazy. var() gives you the value of the lazy parameter var, and so
> if you want to call var (or use opCall or it), then you need another set of
> parens - var()().
>
> Whether requiring parens on lazy parameters is a good design decision is
> debatable,

They are only required if you want to call a lazy delegate/function 
pointer. They are optional in all other cases.

> but I don't see any leaking of implementation details in it. The
> syntax chosen was probably chosen because it's implemented with a delegate,
> but the fact that it's implemented with a delegate is still an implementation
> detail which could theoretically be changed.
>
January 19, 2012
Re: byKey and byValue: properties or methods?
On Thursday, January 19, 2012 03:18:22 Timon Gehr wrote:
> They are only required if you want to call a lazy delegate/function
> pointer. They are optional in all other cases.

I could have sworn that they were required. If not, then yeah, that seems 
pretty bad. It's certainly not the end of the world, but it's inconsistent in 
away that has caused problem for some people (Andrej was posting about it just 
the other day). So, it's poor design in that respect.

- Jonathan M Davis
January 19, 2012
Re: byKey and byValue: properties or methods?
On 2012-01-18 21:26, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:jf6e7a$1929$1@digitalmars.com...
>>
>> method:
>> no parameters - parentheses are optional
>
> FWIW, I always do a double-take when I see code like:
>
> functionName;
> //or
> object.functionName;
>
> It sets off all mannar of "no-effect expression!" bells and buzzers in my
> head every time I look at it, which I then have to silence.

It's even more fun in Ruby which doesn't require semicolons :) Just:

functionName

-- 
/Jacob Carlborg
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home