On Wednesday, January 23, 2013 21:33:07 Jacob Carlborg wrote:
> This is how it should look like. Date ranges in Ruby on Rails can be really beautiful:
> 
> date = 2.days.ago
> 
> I think we should have the same in D.

I confess that it's syntax like that that makes dislike UFCS. I can see why you might like it, but personally, I find it to be hideous.

But as long as you're not using -property, you can do 2.days to get a Duration of 2 days, much as I wish that you couldn't.

- Jonathan M Davis

On Wednesday, 23 January 2013 at 20:37:23 UTC, Jacob Carlborg wrote:
> What about functions not marked with @property?
>
> writeln = "asd";
>
> Doesn't look very nice.

struct FileNotFound {
   int payload;  FileNotFound opBinary(string op : "+")(FileNotFound rhs) {
return this.payload * rhs.payload;
                }
                        } /* LOL INDENTATION */

FileNotFound descriptiveVariableNamesArentMyThingLOLOLOLOL;
descriptiveVariableNamesArentMyThingLOLOLOLOL.payload = 20;

auto rofl = descriptiveVariableNamesArentMyThingLOLOLOLOL + FileNotFound(100);


// LOLOLOLOL rofl.payload == 2000!!!!!!!!!!!!!!!!




All of that looks pretty terrible too, from the awful names, the broken indentation, the useless comment, and of course, the + operator being overloaded to mean multiplication too.

But that's no reason to for the compiler to reject operator overloading, comments, or long variable names, because these things are useful, when not abused by a deranged lunatic.



Simlarly, writeln = 10 might not look very nice, but className = "foo" does.... and it is the same feature, used in real world D code now (that would break if we changed it).

On 2013-01-23 21:46, Jonathan M Davis wrote:

> I confess that it's syntax like that that makes dislike UFCS. I can see why
> you might like it, but personally, I find it to be hideous.
>
> But as long as you're not using -property, you can do 2.days to get a Duration
> of 2 days, much as I wish that you couldn't.

The point is that the code should read like regular text. But if you do:

auto t = ago(days(2));

It's backwards but it's still better than:

auto a = Time.now() - 60 * 60 * 24 * 2; // don't know the exact syntax

-- 
/Jacob Carlborg

On Wednesday, January 23, 2013 21:54:54 Jacob Carlborg wrote:
> On 2013-01-23 21:46, Jonathan M Davis wrote:
> > I confess that it's syntax like that that makes dislike UFCS. I can see
> > why
> > you might like it, but personally, I find it to be hideous.
> > 
> > But as long as you're not using -property, you can do 2.days to get a Duration of 2 days, much as I wish that you couldn't.
> 
> The point is that the code should read like regular text.

I know that that's what you're going for, but I don't agree with it at all. It's code, not a novel.

> But if you do:
> 
> auto t = ago(days(2));
> 
> It's backwards

I've programmed enough in functional languages (and in a functional style in non-functional languages) to find 2.days().ago() to be horribly backwards.

> but it's still better than:
> 
> auto a = Time.now() - 60 * 60 * 24 * 2; // don't know the exact syntax

Well, of course that's horrible. It's using naked numbers. The correct syntax would be

auto a = Clock.currTime() - dur!"days"(2);

or if you don't want to use dur

auto a = Clock.currTime() - days(2);

And I see no problem with that.

- Jonathan M Davis

On 01/23/2013 10:08 PM, Jonathan M Davis wrote:
> On Wednesday, January 23, 2013 21:54:54 Jacob Carlborg wrote:
>> On 2013-01-23 21:46, Jonathan M Davis wrote:
>>> I confess that it's syntax like that that makes dislike UFCS. I can see
>>> why
>>> you might like it, but personally, I find it to be hideous.
>>>
>>> But as long as you're not using -property, you can do 2.days to get a
>>> Duration of 2 days, much as I wish that you couldn't.
>>
>> The point is that the code should read like regular text.
>
> I know that that's what you're going for, but I don't agree with it at all.
> It's code, not a novel.
>

What is the point?

>> But if you do:
>>
>> auto t = ago(days(2));
>>
>> It's backwards
>
> I've programmed enough in functional languages (and in a functional style in
> non-functional languages) to find 2.days().ago() to be horribly backwards.
>

IMHO, this is ridiculous. Real Haskell programmers are flexible enough to use both orders.

sun^.position.x

>> but it's still better than:
>>
>> auto a = Time.now() - 60 * 60 * 24 * 2; // don't know the exact syntax
>
> Well, of course that's horrible. It's using naked numbers. The correct syntax
> would be
>
> auto a = Clock.currTime() - dur!"days"(2);
>
> or if you don't want to use dur
>
> auto a = Clock.currTime() - days(2);
>
> And I see no problem with that.
>
> - Jonathan M Davis
>

