View mode: basic / threaded / horizontal-split · Log in · Help
January 29, 2013
Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
Would everyone be able to agree to only use @property functions as 
properties?  This would still allow omittable parens as a way to make 
call-chaining and ufcs nicer.

The limitation this imposes is that
  void foo(int a) {...}
  void bar(int a, int b) {...}
cannot be called in this way:
  foo = 2;
  2.bar = 3;

As a consequence, everyone's favorite
  writeln = "lolwut";
does not compile.

What is still allowed:
  int foo() {...}
  void @property bar(int a) {...}
  ...
  int x = foo;
  bar = x;
  auto r = lets.chain!(q).some.stuff;

Although this seems like a distinction that's been discussed, I could 
never really tell if there was consensus on this.

Admittedly, I stopped following the "@property needed or not needed?" 
discussion halfway through.

As someone who has taken a stab at doing semantic property rewriting, I 
think this is a limitation that could potentially help us in the long 
run.  It simplifies detection of properties: properties are only the 
things explicitly marked as such, and functions with omitted parens can 
follow a simpler codepath that the in-depth semantic rewrites can safely 
ignore.
January 29, 2013
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
why in the hell would you want:

    writeln = "lolwut";

to compile in the first place?
January 29, 2013
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On 01/28/2013 08:09 PM, F i L wrote:
> why in the hell would you want:
>
> writeln = "lolwut";
>
> to compile in the first place?
>

Dunno.

But it does right now ;)
January 29, 2013
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On Tuesday, 29 January 2013 at 00:56:41 UTC, Chad Joan wrote:
> snip
>
> The limitation this imposes is that
>   void foo(int a) {...}
>   void bar(int a, int b) {...}
> cannot be called in this way:
>   foo = 2;
>   2.bar = 3;
>
> snip

I have been following the properties discussion a bit and lack
the experience to really comment on much. However, looking at
your posting I couldn't help but ask one question.

You state that not allowing at statement like:

2.bar = 3;

is a 'limitation'. Was 'limitation' really the word you were
looking for?
I find such code rather baffling. Perhaps it has valuable uses
somewhere, which is why I am asking.

It sort of reminds me of Python where you can do something like:

' '.join( list_of_strings )

which is very cute and all, but the following, rather mundane
function call would do a better job of conveying to the reader
what is going on, using the same number of keystrokes:

join( list_of_strings, ' ')

Craig
January 29, 2013
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On 01/28/2013 08:59 PM, Craig Dillabaugh wrote:
> On Tuesday, 29 January 2013 at 00:56:41 UTC, Chad Joan wrote:
>> snip
>>
>> The limitation this imposes is that
>> void foo(int a) {...}
>> void bar(int a, int b) {...}
>> cannot be called in this way:
>> foo = 2;
>> 2.bar = 3;
>>
>> snip
>
> I have been following the properties discussion a bit and lack
> the experience to really comment on much. However, looking at
> your posting I couldn't help but ask one question.
>
> You state that not allowing at statement like:
>
> 2.bar = 3;
>
> is a 'limitation'. Was 'limitation' really the word you were
> looking for?
> I find such code rather baffling. Perhaps it has valuable uses
> somewhere, which is why I am asking.
>
> It sort of reminds me of Python where you can do something like:
>
> ' '.join( list_of_strings )
>
> which is very cute and all, but the following, rather mundane
> function call would do a better job of conveying to the reader
> what is going on, using the same number of keystrokes:
>
> join( list_of_strings, ' ')
>
> Craig

I mean limitation in the mathematical sense.

It's a combination of syntax elements that are valid in current D, but 
would no longer be valid if the D community were to desire a properties 
solution that includes this condition.

If no one is harmed by this limitation, then it is still a "limitation", 
and also a /useful/ limitation.
January 29, 2013
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On Tuesday, 29 January 2013 at 01:09:17 UTC, F i L wrote:
> why in the hell would you want:
>
>     writeln = "lolwut";
>
> to compile in the first place?

