View mode: basic / threaded / horizontal-split · Log in · Help
January 23, 2013
Re: Make dur a property?
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
January 23, 2013
Re: Make dur a property?
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).
January 23, 2013
Re: Make dur a property?
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
January 23, 2013
Re: Make dur a property?
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
January 23, 2013
Re: Make dur a property?
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.
January 23, 2013
Re: Make dur a property?
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?
January 23, 2013
Re: Make dur a property?
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 */
);
January 23, 2013
Re: Make dur a property?
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.
January 23, 2013
Re: Make dur a property?
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.
January 23, 2013
Re: Make dur a property?
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
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home