Likewise, there is no problem with 2.days.ago.

Clock.currTime() - dur!"days"(2) is more verbose without being more clear.

OK. I'm going to try to shift the object of this discussion. Let's forget style for a little (I loves me both the functional notation, but am also a syntax Nazi).

Clearly, not everyone agrees with what constitutes a property, and what doesn't. Because of this, there is a strong urge to make parenthesis *on functions* optional (especially when UFCS gets mixed in).

In this context, what does it mean then to have something be "a property" ?

I think we should remember what "@property" (as I understood it) is meant for: a function that can emulate being a object. The de-facto example being "front".

The "final" objective (as I understood it), is that you can publish your interface, and later, swap object/members for functions (and vice versa).

When you think about it: The (no) parentheses is really just a side effect of being a property, but not the root objective. As for enforcing parenthesis on non-property: Well, that has nothing to do with @property, when you think of it

--------
IMO: We should be able to keep the optional parenthesis for all functions (except maybe those that return delegates). Things that are marked as property, however, MUST respect two things:
1) properties should *NEVER* have parentheses.
2) you should not be able to take the address of a property function.
3) The "a.prop = value" should call "a.prop(value)" IFF prop is declared property.

This (I think), should make everyone happy. Callers can still choose their own styles, especially in the context of UFCS.

As for @property: this makes it able to guarantee what it was originally designed for.

...

Or am I completely wrong? Did I miss anything?

My two cents on properties (comments along the way):

alias int delegate() C;
C c;
auto noprop() {return c;}
void noprop(C v) {c = v;}
@property auto prop() {return c;}
@property void prop(C v) {c = v;}

static assert(
   is(typeof( noprop             ) == function) /* well ... I guess, technically */
&& is(typeof( prop               ) == C) /* ok */

&& is(typeof( {return noprop;}() ) == C) /* fails with -property. that's goofy */
&& is(typeof( {return prop;}()   ) == C) /* ok */

&& is(typeof( {noprop = c;}      )) /* fails with -property. that's alright */
&& is(typeof( {prop = c;}        )) /* ok */

&& is(typeof( &noprop            ) == C function()) /* of course */
&& is(typeof( &prop              ) == C function() @property) /* bad, should be typeof(&c) */

&& is(typeof( noprop()           ) == C) /* of course */
&& is(typeof( prop()             ) == C) /* bad, should be int */

&& is(typeof( noprop()()         ) == int) /* of course */
&& is(typeof( prop()()           ) == int) /* bad, should error */
);

On 01/23/2013 10:59 PM, monarch_dodra wrote:
> ...
> --------
> IMO: We should be able to keep the optional parenthesis for all
> functions (except maybe those that return delegates). Things that are
> marked as property, however, MUST respect two things:
> 1) properties should *NEVER* have parentheses.
> 2) you should not be able to take the address of a property function.
> 3) The "a.prop = value" should call "a.prop(value)" IFF prop is declared
> property.
>
> This (I think), should make everyone happy. Callers can still choose
> their own styles, especially in the context of UFCS.
>
> As for @property: this makes it able to guarantee what it was originally
> designed for.
>
> ...
>
> Or am I completely wrong? Did I miss anything?

1 and 2 are necessary. I do not care about 3.

IIRC Adam likes to have both fun = value and fun(value) available for the same function.

On Wednesday, 23 January 2013 at 22:07:30 UTC, Timon Gehr wrote:
> IIRC Adam likes to have both fun = value and fun(value) available for the same function.

Yeah, it is sometimes useful for methods that can be both chained and assigned:

foo.bar(10).baz("hello");

vs

foo.bar = 10;
foo.baz = "hello";


...and sometimes  just as a quick convenience when hunting bugs (yup, I'm kinda for writeln = str; because you can throw that in without hunting for the end of the expression to put in the close paren.



I see no reason to change the current behavior for non-@property.

Now, for @property setters, we might use them for other operations too.

@property int a() { return 10; }
@property void a(int v) { ... }

a += 10;

should be transformed into a(a() + 10); which is not currently done.

On 01/23/2013 09:33 PM, Jacob Carlborg wrote:
>
> This is how it should look like. Date ranges in Ruby on Rails can be
> really beautiful:
>
> date = 2.days.ago
>
> I think we should have the same in D.

As long as your not using -property:
http://dpaste.dzfl.pl/56960911

-- 
Mike Wey