If you disallow this. You will have to invent something else than 
opDispatch.
Something that serves them both. opPropMethodDispatch maybe.
January 29, 2013
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On Tuesday, 29 January 2013 at 02:54:44 UTC, Chad Joan wrote:
> On 01/28/2013 08:59 PM, Craig Dillabaugh wrote:
>> On Tuesday, 29 January 2013 at 00:56:41 UTC, Chad Joan wrote:
>>> snip
>>>
>>> The limitation this imposes is that
>>> void foo(int a) {...}
>>> void bar(int a, int b) {...}
>>> cannot be called in this way:
>>> foo = 2;
>>> 2.bar = 3;
>>>
>>> snip
>>
>> I have been following the properties discussion a bit and lack
>> the experience to really comment on much. However, looking at
>> your posting I couldn't help but ask one question.
>>
>> You state that not allowing at statement like:
>>
>> 2.bar = 3;
>>
>> is a 'limitation'. Was 'limitation' really the word you were
>> looking for?
>> I find such code rather baffling. Perhaps it has valuable uses
>> somewhere, which is why I am asking.
>>
>> It sort of reminds me of Python where you can do something 
>> like:
>>
>> ' '.join( list_of_strings )
>>
>> which is very cute and all, but the following, rather mundane
>> function call would do a better job of conveying to the reader
>> what is going on, using the same number of keystrokes:
>>
>> join( list_of_strings, ' ')
>>
>> Craig
>
> I mean limitation in the mathematical sense.
>
> It's a combination of syntax elements that are valid in current 
> D, but would no longer be valid if the D community were to 
> desire a properties solution that includes this condition.
>
> If no one is harmed by this limitation, then it is still a 
> "limitation", and also a /useful/ limitation.

Thanks. That is what I was hoping was the case. I was just
curious if perhaps such obscure looking code enabled certain
idioms that somehow made the language more powerful.
January 29, 2013
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On Tuesday, 29 January 2013 at 00:56:41 UTC, Chad Joan wrote:
> Would everyone be able to agree to only use @property functions 
> as properties?

I think @property-ies should not be taken for functions... at 
least conceptually.

I think the root reason why such confusion is the bad choice that 
D made in the beginning, to define properties with the same 
syntax as functions, while properties should be rather an 
extensions of the variable concept, not of the functions concept.

For the programmer using a property, he should not even be aware 
that it is a function (or a property). He should think that it is 
a variable and that's all.

The C# syntax is closer to this approach. More, it is strongly 
linking the code (of both the getter and the setter) with the 
considered property. In D, this link is quite loose.

Let me turn the table: why not thinking about the property as a 
variable that, optionally (start another UFCS/opt-parens 
discussion here...) accept the syntax:

v(2);

(besides the obvious v=2). This happens in C++ where you can 
define either int x= 3; either int x(3).

More confusing?
January 29, 2013
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On Tuesday, 29 January 2013 at 01:24:45 UTC, Chad Joan wrote:
> On 01/28/2013 08:09 PM, F i L wrote:
>> why in the hell would you want:
>>
>> writeln = "lolwut";
>
> But it does right now ;)

Joking here, but what about renaming writeln into cout and 
overloading the <<?
January 29, 2013
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
On Tuesday, 29 January 2013 at 08:05:25 UTC, eles wrote:
> On Tuesday, 29 January 2013 at 01:24:45 UTC, Chad Joan wrote:
>> On 01/28/2013 08:09 PM, F i L wrote:
>>> why in the hell would you want:
>>>
>>> writeln = "lolwut";
>>
>> But it does right now ;)
>
> Joking here, but what about renaming writeln into cout and 
> overloading the <<?

Great idea :)

import std.stdio;
struct COut {
    COut opBinary(string op, T)(T other) if(op == "<<") {
            write(other);
            return this;
    }
}

@property COut cout() {
    return COut();
}

void main() {
    cout << "cout" << " " << "rocks" << "\n";
}
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home