www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Make dur a property?

reply "monarch_dodra" <monarchdodra gmail.com> writes:
I was using dur, and as powerful as it is, I *hate* typing:

//----
Thread.sleep(dur!"msecs"(100));
//----

Then, this reminded me of an older thread I started:
Neat: UFCS for integer dot operator suffix
http://forum.dlang.org/thread/uchcycnsvykuojzhuokh forum.dlang.org

And then it struct me:
//----
Thread.sleep(100.dur!"msecs");
//----

Yay! Or even better:
//----
alias msecs = dur!"msecs"
...
Thread.sleep(100.msecs); //Wow. Talk about expressive !!!
//----

Sweet-o! How much cooler can this get?

...

Well, if you are compiling with "-property", the compiler forces 
you to type:
//----
Thread.sleep(100.msecs());
//----

It is *almost* the same thing, but actually not the same at all. 
It shatters the "native" feeling of the suffix notation.

AFAIK, the "-property" switch enforces that non-property 
functions use parenthesis, so removing an " property" attribute 
is potentially breaking. The opposite though is not so true. You 
can add  property to anything, and never break code.

...

So I thought I'd discuss: Would there be a reason to not make dur 
a property? This should impact no-one, but make ufcs usage that 
much more convenient. Can I get the go-ahead to make and document 
the change?

What about making things like msecs public aliases? How do you 
feel about that?
Jan 23 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/23/2013 06:03 PM, monarch_dodra wrote:

 ...

 Well, if you are compiling with "-property", the compiler forces you to
 ...


So don't.


 AFAIK, the "-property" switch enforces that non-property functions use
parenthesis, so removing an " property" attribute is potentially breaking. The
opposite though is not so true. You can add  property to anything, and never
break code.


That is completely nonsensical behaviour. Just ignore -property.
Jan 23 2013
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/23/2013 09:13 AM, Timon Gehr wrote:

 On 01/23/2013 06:03 PM, monarch_dodra wrote:

 ...

 Well, if you are compiling with "-property", the compiler forces you to
 ...


 So don't.


 AFAIK, the "-property" switch enforces that non-property functions use
 parenthesis, so removing an " property" attribute is potentially
 breaking. The opposite though is not so true. You can add  property to
 anything, and never break code.


 That is completely nonsensical behaviour. Just ignore -property.


+1.

Ali
Jan 23 2013
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:

 That is completely nonsensical behaviour. Just ignore -property.



Amen! -property MUST die.  property should fix the real problems 
with properties, not leave that broken while adding new problems.
Jan 23 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 23, 2013 at 06:26:51PM +0100, Adam D. Ruppe wrote:

 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:

That is completely nonsensical behaviour. Just ignore -property.


 
 
 Amen! -property MUST die.  property should fix the real problems
 with properties, not leave that broken while adding new problems.


I'm starting to think that perhaps  property should be disposed of
completely. Just unify properties with nullary functions and be done
with it. There is no semantic difference between them anyway. (Didn't D1
used to do that?)

Compiling with -property also makes *compile-time* unary functions look
ridiculous:

	int ctfeFunc(int arg)() { return dotDotDotMagic(arg); }
	void main() {
		//int x = ctfeFunc!(123);	// doesn't work with -property!
		int x = ctfeFunc!(123)();	// looks ridiculous
	}


T

-- 
They say that "guns don't kill people, people kill people." Well I think
the gun helps. If you just stood there and yelled BANG, I don't think
you'd kill too many people. -- Eddie Izzard, Dressed to Kill
Jan 23 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 17:47:44 UTC, H. S. Teoh wrote:

 I'm starting to think that perhaps  property should be disposed 
 of completely.


There is a problem  property can potentially solve: a property 
returning a callable.

alias void delegate() Callable;

struct test {
     property Callable foo() { ... }
}

test t;
Callable c = t.foo; // should work
t.foo(); // should call the returned function
t.foo()(); // this should NOT work


Currently, t.foo()() DOES work and t.foo() gives the callable, 
without actually calling it (i.e. does not work as it should).

-property and the current  property implementation do not even 
try to address this.




My preferred solution is:

1) all functions without  property work exactly the same way they 
do now (optional parenthesis, callable as setters with =)

2) all functions with  property are ALWAYS rewritten so that a 
reference to them instead references the return value and/or the 
setter function.

So the result would be similar to #define t.foo (t.foo()). The 
type system then takes care of the parenthesis - no special code 
is required for syntax.
Jan 23 2013
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 23 Jan 2013 19:08:09 +0100
schrieb "Adam D. Ruppe" <destructionator gmail.com>:


 
 My preferred solution is:
 
 1) all functions without  property work exactly the same way they 
 do now (optional parenthesis, callable as setters with =)
 
 2) all functions with  property are ALWAYS rewritten so that a 
 reference to them instead references the return value and/or the 
 setter function.


This sounds OK, but you can still run into the callable issue if a
normal function returns a callable.

Probably add a rule that if a normal function returns a callable,
calling it without parentheses is illegal.
Jan 23 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau 
wrote:

 This sounds OK, but you can still run into the callable issue 
 if a normal function returns a callable.


I don't think so because delegates require the parens to call 
anyway, and so do opCall objects (without the parens, it is just 
a reference to it).


 Probably add a rule that if a normal function returns a 
 callable, calling it without parentheses is illegal.


That's not a bad idea.
Jan 23 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 19:40:02 +0100
"Adam D. Ruppe" <destructionator gmail.com> wrote:


 On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau 
 wrote:

 This sounds OK, but you can still run into the callable issue 
 if a normal function returns a callable.


 
 I don't think so because delegates require the parens to call 
 anyway, and so do opCall objects (without the parens, it is just 
 a reference to it).
 


So you want it to work like this?:

    void foo() {...}
    void delegate() {...} bar;

    foo; // call it
    bar; // don't call it

Yuck.

It's already bad enough that we have this goofy mess:

    int func() {...}

    void foo(int a) {...}
    void bar(int delegate() dg) {...}
    template baz(alias a) {...}

    foo(func); // Calls func
    bar(&func); // Doesn't call func, just refers to it
    baz!(func); // Doesn't call func, just refers to it
    baz!(&func); // Error

WTF?
Jan 23 2013
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 13:57:32 -0500
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

     void delegate() {...} bar;


Erm, obviously I meant:

void delegate() bar = ...;
Jan 23 2013
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
23-Jan-2013 22:57, Nick Sabalausky пишет:

 On Wed, 23 Jan 2013 19:40:02 +0100
 "Adam D. Ruppe" <destructionator gmail.com> wrote:


 On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau
 wrote:

 This sounds OK, but you can still run into the callable issue
 if a normal function returns a callable.


 I don't think so because delegates require the parens to call
 anyway, and so do opCall objects (without the parens, it is just
 a reference to it).


 So you want it to work like this?:

      void foo() {...}
      void delegate() {...} bar;

      foo; // call it


This is a call, arguably bad style


      bar; // don't call it


compile-time error, as statement has no side-effects?
(and we have this kind of check even now)



-- 
Dmitry Olshansky
Jan 23 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 23:03:32 +0400
Dmitry Olshansky <dmitry.olsh gmail.com> wrote:


 23-Jan-2013 22:57, Nick Sabalausky =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 On Wed, 23 Jan 2013 19:40:02 +0100
 "Adam D. Ruppe" <destructionator gmail.com> wrote:


 On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau
 wrote:

 This sounds OK, but you can still run into the callable issue
 if a normal function returns a callable.


 I don't think so because delegates require the parens to call
 anyway, and so do opCall objects (without the parens, it is just
 a reference to it).


 So you want it to work like this?:

      void foo() {...}
      void delegate() {...} bar;

      foo; // call it


=20
 This is a call, arguably bad style
=20

      bar; // don't call it


=20
 compile-time error, as statement has no side-effects?
 (and we have this kind of check even now)
=20
=20
=20


int foo() {...}
int delegate() {...} bar;

auto x =3D foo; // call it
auto y =3D bar; // don't call it
Jan 23 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 19:29:44 UTC, Nick Sabalausky 
wrote:

 int foo() {...}
 int delegate() {...} bar;

 auto x = foo; // call it
 auto y = bar; // don't call it


I don't have a problem with that because delegates and functions 
are different beasts anyway. For one major example, you can't 
rebind a function, but you can rebind a delegate, so "bar" has a 
meaning that "foo" doesn't (and &bar and &foo are different 
beasts too, one is address of a (rebindable) pointer, the other 
is address of a function, so they won't match up either).
Jan 23 2013
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 18:57:38 UTC, Nick Sabalausky 
wrote:

 So you want it to work like this?:


Yes, keeping the current behavior unless you opt-in to  property 
(though I wouldn't object to Dmitry's idea of "error: expression 
has no effect").

If I update dmd again and get 1,000 useless errors over a trivial 
syntax change because some people on the newsgroups are insisting 
on cleansing the unbelievers, it is just going to make me sad.


 It's already bad enough that we have this goofy mess:


meh, I don't have a problem with any of that.
Jan 23 2013
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 23 Jan 2013 19:40:02 +0100
schrieb "Adam D. Ruppe" <destructionator gmail.com>:


 On Wednesday, 23 January 2013 at 18:24:22 UTC, Johannes Pfau 
 wrote:

 This sounds OK, but you can still run into the callable issue 
 if a normal function returns a callable.


 
 I don't think so because delegates require the parens to call 
 anyway, and so do opCall objects (without the parens, it is just 
 a reference to it).


Yes, the delegate needs the parentheses but the function does not:

int DG() {return 42};
int delegate() getDG() {return &DG};

auto dg = getDG; //OK
auto ??? = getDG();

The last line could be a call to getDG with optional parenthesis,
so ??? = DG. Or it could be a call to getDG without optional
parenthesis and a call to the returned DG, so ??? = 42.
Jan 23 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 19:18:09 UTC, Johannes Pfau 
wrote:

 int DG() {return 42};
 int delegate() getDG() {return &DG};

 auto dg = getDG; //OK
 auto ??? = getDG();

 The last line could be a call to getDG with optional 
 parenthesis,
 so ??? = DG. Or it could be a call to getDG without optional
 parenthesis and a call to the returned DG, so ??? = 42.


If getDG is a  property, ??? == 42, because getDG() is rewritten 
into (getDG())() - parens there would ALWAYS mean "call the 
return value", so any  property is indistinguishable from its 
return value. (if we get  property like I want)

Without  property, it'd return DG because while parenthesis are 
optional, if they are present, they always apply to the preceding 
thing directly; getDG == getDG() in all cases. (This is the 
status quo, which I'd retain)


The type system will help catch errors here better than the 
syntax.
Jan 23 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-23 19:08, Adam D. Ruppe wrote:


 My preferred solution is:

 1) all functions without  property work exactly the same way they do now
 (optional parenthesis, callable as setters with =)

 2) all functions with  property are ALWAYS rewritten so that a reference
 to them instead references the return value and/or the setter function.

 So the result would be similar to #define t.foo (t.foo()). The type
 system then takes care of the parenthesis - no special code is required
 for syntax.


What about functions not marked with  property?

writeln = "asd";

Doesn't look very nice.

-- 
/Jacob Carlborg
Jan 23 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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).
Jan 23 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 21:48:32 +0100
"Adam D. Ruppe" <destructionator gmail.com> wrote:


 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).


1. Bad comparison because operator overloading, symbol names, etc are
determined by the *callee*, not the caller. That is as it should be.

2. Strawman. The ability to write bad code is NOT valid justification
for offering a feature (ie the ability to call *any* arbitrary
single-arg function, rather than just properties, using assignment
syntax) that provides absolutely no useful value whatsoever.

Note that properties are *not* functions, they're only implemented using
functions (though D's syntax unfortunately does its best to conflate
the two notions - at least in part because those who originally
designed  property openly didn't understand and didn't like the whole
concept of properties).

Properties are fundamentally different from functions as they are used
for a fundamentally different conceptual model (yes, sometimes there is
a grey area - *SOMETIMES*, not usually). And this is a distinction that
is *inherently* made by the *callee*. The caller doesn't have a damn
thing to do with the choice other than to either get it right or get
it wrong - so why *allow* them to get it wrong? What does that gain
anyone? Not a damn thing.

Overly long variable names are NOT an accurate comparison here because
the border between good/bad variable names is impossibly fuzzy. Whereas
this, OTOH is binary: Either the author designed it as a property
or didn't. You can maybe argue with their choice in *some* cases, but
bottom line, it's either a property or it isn't. The caller doesn't
have jack shit to do with it.

What you're suggesting is comparable to allowing the caller to
determine member visibility. Or member existence, for that matter. Or
capitalization (I hate case-insensitive languages - what the hell does
that ability gain anybody other than helping to introduce inconsistency
and sloppiness? It's a non-feature - ditch it.)

(FWIW, I'm not advocating making dur a property. "minutes" is
obviously not a property of 10.)
Jan 23 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 22:24:20 UTC, Nick Sabalausky 
wrote:

 that provides absolutely no useful value whatsoever.


Do you think so many of us would be arguing for it and using it 
if it was of no value whatsoever?


 Note that properties are *not* functions


Indeed, which is why I separate out -property, a stupid waste of 
time, and  property, a good idea.

Parenthesis and properties have nothing to do with each other. 
But when  property was proposed, we didn't talk about what it 
*is* (indistinguishable semantics from the return value), but 
instead what it *looks like* (must not be called with 
parenthesis).

That's where all this pain comes from. Two separate features got 
intertwined due to a sloppy DIP.


You're talking about removing a feature (optional parenthesis) 
from the language. We need to be weary of doing that. You say it 
is useless... but it *is* used by many of us. Changing it now has 
a cost. Even if it was worthless, the benefit of killing a 
worthless feature is smaller than the harm caused by breaking the 
code.

Similarly, I feel the new keyword is a detriment (indeed, I think 
new is less useful than optional parens). It doesn't do anything 
that can't be done in the library and gives special treatment to 
one preferred allocator (the gc), discouraging others and 
preventing easy replacement with user defined types (e.g. a 
create method that returns NotNull!T instead of T).

But the fact is that new is a feature in D today, and removing it 
would break a heck of a lot of code, so if I was given a vote on 
removing it... I'd vote to keep it how it is.




Now, property semantics are an entirely different issue, and 
thanks to the  property decoration, we CAN fix them without 
breaking anything else. That's a no-brainer to me, we should 
definitely do that.
Jan 23 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 5:46 PM, Adam D. Ruppe wrote:

 On Wednesday, 23 January 2013 at 22:24:20 UTC, Nick Sabalausky wrote:

 that provides absolutely no useful value whatsoever.


 Do you think so many of us would be arguing for it and using it if it
 was of no value whatsoever?


 Note that properties are *not* functions


 Indeed, which is why I separate out -property, a stupid waste of time,
 and  property, a good idea.

 Parenthesis and properties have nothing to do with each other. But when
  property was proposed, we didn't talk about what it *is*
 (indistinguishable semantics from the return value), but instead what it
 *looks like* (must not be called with parenthesis).

 That's where all this pain comes from. Two separate features got
 intertwined due to a sloppy DIP.


We need a good DIP on this. UFCS has destroyed all arguments in favor of 
requiring parens. There is no question we must do this. Anyone inclined 
toward writing a detailed DIP?

Andrei
Jan 23 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 18:39:49 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 
 We need a good DIP on this. UFCS has destroyed all arguments in favor
 of requiring parens.


Uhh, how exactly?
Jan 23 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 8:59 PM, Nick Sabalausky wrote:

 On Wed, 23 Jan 2013 18:39:49 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:

 We need a good DIP on this. UFCS has destroyed all arguments in favor
 of requiring parens.


 Uhh, how exactly?


With compelling examples that look awesome without parens and look awful 
with.

Andrei
Jan 23 2013
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
Alexandrescu wrote:

 We need a good DIP on this. [snip]


DIPs are good in theory but I think the process really needs to 
be formalized.  In the past 3 years there have been thirteen DIPs 
with only one being approved and implemented.  Perhaps 12 of 
those really weren't good enough to pursue but, upon looking at 
some of the proposals I really like, I think it's probably more 
the case that they get proposed and then the community forgets 
about them.  DIPs seem to be the place where good ideas go to die.

I think just applying the phobos module review process to DIPs 
would help a lot (although that process suffers from a lack of 
initiative in actually running reviews but I think that's 
something that can be overcome).  It'd force the community to 
make a yea or nay decision instead of just letting them languish 
in the wiki.

BA
Jan 23 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-24 03:17, Brad Anderson wrote:

 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:

 We need a good DIP on this. [snip]


 DIPs are good in theory but I think the process really needs to be
 formalized.  In the past 3 years there have been thirteen DIPs with only
 one being approved and implemented.


According to this there's been four implemented:

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs

It think it seems correctly.

-- 
/Jacob Carlborg
Jan 24 2013
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
Alexandrescu wrote:

 We need a good DIP on this. UFCS has destroyed all arguments in 
 favor of requiring parens. There is no question we must do 
 this. Anyone inclined toward writing a detailed DIP?

 Andrei


What about optional parens on non-UFCS calls, is there a case for 
this? Honest question.

I'm inclined to writing a DIP.
Jan 23 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 1:18 AM, monarch_dodra wrote:

 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:

 We need a good DIP on this. UFCS has destroyed all arguments in favor
 of requiring parens. There is no question we must do this. Anyone
 inclined toward writing a detailed DIP?

 Andrei


 What about optional parens on non-UFCS calls, is there a case for this?
 Honest question.


Let them be.


 I'm inclined to writing a DIP.


That would be great!


Andrei
Jan 23 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 24 January 2013 at 06:34:58 UTC, Andrei Alexandrescu 
wrote:

 On 1/24/13 1:18 AM, monarch_dodra wrote:

 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
 Alexandrescu wrote:

 We need a good DIP on this. UFCS has destroyed all arguments 
 in favor
 of requiring parens. There is no question we must do this. 
 Anyone
 inclined toward writing a detailed DIP?

 Andrei


 What about optional parens on non-UFCS calls, is there a case 
 for this?
 Honest question.


 Let them be.


 I'm inclined to writing a DIP.


 That would be great!


 Andrei


We actually have one, which I think I agree with:
http://wiki.dlang.org/DIP21

The gist of the DIP is that something marked with  property is 
always and immediately expanded into a call.

This fits into my proposal of:
1) properties never have parens (they are added by the compiler)
2) You can't take the address of a property function: "&foo" 
would become "&foo()", so you'd always get the address of the 
return value.

- make parens optional for everything else.
- allow the "foo = 5" rewrite into "foo(5)" only for properties.
-- Note that if foo is a non-property that returns by ref, then 
"foo = 5" remains legal
-- However, "writeln = 5" would be illegal.

I think properties is a really cool & powerful concept. It got 
conflated into "optional parens". This doesn't mean we should 
just "take it out back"...
Jan 24 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 4:28 AM, monarch_dodra wrote:

 We actually have one, which I think I agree with:
 http://wiki.dlang.org/DIP21


Walter convinced me last night that eliminating  property is more sensible.

Andrei
Jan 24 2013
next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 24 January 2013 at 16:30:45 UTC, Andrei Alexandrescu 
wrote:

 On 1/24/13 4:28 AM, monarch_dodra wrote:

 We actually have one, which I think I agree with:
 http://wiki.dlang.org/DIP21


 Walter convinced me last night that eliminating  property is 
 more sensible.


He hasn't even *tried* to address the arguments which led to the 
introduction of  property here, though.

I don't like  property myself, and even less the current broken 
implementation, but just saying »meh, we don't need it anyway« 
without even reviewing the reasons that led to its introduction 
is the worst possible way of handling the situation. And if this 
has already been done, why not summarize the rationale for 
removing it anyway here?

Otherwise, everybody has to dig through numerous threads in the 
archives in order to even *join* the discussion. I'm sure many 
people just shouting "+1" here have not considered the behavior 
in the various special cases involved.

In any case, I'm looking forward to seeing these points addressed 
in a DIP on the topic.

David
Jan 24 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 11:30:46 Andrei Alexandrescu wrote:

 On 1/24/13 4:28 AM, monarch_dodra wrote:

 We actually have one, which I think I agree with:
 http://wiki.dlang.org/DIP21


 
 Walter convinced me last night that eliminating  property is more sensible.


Well, that's bad news. It's bad enough that  property hasn't been properly 
sorted out, but getting rid of it completely disregards the problems that it's 
trying to solve. Getting rid of  property would be a horrible move IMHO.

- Jonathan M Davis
Jan 24 2013
next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 24 Jan 2013 20:26:25 +0100
schrieb "Jonathan M Davis" <jmdavisProg gmx.com>:


 On Thursday, January 24, 2013 11:30:46 Andrei Alexandrescu wrote:

 On 1/24/13 4:28 AM, monarch_dodra wrote:

 We actually have one, which I think I agree with:
 http://wiki.dlang.org/DIP21


 
 Walter convinced me last night that eliminating  property is more
 sensible.


 
 Well, that's bad news. It's bad enough that  property hasn't been
 properly sorted out, but getting rid of it completely disregards the
 problems that it's trying to solve. Getting rid of  property would be
 a horrible move IMHO.
 
 - Jonathan M Davis


Especially as it means that we have to deprecate  property first and
it'll probably stay around for at least another year.
Jan 24 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 2:26 PM, Jonathan M Davis wrote:

 On Thursday, January 24, 2013 11:30:46 Andrei Alexandrescu wrote:

 On 1/24/13 4:28 AM, monarch_dodra wrote:

 We actually have one, which I think I agree with:
 http://wiki.dlang.org/DIP21


 Walter convinced me last night that eliminating  property is more sensible.


 Well, that's bad news. It's bad enough that  property hasn't been properly
 sorted out, but getting rid of it completely disregards the problems that it's
 trying to solve. Getting rid of  property would be a horrible move IMHO.


No, the idea is to use better inference for the cases in which  property 
would be appropriate.

So we are looking at _changing_ the language, not simply ignoring  property.


Andrei
Jan 24 2013
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 15:14:36 Andrei Alexandrescu wrote:

 On 1/24/13 2:26 PM, Jonathan M Davis wrote:

 On Thursday, January 24, 2013 11:30:46 Andrei Alexandrescu wrote:

 On 1/24/13 4:28 AM, monarch_dodra wrote:

 We actually have one, which I think I agree with:
 http://wiki.dlang.org/DIP21


 
 Walter convinced me last night that eliminating  property is more
 sensible.


 
 Well, that's bad news. It's bad enough that  property hasn't been properly
 sorted out, but getting rid of it completely disregards the problems that
 it's trying to solve. Getting rid of  property would be a horrible move
 IMHO.


 No, the idea is to use better inference for the cases in which  property
 would be appropriate.
 
 So we are looking at _changing_ the language, not simply ignoring  property.


Then what do you mean to do with  property? Regardless of what we do with 
paren-less function calls, I think that it's important to have explicit 
properties - particularly when you consider enhancement requests such as
http://d.puremagic.com/issues/show_bug.cgi?id=8006 (which we probably should 
have implemented ages ago).

- Jonathan M Davis
Jan 24 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
Alexandrescu wrote:

 We need a good DIP on this. UFCS has destroyed all arguments in 
 favor of requiring parens. There is no question we must do 
 this. Anyone inclined toward writing a detailed DIP?


Let me strongly disagree. Language feature should never be 
introduced where library solution is possible.

And library solution is possible. And opDispatch makes it 
possible.
Jan 24 2013
next sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:

 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
 Alexandrescu wrote:

 We need a good DIP on this. UFCS has destroyed all arguments 
 in favor of requiring parens. There is no question we must do 
 this. Anyone inclined toward writing a detailed DIP?


 Let me strongly disagree. Language feature should never be 
 introduced where library solution is possible.


C has strings as a concept and C++ as a library solution. Which 
strings are better: C, C++ or D?
Jan 24 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 14:53:49 UTC, Maxim Fomin wrote:

 On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:

 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
 Alexandrescu wrote:

 We need a good DIP on this. UFCS has destroyed all arguments 
 in favor of requiring parens. There is no question we must do 
 this. Anyone inclined toward writing a detailed DIP?


 Let me strongly disagree. Language feature should never be 
 introduced where library solution is possible.


 C has strings as a concept and C++ as a library solution. Which 
 strings are better: C, C++ or D?


D string string is not builtin. string is merely a thing in D.

D have builtin slices, which is a generic feature that is used 
with whatever you want.
Jan 24 2013
parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Thursday, 24 January 2013 at 15:02:02 UTC, deadalnix wrote:

 On Thursday, 24 January 2013 at 14:53:49 UTC, Maxim Fomin wrote:

 On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:

 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
 Alexandrescu wrote:

 We need a good DIP on this. UFCS has destroyed all arguments 
 in favor of requiring parens. There is no question we must 
 do this. Anyone inclined toward writing a detailed DIP?


 Let me strongly disagree. Language feature should never be 
 introduced where library solution is possible.


 C has strings as a concept and C++ as a library solution. 
 Which strings are better: C, C++ or D?


 D string string is not builtin. string is merely a thing in D.

 D have builtin slices, which is a generic feature that is used 
 with whatever you want.


Perhaps a bad example but I disagree that any feature that can be 
implemented as a library, should not be introduced as a language 
feature. Some features needed to be embedded into language 
because as a library features they would be very ugly.
Jan 24 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 15:32:36 UTC, Maxim Fomin wrote:

 Perhaps a bad example but I disagree that any feature that can 
 be implemented as a library, should not be introduced as a 
 language feature. Some features needed to be embedded into 
 language because as a library features they would be very ugly.


Yes, that is true. But in our case, the library solution isn't 
ugly.
Jan 24 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 9:25 AM, deadalnix wrote:

 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:

 We need a good DIP on this. UFCS has destroyed all arguments in favor
 of requiring parens. There is no question we must do this. Anyone
 inclined toward writing a detailed DIP?


 Let me strongly disagree. Language feature should never be introduced
 where library solution is possible.


Absolutes are difficult positions in language design.


 And library solution is possible. And opDispatch makes it possible.


Problem is, a lot of code would need to add opDispatch. I don't think 
that's good language design.


Andrei
Jan 24 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 18:01:30 UTC, Andrei Alexandrescu 
wrote:

 On 1/24/13 9:25 AM, deadalnix wrote:

 On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
 Alexandrescu wrote:

 We need a good DIP on this. UFCS has destroyed all arguments 
 in favor
 of requiring parens. There is no question we must do this. 
 Anyone
 inclined toward writing a detailed DIP?


 Let me strongly disagree. Language feature should never be 
 introduced
 where library solution is possible.


 Absolutes are difficult positions in language design.


This is why I used should and not must.


 And library solution is possible. And opDispatch makes it 
 possible.


 Problem is, a lot of code would need to add opDispatch. I don't 
 think that's good language design.


Not at all, you can provide one via UFCS.
Jan 24 2013
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 23 Jan 2013 09:45:49 -0800
schrieb "H. S. Teoh" <hsteoh quickfur.ath.cx>:


 On Wed, Jan 23, 2013 at 06:26:51PM +0100, Adam D. Ruppe wrote:

 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:

That is completely nonsensical behaviour. Just ignore -property.


 
 
 Amen! -property MUST die.  property should fix the real problems
 with properties, not leave that broken while adding new problems.


 
 I'm starting to think that perhaps  property should be disposed of
 completely.


Please do not forget the main reason for  property: Returning a
delegate from a function can become ambiguous without it:

int a(){return 42;}
void b() {return &a;}

auto var = b; //OK
auto var2 = b(); //is var2 == b or == 42?

It might be an extreme corner case, but it's inconsistent behavior and
confusing. Need a real-world example?
http://www.digitalmars.com/d/archives/digitalmars/D/ModuleInfo.unitTest_cannot_be_called_twice_183357.html
(with proper  property the first example should work as expected).

So if most people really think  property is such a problem we can
probably remove it, but we have to make sure examples like this one are
not ambiguous.
Jan 23 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 1:18 PM, Johannes Pfau wrote:

 Please do not forget the main reason for  property: Returning a
 delegate from a function can become ambiguous without it:

 int a(){return 42;}
 void b() {return&a;}

 auto var = b; //OK
 auto var2 = b(); //is var2 == b or == 42?

 It might be an extreme corner case, but it's inconsistent behavior and
 confusing.


Agreed. I think we should require  property only for those cases, and 
not any others.

Andrei
Jan 23 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 15:11:35 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 1/23/13 1:18 PM, Johannes Pfau wrote:

 Please do not forget the main reason for  property: Returning a
 delegate from a function can become ambiguous without it:

 int a(){return 42;}
 void b() {return&a;}

 auto var = b; //OK
 auto var2 = b(); //is var2 == b or == 42?

 It might be an extreme corner case, but it's inconsistent behavior
 and confusing.


 
 Agreed. I think we should require  property only for those cases, and 
 not any others.
 
 Andrei


I'd rather not see more "Sometimes the language lets me skip XXXX, and
sometimes it complains" get introduced into the language. That
complicates the language and makes the language harder to understand.

There are cases where that strategy has certainly made sense, but at
this point I think you're just grasping for ways to justify leaving in
the non-beneficial "Use either 'foo' or 'foo()', whichever you want,
anytime you want" sloppiness. And making sure that non-feature can
remain by introducing more special-cases into the language to patch
over the problems with the non-feature.
Jan 23 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 5:32 PM, Nick Sabalausky wrote:

 I'd rather not see more "Sometimes the language lets me skip XXXX, and
 sometimes it complains" get introduced into the language. That
 complicates the language and makes the language harder to understand.

 There are cases where that strategy has certainly made sense, but at
 this point I think you're just grasping for ways to justify leaving in
 the non-beneficial "Use either 'foo' or 'foo()', whichever you want,
 anytime you want" sloppiness. And making sure that non-feature can
 remain by introducing more special-cases into the language to patch
 over the problems with the non-feature.


UFCS has effectively buried the case for requiring parens.

Andrei
Jan 23 2013
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, January 23, 2013 18:35:24 Andrei Alexandrescu wrote:

 UFCS has effectively buried the case for requiring parens.


Honestly, I'd love to require parens even with UFCS, but I think that it's 
clear that most folks want the parens to be optional for UFCS, and at this 
point, requiring parens would break a lot of code. So, even if it were 
generally agreed upon that it's a great idea to require them, the cost in code 
breakage would risk making the change unacceptable.

- Jonathan M Davis
Jan 23 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-23 19:18, Johannes Pfau wrote:


 It might be an extreme corner case, but it's inconsistent behavior and
 confusing. Need a real-world example?
 http://www.digitalmars.com/d/archives/digitalmars/D/ModuleInfo.unitTest_cannot_be_called_twice_183357.html
 (with proper  property the first example should work as expected).


Yeah, that was kind of embarrassing.

-- 
/Jacob Carlborg
Jan 23 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 09:45:49 -0800
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:


 On Wed, Jan 23, 2013 at 06:26:51PM +0100, Adam D. Ruppe wrote:

 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:

That is completely nonsensical behaviour. Just ignore -property.


 
 
 Amen! -property MUST die.  property should fix the real problems
 with properties, not leave that broken while adding new problems.


 
 I'm starting to think that perhaps  property should be disposed of
 completely. Just unify properties with nullary functions and be done
 with it. There is no semantic difference between them anyway. (Didn't
 D1 used to do that?)
 


Unfortunately, yea, D1 did do that. One of the many things that were
fixed in D2 (at least it was partially fixed anyway).

Having the *caller* decide whether something is a property or not makes
as much sense as having the caller decide the function's name,
signature and semantics.

This level of need to go doing s/()/ over everything is
blown ridiculously out of proportion. Not to mention misguided. I've
dealt with code that consistently took advantage of D1's misfeature of
disguising function calls as no-op statements, and it absolutely is
a non-feature that provides no *real* benefit outside of code
obfuscation contests.

Properties are for *properties*, not for hacking around a language's
syntax for the sake of a highly questionable and semantically
misleading aesthetic "benefit". And just because certain people
are unable/unwilling to see that there *is* in fact a meaningful
distinction between "property" and "function" doesn't mean it isn't
actually there.


 int x = ctfeFunc!(123)();	// looks ridiculous


If anything, that's an issue with template syntax, it has nothing to do
with properties, let alone the beloved practice of abusing properties
for the sake of things that clearly are not properties.
Jan 23 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 1:48 PM, Nick Sabalausky wrote:

 Having the *caller* decide whether something is a property or not makes
 as much sense as having the caller decide the function's name,
 signature and semantics.


No. The caller does get to decide a variety of syntactic aspects of the 
invocation.


 If anything, that's an issue with template syntax, it has nothing to do
 with properties, let alone the beloved practice of abusing properties
 for the sake of things that clearly are not properties.


The implied assumption here is that if it doesn't have parens it's a 
property. Well it's a function call.


Andrei
Jan 23 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 15:14:21 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 1/23/13 1:48 PM, Nick Sabalausky wrote:

 Having the *caller* decide whether something is a property or not
 makes as much sense as having the caller decide the function's name,
 signature and semantics.


 
 No. The caller does get to decide a variety of syntactic aspects of
 the invocation.
 


Yes, but it's unfortunate that includes a part of the syntax that
carries semantic/conceptual implications for something (action or
data) that is already *inherently* determined by writer of the *callee*.


 If anything, that's an issue with template syntax, it has nothing
 to do with properties, let alone the beloved practice of abusing
 properties for the sake of things that clearly are not properties.


 
 The implied assumption here is that if it doesn't have parens it's a 
 property. Well it's a function call.
 


Right, it's a function call. So what in the world do we gain by
allowing the caller to make it look like something it isn't? Nothing.
Jan 23 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/23/2013 11:40 PM, Nick Sabalausky wrote:

 On Wed, 23 Jan 2013 15:14:21 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 1/23/13 1:48 PM, Nick Sabalausky wrote:

 Having the *caller* decide whether something is a property or not
 makes as much sense as having the caller decide the function's name,
 signature and semantics.


 No. The caller does get to decide a variety of syntactic aspects of
 the invocation.


 Yes, but it's unfortunate that includes a part of the syntax that
 carries semantic/conceptual implications for something (action or
 data) that is already *inherently* determined by writer of the *callee*.


Keeping or leaving out the parens has no semantic implications.


 If anything, that's an issue with template syntax, it has nothing
 to do with properties, let alone the beloved practice of abusing
 properties for the sake of things that clearly are not properties.


 The implied assumption here is that if it doesn't have parens it's a
 property. Well it's a function call.


 Right, it's a function call. So what in the world do we gain by
 allowing the caller to make it look like something it isn't? Nothing.


That does not make any sense. It still looks just like a function call, 
because that is how a function call might look.
Jan 23 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 00:30:43 +0100
Timon Gehr <timon.gehr gmx.ch> wrote:


 On 01/23/2013 11:40 PM, Nick Sabalausky wrote:

 On Wed, 23 Jan 2013 15:14:21 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 1/23/13 1:48 PM, Nick Sabalausky wrote:

 Having the *caller* decide whether something is a property or not
 makes as much sense as having the caller decide the function's
 name, signature and semantics.


 No. The caller does get to decide a variety of syntactic aspects of
 the invocation.


 Yes, but it's unfortunate that includes a part of the syntax that
 carries semantic/conceptual implications for something (action or
 data) that is already *inherently* determined by writer of the
 *callee*.


 
 Keeping or leaving out the parens has no semantic implications.
 


foo.bar() // Perform action
foo.bar   // Access data
Jan 23 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-24 03:02, Nick Sabalausky wrote:


 foo.bar() // Perform action
 foo.bar   // Access data


Who says it has to be like this.

-- 
/Jacob Carlborg
Jan 24 2013
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 24 Jan 2013 09:20:44 +0100
schrieb Jacob Carlborg <doob me.com>:


 On 2013-01-24 03:02, Nick Sabalausky wrote:
 

 foo.bar() // Perform action
 foo.bar   // Access data


 
 Who says it has to be like this.
 


.NET guidelines since .NET 1.1 for example:

"In general, methods represent actions and properties represent data."
(http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx).
Jan 24 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 04:45 PM, Johannes Pfau wrote:

 Am Thu, 24 Jan 2013 09:20:44 +0100
 schrieb Jacob Carlborg <doob me.com>:


 On 2013-01-24 03:02, Nick Sabalausky wrote:


 foo.bar() // Perform action
 foo.bar   // Access data


 Who says it has to be like this.


 .NET guidelines since .NET 1.1 for example:

 "In general, methods represent actions and properties represent data."
 (http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx).
Jan 24 2013
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 25 Jan 2013 00:11:24 +0100
schrieb Timon Gehr <timon.gehr gmx.ch>:


 On 01/24/2013 04:45 PM, Johannes Pfau wrote:

 Am Thu, 24 Jan 2013 09:20:44 +0100
 schrieb Jacob Carlborg <doob me.com>:


 On 2013-01-24 03:02, Nick Sabalausky wrote:


 foo.bar() // Perform action
 foo.bar   // Access data


 Who says it has to be like this.


 .NET guidelines since .NET 1.1 for example:

 "In general, methods represent actions and properties represent
 data." (http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx).


 



I think I misunderstood the question. If the question was whether the
parenthesis mark an action as opposed to data access, then my
statement is of course void. (But it's a tradition from C that () mark
function calls).

I thought he meant properties should be used for data access. This is


for data access, if you don't use properties for data access but for
other things the whole concept doesn't make sense. So in that case


Properties are polymorphic fields, nothing more nothing less. The D
implementation is horrible though as you can't do  stuff like
x.field++. However, how would you implement this without properties and
fields:

x.value++; //Field or property
x.setValue(x.getValue()++); //How ugly...
x.setValue(x.getValue++); //Really ugly (optional parentheses func call)

You can't allow these rewrites for normal functions, it'll be a
disaster and this is why we need properties. And it's also the reason
why properties are data: they're fields and fields are data.
Jan 25 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2013 05:56 PM, Johannes Pfau wrote:

 Am Fri, 25 Jan 2013 00:11:24 +0100
 schrieb Timon Gehr <timon.gehr gmx.ch>:


 On 01/24/2013 04:45 PM, Johannes Pfau wrote:

 Am Thu, 24 Jan 2013 09:20:44 +0100
 schrieb Jacob Carlborg <doob me.com>:


 On 2013-01-24 03:02, Nick Sabalausky wrote:


 foo.bar() // Perform action
 foo.bar   // Access data


 Who says it has to be like this.


 .NET guidelines since .NET 1.1 for example:

 "In general, methods represent actions and properties represent
 data." (http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx).





 I think I misunderstood the question. If the question was whether the
 parenthesis mark an action as opposed to data access, then my
 statement is of course void. (But it's a tradition from C that () mark
 function calls).

 I thought he meant properties should be used for data access. This is


 for data access, if you don't use properties for data access but for
 other things the whole concept doesn't make sense. So in that case

 ...


I think he meant both. =)
Jan 25 2013
prev sibling parent "mist" <none none.none> writes:
On Thursday, 24 January 2013 at 23:11:25 UTC, Timon Gehr wrote:
Jan 25 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 3:20 AM, Jacob Carlborg wrote:

 On 2013-01-24 03:02, Nick Sabalausky wrote:


 foo.bar() // Perform action
 foo.bar // Access data


 Who says it has to be like this.


Agreed. It's an implied, unstated assumption - the most dangerous kind.

Andrei
Jan 24 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 11:25:38 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 1/24/13 3:20 AM, Jacob Carlborg wrote:

 On 2013-01-24 03:02, Nick Sabalausky wrote:


 foo.bar() // Perform action
 foo.bar // Access data


 Who says it has to be like this.


 
 Agreed. It's an implied, unstated assumption - the most dangerous
 kind.
 


It's dangerous to *break*, not to follow.
Jan 24 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 07:16 PM, Nick Sabalausky wrote:

 On Thu, 24 Jan 2013 11:25:38 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 1/24/13 3:20 AM, Jacob Carlborg wrote:

 On 2013-01-24 03:02, Nick Sabalausky wrote:


 foo.bar() // Perform action
 foo.bar // Access data


 Who says it has to be like this.


 Agreed. It's an implied, unstated assumption - the most dangerous
 kind.


 It's dangerous to *break*, not to follow.


It's somewhat dangerous to assume but not to follow at the same time. No 
significantly stronger statement can be made, which is why this is a 
matter of taste.
Jan 24 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-24 19:16, Nick Sabalausky wrote:


 It's dangerous to *break*, not to follow.


Follow what? There are several languages that don't care if you use 
parentheses when calling a method.

-- 
/Jacob Carlborg
Jan 24 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 5:40 PM, Nick Sabalausky wrote:

 On Wed, 23 Jan 2013 15:14:21 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:


 On 1/23/13 1:48 PM, Nick Sabalausky wrote:

 Having the *caller* decide whether something is a property or not
 makes as much sense as having the caller decide the function's name,
 signature and semantics.


 No. The caller does get to decide a variety of syntactic aspects of
 the invocation.


 Yes, but it's unfortunate that includes a part of the syntax that
 carries semantic/conceptual implications for something (action or
 data) that is already *inherently* determined by writer of the *callee*.


"Semantic" and "conceptual" sound interesting but are a bit out of 
context here. We're talking simple syntax here, and in particular an 
option available to other languages already.


 If anything, that's an issue with template syntax, it has nothing
 to do with properties, let alone the beloved practice of abusing
 properties for the sake of things that clearly are not properties.


 The implied assumption here is that if it doesn't have parens it's a
 property. Well it's a function call.


 Right, it's a function call. So what in the world do we gain by
 allowing the caller to make it look like something it isn't? Nothing.


Never answer your own rhetorical question :o).


Andrei
Jan 23 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 18:38:11 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 1/23/13 5:40 PM, Nick Sabalausky wrote:

 On Wed, 23 Jan 2013 15:14:21 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:


 On 1/23/13 1:48 PM, Nick Sabalausky wrote:

 Having the *caller* decide whether something is a property or not
 makes as much sense as having the caller decide the function's
 name, signature and semantics.


 No. The caller does get to decide a variety of syntactic aspects of
 the invocation.


 Yes, but it's unfortunate that includes a part of the syntax that
 carries semantic/conceptual implications for something (action or
 data) that is already *inherently* determined by writer of the
 *callee*.


 
 "Semantic" and "conceptual" sound interesting but are a bit out of 
 context here. We're talking simple syntax here, and in particular an 
 option available to other languages already.
 


I realize that you think properties are purely a syntactic matter, but
that misunderstanding is the heart of the problem. You're thinking "Do
I feel like calling this function with or without parens?" That's
completely wrong and demonstrates a continued misunderstanding of
properties.

The real question is "Is this an action or data?" (And obviously I mean
when viewed from outside the encapsulation, I don't mean the
implementation.) Note that the answer to that question is NOT
subjective to the context of the caller, only the callee. Blindly
discounting the "conceptual" matter (ie "action or data?") is a
convenient way contort the issue so that it fits back into the "Call
with/without parens?" strawman.

There have already been enough problems shown that have arisen as a
direct result of mistreating the matter of properties as merely
an "optional paren" syntax matter. You suggest various additional rules
to patch over those symptoms, but when you consider the very simple,
time-honored, and frankly very very common, association of:

foo.bar() // Perform action
foo.bar   // Read/Write data

Then you'll notice that all those edge cases created by the "optional
paren" mindset simply vanish as natural straightforward consequences of
the above rule. No need for any additional rules or "sometimes
required, sometimes optional" puzzles.

This is a problem that other languages have *already* solved, with
well-known, well-understood solutions (ie: the "action==paren,
data==no parem" rule). Unfortunately, despite the readily available
solution, D is still trying to wrap its head around the matter, and
winds up flailing around in a sea of issues because it is (you are)
desperately clinging to the failed (ie: it creates problems) and
unimportant notion of "No matter what happens with properties, I *must*
be able to decide on a whim whether I feel like calling a particular
func with or without parans". Try detaching from that desire for a while
and explore it plays out.



 If anything, that's an issue with template syntax, it has nothing
 to do with properties, let alone the beloved practice of abusing
 properties for the sake of things that clearly are not properties.


 The implied assumption here is that if it doesn't have parens it's
 a property. Well it's a function call.


 Right, it's a function call. So what in the world do we gain by
 allowing the caller to make it look like something it isn't?
 Nothing.


 
 Never answer your own rhetorical question :o).
 


I think there's also another overrated rule that prohibits use of the
word "you" ;)

But fine:

"Right, it's a function call. So what in the world do we gain by
allowing the caller to make it look like something it isn't?"
Jan 23 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Nick Sabalausky:


 This is a problem that other languages have *already* solved, 
 with
 well-known, well-understood solutions (ie: the "action==paren,
 data==no parem" rule). Unfortunately, despite the readily 
 available
 solution, D is still trying to wrap its head around the matter, 
 and
 winds up flailing around in a sea of issues because it is (you 
 are)
 desperately clinging to the failed (ie: it creates problems) and
 unimportant notion of "No matter what happens with properties, 
 I *must*
 be able to decide on a whim whether I feel like calling a 
 particular
 func with or without parans". Try detaching from that desire 
 for a while
 and explore it plays out.


+1 :-)

Bye,
bearophile
Jan 23 2013
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
24-Jan-2013 06:46, Nick Sabalausky пишет:

 On Wed, 23 Jan 2013 18:38:11 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:



 The real question is "Is this an action or data?" (And obviously I mean
 when viewed from outside the encapsulation, I don't mean the
 implementation.) Note that the answer to that question is NOT
 subjective to the context of the caller, only the callee. Blindly
 discounting the "conceptual" matter (ie "action or data?") is a
 convenient way contort the issue so that it fits back into the "Call
 with/without parens?" strawman.


These days properties imply an action of, well, obtaining said value. If 
it's a wrapper as in "return zis variable" something is wrong already.


 There have already been enough problems shown that have arisen as a
 direct result of mistreating the matter of properties as merely
 an "optional paren" syntax matter. You suggest various additional rules
 to patch over those symptoms, but when you consider the very simple,
 time-honored, and frankly very very common, association of:

 foo.bar() // Perform action
 foo.bar   // Read/Write data


The same argument was brought about overloading  operators, about 
overloading functions, etc. In other words the argument is WYSIWYG, but 
humans inherently think in overloaded notions and take obvious shortcuts
just about everywhere.

Also what about x.y itself? Unlike in C/C++ you don't know if x is a 
pointer or not. And so what? Add to this possible static members, D 
already cuts corners and not at all WYSIWYG. Also see the opDispatch 
problems as it can be either property or not.  property on its own 
brings a lot of schism.

What makes all of the engineering, science etc. domains usable at all - 
is an optimized/overloaded/shortened vocabulary. In this light extra 
parens are redundant and thus skipped, end of story. Feel free to impose 
a coding standard that requires usage of these and see how it goes.

-- 
Dmitry Olshansky
Jan 24 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 19:36:35 UTC, Dmitry Olshansky 
wrote:

 The same argument was brought about overloading  operators, 
 about overloading functions, etc. In other words the argument 
 is WYSIWYG, but humans inherently think in overloaded notions 
 and take obvious shortcuts
 just about everywhere.


That is not because it is ambiguous, where . overload behavior 
for pointer isn't.

Such behavior would be like if pointer dereferenced automagically 
and you add to put & everywhere to not dereference them. That 
would be an horrible behavior, as well as calling function 
automatically is an horrible behavior.

So we want to avoid () for convenience. I have noting against 
convenience, but here it is plain wrong :
  - We have 2 syntax to do the same thing.
  - If the return value is callable, it is unclear what is done.
  - We need something to NOT call the function, as it is called 
magically. Let's introduce &funName syntax and mess up with 
another feature.
  - It is now unclear when we take the return address or the 
address of the function.
  - It is also not clear how to pass a function as parameter (we 
have seen the case recently).
  - Depending on the callable, () and & have different behaviors, 
which is error prone, harder to learn for newcomer, harder for 
generic code, and exactly what everybody hate about C++ .

I have nothing against convenience, and like very much the 
pointer + dot behavior. I actuelly proposed something similar 
with functions : function.identifier can call the function 
without (), which is the equivalent of the pointer thing in term 
of convenience. Going further inherently mess up with other 
features of the language.
Jan 25 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 23:36:30 +0400
Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 
 These days properties imply an action of, well, obtaining said value.
 If it's a wrapper as in "return zis variable" something is wrong
 already.
 


I agree in principle, but unfortunately "return zis variable" getters
are often needed because no major language (that I know of) offers any
other way to create data that's privately-writable and
publicly-read-only - a very common need.

Ie, that's the "something" that "is wrong already": the lack of a
simple built-in "The public can only read this, but I can R/W it." to
obviate an extremely common idiom.
Jan 25 2013
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
25-Jan-2013 23:27, Nick Sabalausky пишет:

 On Thu, 24 Jan 2013 23:36:30 +0400
 Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 These days properties imply an action of, well, obtaining said value.
 If it's a wrapper as in "return zis variable" something is wrong
 already.


 I agree in principle, but unfortunately "return zis variable" getters
 are often needed because no major language (that I know of) offers any
 other way to create data that's privately-writable and
 publicly-read-only - a very common need.

 Ie, that's the "something" that "is wrong already": the lack of a
 simple built-in "The public can only read this, but I can R/W it." to
 obviate an extremely common idiom.


It might be worth extending the access modifiers (not going to happen) 
or maybe simplifying the boilerplate... (could happen but dunno).

-- 
Dmitry Olshansky
Jan 25 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-25 20:27, Nick Sabalausky wrote:


 I agree in principle, but unfortunately "return zis variable" getters
 are often needed because no major language (that I know of) offers any
 other way to create data that's privately-writable and
 publicly-read-only - a very common need.

 Ie, that's the "something" that "is wrong already": the lack of a
 simple built-in "The public can only read this, but I can R/W it." to
 obviate an extremely common idiom.


In Ruby one would do:

class Foo
   attr_reader :foo
end

This would create a getter and an instance variable. Internally one can 
write directly do the instance variable, or create a setter:

class Foo
   attr_reader :foo

private

   def foo= (value)

   end
end

The equal sign indicates the method is a property. Not that 
"attr_reader" is not a language feature, it's implemented in the core 
library. There are also functions available for getter and both getter 
and setter.

In D, I would like to see something like this:

 property(get, set) int a;
 property(get) int b;
 property(set) int c;
 property int d; // same as "a"

This would create a getter and/or setter and an instance variable. One 
could also experiment with the protection attributes like this:

public  property(get, protected set) int a;

One way could affect the instance variable, the other way to affect the 
getter/setter implementation.

-- 
/Jacob Carlborg
Jan 26 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 26 Jan 2013 12:33:11 +0100
Jacob Carlborg <doob me.com> wrote:


 On 2013-01-25 20:27, Nick Sabalausky wrote:
 

 I agree in principle, but unfortunately "return zis variable"
 getters are often needed because no major language (that I know of)
 offers any other way to create data that's privately-writable and
 publicly-read-only - a very common need.

 Ie, that's the "something" that "is wrong already": the lack of a
 simple built-in "The public can only read this, but I can R/W it."
 to obviate an extremely common idiom.


 
 In Ruby one would do:
 
 class Foo
    attr_reader :foo
 end
 
 This would create a getter and an instance variable. Internally one
 can write directly do the instance variable, or create a setter:
 
 class Foo
    attr_reader :foo
 
 private
 
    def foo= (value)

    end
 end
 
 The equal sign indicates the method is a property. Not that 
 "attr_reader" is not a language feature, it's implemented in the core 
 library. There are also functions available for getter and both
 getter and setter.
 
 In D, I would like to see something like this:
 
  property(get, set) int a;
  property(get) int b;
  property(set) int c;
  property int d; // same as "a"
 
 This would create a getter and/or setter and an instance variable.
 One could also experiment with the protection attributes like this:
 
 public  property(get, protected set) int a;
 
 One way could affect the instance variable, the other way to affect
 the getter/setter implementation.
 


Interesting.

Although with that in mind it seems my earlier statement is not
entirely true. There are languages that offer a "publically read-only"

do it via shorthand versions of their property syntaxes.
Jan 26 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-26 19:55, Nick Sabalausky wrote:


 Interesting.

 Although with that in mind it seems my earlier statement is not
 entirely true. There are languages that offer a "publically read-only"

 do it via shorthand versions of their property syntaxes.


Depending on how you look at it, D1 with const variables does as well 
and Java with final variables.

-- 
/Jacob Carlborg
Jan 26 2013
prev sibling parent "." <. .com> writes:
 "Right, it's a function call. So what in the world do we gain by
 allowing the caller to make it look like something it isn't?"


Nothing!
Jan 24 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-23 19:48, Nick Sabalausky wrote:


 Having the *caller* decide whether something is a property or not makes
 as much sense as having the caller decide the function's name,
 signature and semantics.


In Ruby parentheses are optional when calling a method. I have never had 
any problem with that, although in Ruby you invoke a callable object 
with ".call". Property setters are more explicit in Ruby than D:

def foo= (value)
end

The equal sign is actually part of the method name.

-- 
/Jacob Carlborg
Jan 23 2013
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/23/13, Adam D. Ruppe <destructionator gmail.com> wrote:

 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
 Amen! -property MUST die.  property should fix the real problems
 with properties, not leave that broken while adding new problems.


About  property problems, I've recently ran into this:
ModuleInfo.unitTest is defined as

 property void function() unitTest() nothrow pure;

And if I use it:

    foreach (m; ModuleInfo)
    {
        if (m is null)
            continue;

        if (auto fp = m.unitTest)
        {
            fp();           // calls it
            m.unitTest();   // doesn't call it
            m.unitTest()(); // calls it
        }
    }

This is regardless of the -property switch. I would expect the second
call to work. Anyone know if this is filed already?
Jan 23 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 21:29:14 +0100
Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:


 On 1/23/13, Adam D. Ruppe <destructionator gmail.com> wrote:

 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
 Amen! -property MUST die.  property should fix the real problems
 with properties, not leave that broken while adding new problems.


 
 About  property problems, I've recently ran into this:
 ModuleInfo.unitTest is defined as
 
  property void function() unitTest() nothrow pure;
 
 And if I use it:
 
     foreach (m; ModuleInfo)
     {
         if (m is null)
             continue;
 
         if (auto fp = m.unitTest)
         {
             fp();           // calls it
             m.unitTest();   // doesn't call it
             m.unitTest()(); // calls it
         }
     }
 
 This is regardless of the -property switch. I would expect the second
 call to work. Anyone know if this is filed already?


Don't know if it's filed, but yea: Optional empty-parens and
the practice of conflating properties with functions is riddled with
corner-cases. We can either try to patch over these corner cases
with increasingly detailed new rules, as Andrei is proposing, or we
can just accept "the writing on the wall" (if you'll pardon my 80's-ism)
that properties != functions.
Jan 23 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/23/2013 11:46 PM, Nick Sabalausky wrote:

 On Wed, 23 Jan 2013 21:29:14 +0100
 Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:


 On 1/23/13, Adam D. Ruppe <destructionator gmail.com> wrote:

 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
 Amen! -property MUST die.  property should fix the real problems
 with properties, not leave that broken while adding new problems.


 About  property problems, I've recently ran into this:
 ModuleInfo.unitTest is defined as

  property void function() unitTest() nothrow pure;

 And if I use it:

      foreach (m; ModuleInfo)
      {
          if (m is null)
              continue;

          if (auto fp = m.unitTest)
          {
              fp();           // calls it
              m.unitTest();   // doesn't call it
              m.unitTest()(); // calls it
          }
      }

 This is regardless of the -property switch. I would expect the second
 call to work. Anyone know if this is filed already?


 Don't know if it's filed, but yea: Optional empty-parens and
 the practice of conflating properties with functions is riddled with
 corner-cases. We can either try to patch over these corner cases
 with increasingly detailed new rules,


What are those "new" rules? The rules we already have are sufficient. 
Now the compiler needs to implement them properly.


 as Andrei is proposing, or we
 can just accept "the writing on the wall" (if you'll pardon my 80's-ism)
 that properties != functions.


That is not even the point of this discussion.

a.map!(a=>foo(a,b).map!(a=>2*a)())().days().ago().writeln()
Jan 23 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 00:45:02 +0100
Timon Gehr <timon.gehr gmx.ch> wrote:


 On 01/23/2013 11:46 PM, Nick Sabalausky wrote:

 On Wed, 23 Jan 2013 21:29:14 +0100
 Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:


 On 1/23/13, Adam D. Ruppe <destructionator gmail.com> wrote:

 On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote:
 Amen! -property MUST die.  property should fix the real problems
 with properties, not leave that broken while adding new problems.


 About  property problems, I've recently ran into this:
 ModuleInfo.unitTest is defined as

  property void function() unitTest() nothrow pure;

 And if I use it:

      foreach (m; ModuleInfo)
      {
          if (m is null)
              continue;

          if (auto fp = m.unitTest)
          {
              fp();           // calls it
              m.unitTest();   // doesn't call it
              m.unitTest()(); // calls it
          }
      }

 This is regardless of the -property switch. I would expect the
 second call to work. Anyone know if this is filed already?


 Don't know if it's filed, but yea: Optional empty-parens and
 the practice of conflating properties with functions is riddled with
 corner-cases. We can either try to patch over these corner cases
 with increasingly detailed new rules,


 
 What are those "new" rules? The rules we already have are sufficient. 
 Now the compiler needs to implement them properly.
 


Andrei was just suggesting this:

http://forum.dlang.org/post/kdpg5n$2qt2$1 digitalmars.com


 as Andrei is proposing, or we
 can just accept "the writing on the wall" (if you'll pardon my
 80's-ism) that properties != functions.


 
 That is not even the point of this discussion.
 
 a.map!(a=>foo(a,b).map!(a=>2*a)())().days().ago().writeln()
 


First of all, spacing helps:

a.map!( a => foo(a,b).map!(a=>2*a)() )().days().ago().writeln()

So does not trying to cram everything into a one-liner:

auto descriptiveName = a => foo(a,b).map!(a=>2*a)();
a.map!descriptiveName().days().ago().writeln()

And then there's a few () in there, but not only do I fail to see how
those hurt anybody, they make perfect sense since "days", "ago" and
"writeln" are not data access, they're actions (even if maybe a little
too cutely-named in the case of "ago").

(Of course, I'd question the meaningfulness and feasability of passing
the "days" type constructor a range instead of a scalar, but I get that
that's beside the point ;) )
Jan 23 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 10:02 PM, Nick Sabalausky wrote:

 First of all, spacing helps:

 a.map!( a =>  foo(a,b).map!(a=>2*a)() )().days().ago().writeln()

 So does not trying to cram everything into a one-liner:

 auto descriptiveName = a =>  foo(a,b).map!(a=>2*a)();
 a.map!descriptiveName().days().ago().writeln()

 And then there's a few () in there, but not only do I fail to see how
 those hurt anybody, they make perfect sense since "days", "ago" and
 "writeln" are not data access, they're actions (even if maybe a little
 too cutely-named in the case of "ago").


If you find this not wanting and not improvable we might have reached an 
irreducible position.

Andrei
Jan 23 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 01:33:29 Andrei Alexandrescu wrote:

 If you find this not wanting and not improvable we might have reached an
 irreducible position.


I think that it's been clear for some time that there's no way to please both 
the folks who want strong property enforcement and those who want weak 
property enforcement. One side is going to lose out, and much as I'm very much 
in favor strong property enforcement (and Nick clearly is as well), I think 
that it's fairly clear at this point that the majority of folks arond here are 
not (in great part due to UFCS). Not to mention, sorting out proper property 
enforcement has taken so long given all of the other priorities, that doing 
strong property enforcement would probably break quite a lot of code at this 
point.

- Jonathan M Davis
Jan 23 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 04:02 AM, Nick Sabalausky wrote:

 On Thu, 24 Jan 2013 00:45:02 +0100
 Timon Gehr <timon.gehr gmx.ch> wrote:


 On 01/23/2013 11:46 PM, Nick Sabalausky wrote:

 On Wed, 23 Jan 2013 21:29:14 +0100
 ...
 Don't know if it's filed, but yea: Optional empty-parens and
 the practice of conflating properties with functions is riddled with
 corner-cases. We can either try to patch over these corner cases
 with increasingly detailed new rules,


 What are those "new" rules? The rules we already have are sufficient.
 Now the compiler needs to implement them properly.


 Andrei was just suggesting this:

 http://forum.dlang.org/post/kdpg5n$2qt2$1 digitalmars.com


This rule is not new. Also, it is about  property.


 as Andrei is proposing, or we
 can just accept "the writing on the wall" (if you'll pardon my
 80's-ism) that properties != functions.


 That is not even the point of this discussion.

 a.map!(a=>foo(a,b).map!(a=>2*a)())().days().ago().writeln()


 First of all, spacing helps:


I do not see that. It just blows up the code even more.


 a.map!( a => foo(a,b).map!(a=>2*a)() )().days().ago().writeln()

 So does not trying to cram everything into a one-liner:

 auto descriptiveName = a => foo(a,b).map!(a=>2*a)();
 a.map!descriptiveName().days().ago().writeln()


This is not valid code.


 And then there's a few () in there, but not only do I fail to see how
 those hurt anybody, they make perfect sense since "days", "ago" and
 "writeln" are not data access, they're actions (even if maybe a little
 too cutely-named in the case of "ago").


There is no universal rule that says () has any relevance for this.

(Arguably, it does not make any sense to distinguish concepts like 'data 
access' and 'action' syntactically. What is this distinction anyway?)


 (Of course, I'd question the meaningfulness and feasability of passing
 the "days" type constructor a range instead of a scalar, but I get that
 that's beside the point ;) )


No, that is spot on. I didn't even notice, which is partly owed to the 
paren spam.
Jan 24 2013
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 January 2013 at 20:29:24 UTC, Andrej Mitrovic 
wrote:

 This is regardless of the -property switch. I would expect the 
 second call to work.


Indeed. I don't know if it is filed (I think I saw it mentioned 
on irc yesterday though, so it might be), but this is exactly why 
-property is so useless: it doesn't even solve the problem 
(exactly what you saw there!) that  property was supposed to 
address!

The current implementation ONLY checks syntax. That's completely 
backward: if we got the semantics right, the syntax of 
 properties would take care of itself.
Jan 23 2013
prev sibling parent reply "anonymous" <anonymous example.com> writes:
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 */
);
Jan 23 2013
parent "anonymous" <anonymous example.com> writes:
On Wednesday, 23 January 2013 at 22:07:20 UTC, anonymous wrote:

 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;}



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


Actually, this may be alright; have to be explicit with 
non-properties. Just don't apply that rule to UFCS.

Some more:

static assert(
    is(typeof( noprop(c)          )) /* of course */
&& is(typeof( prop(c)            )) /* should error */
);

void noprop(C, int);
 property void prop(C, int);

static assert(
    is(typeof( {c.noprop;}        )) /* fails with -property, 
should work, is explicit enough */
&& is(typeof( {c.prop;}          )) /* should error */

&& is(typeof( {c.noprop();}      )) /* ok */
&& is(typeof( {c.prop();}        )) /* should error */

&& is(typeof( {c.noprop(0);}     )) /* ok */
&& is(typeof( {c.prop(0);}       )) /* should error */

&& is(typeof( {c.noprop = 0;}    )) /* fails with -property, 
alright */
&& is(typeof( {c.prop = 0;}      )) /* ok */
);
Jan 23 2013
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
23-Jan-2013 21:13, Timon Gehr пишет:

 On 01/23/2013 06:03 PM, monarch_dodra wrote:

 ...

 Well, if you are compiling with "-property", the compiler forces you to
 ...


 So don't.


 AFAIK, the "-property" switch enforces that non-property functions use
 parenthesis, so removing an " property" attribute is potentially
 breaking. The opposite though is not so true. You can add  property to
 anything, and never break code.


 That is completely nonsensical behaviour. Just ignore -property.


+111

-- 
Dmitry Olshansky
Jan 23 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, January 23, 2013 18:03:19 monarch_dodra wrote:

 So I thought I'd discuss: Would there be a reason to not make dur
 a property? This should impact no-one, but make ufcs usage that
 much more convenient. Can I get the go-ahead to make and document
 the change?


No. It's not conceptually a property, so it shouldn't be marked with 
 property. It's a factory function.


 What about making things like msecs public aliases? How do you
 feel about that?


We have aliases already. If you don't like dur!"msecs"(100), you can do 
msecs(100). The same with days, minutes, etc.

- Jonathan M Davis
Jan 23 2013
next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 23 January 2013 at 18:02:05 UTC, Jonathan M Davis 
wrote:

 We have aliases already. If you don't like dur!"msecs"(100), 
 you can do
 msecs(100). The same with days, minutes, etc.

 - Jonathan M Davis


Hum. I guess I missed those. Thanks.
Jan 23 2013
prev sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 23 January 2013 at 18:02:05 UTC, Jonathan M Davis 
wrote:

 On Wednesday, January 23, 2013 18:03:19 monarch_dodra wrote:

 So I thought I'd discuss: Would there be a reason to not make 
 dur
 a property? This should impact no-one, but make ufcs usage that
 much more convenient. Can I get the go-ahead to make and 
 document
 the change?


 No. It's not conceptually a property, so it shouldn't be marked 
 with
  property. It's a factory function.


I agree. It's important we don't conflate properties with 
parentheses-less calling.  They are two separate things.

I want to be able to call without parentheses but we shouldn't 
abuse  property to accomplish it.

BA
Jan 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 18:03:19 +0100
"monarch_dodra" <monarchdodra gmail.com> wrote:


 I was using dur, and as powerful as it is, I *hate* typing:
 
 //----
 Thread.sleep(dur!"msecs"(100));
 //----
 


I completely agree. It's absolutely hideous. And the flexibility of
having the unit be a template param is only rarely useful. What we *do*
fortunately have is these:

msecs(100)
hours(12)
days(30)
etc...

But beyond that, unfortunately, it's all been discussed before, and the
guy in charge of std.datetime is very strongly opposed to such changes
and feels that 'dur!"msecs"(100)' is great-looking. It was a ridiculous
uphill battle just to get the aliases above approved and included, and
even then the phobos devs rejected the portions of the pull request that
cleaned up phobos's internal usages of "durrrr" with the
vastly cleaner aliases. Such code cleanup was deemed to be pointless
and something to be avoided.



 
 Well, if you are compiling with "-property", the compiler forces 
 you to type:
 //----
 Thread.sleep(100.msecs());
 //----
 
 It is *almost* the same thing, but actually not the same at all. 
 It shatters the "native" feeling of the suffix notation.


The behavior *without* -property turned out to be a broken idea and the
*with* -property was created as the new replacement, intended to
deprecate the old ultimately-flawed behavior. Although that was a long
time ago and there seems to be a lot of reluctance to finally make the
switch because even the admins who admitted the change was necessary
are big fans of the old behavior.

Apparently, there's some fear about breaking code by making -propery
the default *as was always intended*. But that potential breakage was
the whole damn reason for adding the switch in the first place, as a
transitional measure (which has now become what, about a two year
"transition"?). Nevermind that we've had bigger breakages since then
that didn't even have any transition period, and we got by just fine.
Jan 23 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-23 18:03, monarch_dodra wrote:

 I was using dur, and as powerful as it is, I *hate* typing:

 //----
 Thread.sleep(dur!"msecs"(100));
 //----

 Then, this reminded me of an older thread I started:
 Neat: UFCS for integer dot operator suffix
 http://forum.dlang.org/thread/uchcycnsvykuojzhuokh forum.dlang.org

 And then it struct me:
 //----
 Thread.sleep(100.dur!"msecs");
 //----

 Yay! Or even better:
 //----
 alias msecs = dur!"msecs"
 ...
 Thread.sleep(100.msecs); //Wow. Talk about expressive !!!


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.


 What about making things like msecs public aliases? How do you feel
 about that?


Go for it.

-- 
/Jacob Carlborg
Jan 23 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jan 23 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 23 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jan 23 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jan 23 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 22:53:45 +0100
Timon Gehr <timon.gehr gmx.ch> wrote:

 
 Likewise, there is no problem with 2.days.ago.
 
 Clock.currTime() - dur!"days"(2) is more verbose without being more
 clear.


*IMO*: The problem with that latter example is just (what I see as) some
unfortunate choices for naming and such. Alter it like this:

now() - days(2)

And I think that's no longer overly verbose, has great clarity, and
does so without feeling too cute or magical.

Of course, like I said before, I could live with 2.days.ago, but it's
not really what I'd prefer.
Jan 23 2013
prev sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
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?
Jan 23 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jan 23 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jan 23 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 23:19:17 +0100
"Adam D. Ruppe" <destructionator gmail.com> wrote:

 (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 think that shows how different editors or even just personal
typing styles can affect our coding style. For me, I'll do stuff like:

  str~isFoo?

  [Oops, that's right, I need parens around that '?:']

  <CTRL + (LEFT-ARROW x2)>
  (
  <END>
  )
  <LEFT-ARROW>

  [Now looks like: str~(isFoo?|)  <--pipe is cursor]

  trueCond:falseCond
  <END>

  [Now looks like: str~(isFoo?trueCond:falseCond)|  ]
  [Hmm, I want to writeln that...]

  <HOME>
  writeln(
  <END>
  );

  Final: writeln(str~(isFoo?trueCond:falseCond));

Probably not surprising that I avoid trying to code on anything but a
full-size keyboard with a proper section of <arrows, del, home, end,
pgup, pgdn>, because coding on, say, a laptop keyboard (even
one with a numpad) is a huge slowdown. I'd gladly give up the numberpad
on my laptop if I could get a standard arrows/home/end/etc section
instead, rather than the impractical "mini-keys in awkward faraway
places" they currently use for such keys.

Heh, actually, case in point, take a look at my normal work setup:

http://66.228.38.161/download/img/jobs-would-have-hung-employees-for-doing-this.jpg

(Yes, I need to get a wireless keyboard/trackball ;) )


 
 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.


Geez, we still don't have that?
Jan 23 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-24 06:16, Nick Sabalausky wrote:


 Heh, actually, case in point, take a look at my normal work setup:

 http://66.228.38.161/download/img/jobs-would-have-hung-employees-for-doing-this.jpg

 (Yes, I need to get a wireless keyboard/trackball ;) )


That's not a good work setup, in any way. Close the laptop and get a 
real, external monitor, or two. I'm serious, you're going to break your 
neck, sooner or later.


 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.


 Geez, we still don't have that?


No we don't :( That's also one reason why a public fields cannot be 
changed to a property without breaking the API, see: 
http://forum.dlang.org/thread/ceukykobasewoexsrveb forum.dlang.org?page=8#post-kdqs3u:2414i1:241:40digitalmars.com

-- 
/Jacob Carlborg
Jan 24 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 09:47:32 +0100
Jacob Carlborg <doob me.com> wrote:


 On 2013-01-24 06:16, Nick Sabalausky wrote:
 

 Heh, actually, case in point, take a look at my normal work setup:

 http://66.228.38.161/download/img/jobs-would-have-hung-employees-for-doing-this.jpg

 (Yes, I need to get a wireless keyboard/trackball ;) )


 
 That's not a good work setup, in any way. Close the laptop and get a 
 real, external monitor, or two.


I do, just not hooked up ATM. Been meaning to.
Jan 24 2013
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 January 2013 at 05:16:32 UTC, Nick Sabalausky 
wrote:

 I think that shows how different editors or even just personal
 typing styles can affect our coding style. For me, I'll do 
 stuff like:



Aye, I think this applies to my non-caring about identifier name 
length too - I use tab completion in my editor.

I've tried some of those auto parens things, and it just confuses 
me. I guess I could get used to it (I recently started playing 
one of those newer shooter games. I come from Perfect Dark on the 
N64, so I'm used to what Halo called "legacy controls". The new 
controls were totally unusable to me.... but I was forced to 
stick with it for a while and now kinda am ok. I just hope it 
hasn't ruined my aptitude at PD controls! Perfect Dark is still 
the best shooter ever.).

But still, it isn't that big of a deal, my way works very well 
99.9% of the time.



 Probably not surprising that I avoid trying to code on anything 
 but a full-size keyboard with a proper section of <arrows, del,
 home, end, pgup, pgdn>, because coding on, say, a laptop
 keyboard (even one with a numpad) is a huge slowdown.


Yeah, I spend some time on a laptop (a little 12" one too) and it 
isn't as nice as the real keyboard, but I got one with a decent 
key placement and remapped some of the keys to fit the muscle 
memory anyway, so it isn't that bad.

The worst thing about my laptop keyboard is the 9 key doesn't 
work right and needs extra force. Since that's also (, ugh! But 
I'm cheap so whatever.


 Heh, actually, case in point, take a look at my normal work 
 setup:


lol, I got one of those ipads as a gift last year. I found it 
totally useless except for the angry birds and watching some 
video streams, i.e. not work at all.

But, I wanted a computer in my other room last week. My laptop is 
never at home, so I looked into buying something.

And my decision was sure to be painful to Steve Jobs: I bought an 
off brand usb thingy for the pad, and a full sized (Microsoft 
brand LOL) keyboard. Combined with an ssh app for the pad thingy 
(death to lowercase i), it became almost useful.

So I was only in for $20 and now have a halfway usable portable 
computer. No mouse though. Yes arrow keys (thank god, the morons 
at Apple refuse to put them in, which makes this thing utterly 
useless for anything other than their small set of sanctioned 
activities. OK, that apparently serves millions of people and 
turns an enormous profit, but that doesn't matter to /me/!). But, 
surprisingly, no to home and end!

Maybe it is just mapped wrong though, I haven't looked into the 
details.


Still though, 3/4 of a real keyboard is lightyears beyond the 
touch nonsense, and the price for the hack beat the crap out of 
buying a real computer.


 Geez, we still don't have that?


We spend too much time arguing over optional parenthesis!
Jan 24 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 14:37:28 +0100
"Adam D. Ruppe" <destructionator gmail.com> wrote:


 On Thursday, 24 January 2013 at 05:16:32 UTC, Nick Sabalausky 
 wrote:

 I think that shows how different editors or even just personal
 typing styles can affect our coding style. For me, I'll do 
 stuff like:


 
 
 Aye, I think this applies to my non-caring about identifier name 
 length too - I use tab completion in my editor.
 


I tend to do a lot of copy/paste for symbol names. Maybe not as good as
auto-complete, but with either of these (depending on the situation
and my whims):

1. Up/Down/Ctrl-Left/Ctrl-Right/Home/End to line/word-skip to one end of
ident
2. Shift-Ctrl-(Left or Right) to select ident
3. Ctrl-C (copy)
4. Up/Down/Ctrl-Left/Ctrl-Right/Home/End to line/word-skip to target
5. Ctrl-V (paste)
6. Goto 4 if needed

(Less frequent, but nicer for long distances or if my hand is already
on the mouse):
1. Right hand: Double-click ident
2. Left hand: Ctrl-C (copy)
3. Right hand: Click target
4. Left hand: Ctrl-V (paste)
5. Goto 3 if needed

Been doing both long enough that muscle memory makes either of
them quick, natural operations. Ctrl-Arrow and Home/End are fucking
awesome :)

Anyway, point being, with either of those, longer idents don't bother
me much either (unless it gets the the point where line lengths for
simple things get too long, or I can't distinguish between the idents
without reading them).


 I've tried some of those auto parens things, and it just confuses 
 me.


They're not my thing either. Same thing for when they auto-indent big
checks of code (I can do that myself with Shift-Ctrl-Up/Down and then
Tab). It certainly *could* be helpful for some, but I don't like when
the editor tries to anticipate my typing style and changes things around
while I'm typing. It's like having someone reach over my shoulder while
I'm working and "help out" by banging on the keyboard uninvited
without them having any idea what my muscle memory, habits and concious
intent are just about to make me type.

I do very much like having <Enter> copy the same indentation of the
previous line into the newly-inserted line, but that's about it.


 I guess I could get used to it (I recently started playing 
 one of those newer shooter games. I come from Perfect Dark on the 
 N64, so I'm used to what Halo called "legacy controls". The new 
 controls were totally unusable to me.... but I was forced to 
 stick with it for a while and now kinda am ok. I just hope it 
 hasn't ruined my aptitude at PD controls! Perfect Dark is still 
 the best shooter ever.).


Yea, those "Halo" controls are usually just called "Dual Analog"
first-person controls. I think they're an abomination compared to
having a *real* pointing device, like a mouse/trackball or Wii's IR
pointing (Yea, the Wii's gesture recognition is crap as everyone says,
*but* the IR pointing works great and is a killer feature IMO). But when
I'm playing some first-person game that won't let me use a real pointing
device (ex: most PS3 first-persons, all XBox1 first-persons) then I've
always found the dual-analog to at least be a huge improvement over the
older single-analog designs.

But the notable exception for me is Metroid Prime: The single-analog
controls in 1 and 2 worked great for that game, and 3's IR-pointing
was botched and crappy - I hated it. Red Steel 1 and Call of Duty 3 did
IR pointing the *right* way, even though I never liked Call of Duty 3
overall, and Red Steel's controls *did* turn shitty during the
unfortunate sword battles.

But you're right, Perfect Dark *is* a great game. :)



 Heh, actually, case in point, take a look at my normal work 
 setup:


 
 lol, I got one of those ipads as a gift last year. I found it 
 totally useless except for the angry birds and watching some 
 video streams, i.e. not work at all.
 


Yea. For work, I spent most of 2012 in possession of a loaner iPhone 4
(and some Android thing). I got the urge to hurl it into the nearest
concrete wall every time I used it. I don't think there was a single
thing about it I liked. At the end, packaging it up to send back felt
like Christmas morning :)

Angry Birds gets a lot of flack for, I guess, being a bit too popular
and overly-marketed. But thing about it though, is it's pretty much the
only phone/tablet game out there that *isn't* total crap. (And the
"In Space" one is actually quite good.) All the other games on those
devices either have those completely unusable "soft gamepad"
abominations, or just simply have extremely minimal gameplay. And most
of them are just clones of each other.

I do kinda want to get a WiFi-only Android thingamadoo though. Not
because I like it (I don't - it was clearly designed by people who
considered the iPhone to be perfection), but only because I could use a
new camera and a WiFi-connected PDA, and PalmOS is unfortunately dead
and therefore no longer an option.


 But, I wanted a computer in my other room last week. My laptop is 
 never at home, so I looked into buying something.
 
 And my decision was sure to be painful to Steve Jobs: I bought an 
 off brand usb thingy for the pad, and a full sized (Microsoft 
 brand LOL) keyboard. Combined with an ssh app for the pad thingy 
 (death to lowercase i), it became almost useful.
 


Heh, yea. Having ultra-mobile SSH is pretty damn cool. Part of why I
want a new PDA.


 So I was only in for $20 and now have a halfway usable portable 
 computer. No mouse though. Yes arrow keys (thank god, the morons 
 at Apple refuse to put them in, which makes this thing utterly 
 useless for anything other than their small set of sanctioned 
 activities. OK, that apparently serves millions of people and 
 turns an enormous profit, but that doesn't matter to /me/!). But, 
 surprisingly, no to home and end!
 


/me nods head in total agreeance.

Manufacturers figure "Ehh, *most* people don't use them and we don't
give a shit about the rest, so let's just throw them away." Which is
going to lead to a need to start seeing special "Programmer Keyboards"
in the US like other countries have. Of course, these will probably end
up being as expensive as the rip-off "Gamer Keyboards" that are out
there.

In computers, companies have actually managed to turn "knowing what
you're doing" into a liability.


 Still though, 3/4 of a real keyboard is lightyears beyond the 
 touch nonsense,


Oh absolutely.

More like "non-touch" though. It's absolutely insane that these
companies toss around the word "touch" like crazy despite the clear
fact that they're systematically *eliminating* any and all touch
sensation, they're not adding one damn bit of touch. Thay're *not*
"touch", they're very much *anti*-touch. Idiots.


 and the price for the hack beat the crap out of 
 buying a real computer.
 


Not if you didn't already have the iPad. Those things are expensive. I
got my laptop last spring (with dual-core, 64-bit, 4GB RAM, 320GB
HDD, USB 3, HDMI/VGA-out, DVD burning, Intel HD graphics which is
actually quite capable for many games, not that I needed that), for
only $340. Add in a few cheap accessories from MicroCenter (by far the
best computer store I've ever found - as long as you ignore the
salesmen), and I think it came out pretty well.

Still not nearly as portable as a netbook, and I *hate* the 16:9
screen that's become the ONLY option (unless you want one of those
completely moronic 2.x:1 screens that some companies actually offer) but
hey, beats the old desktop, and a damn better price than the ~$2000
that was typical for a decent portable 12/13 years ago when I'd bought
my first laptop (I'd made sure to splurge for the active-matrix
screen ;) ).

Speaking of, what's a good Linux for laptops these days? I'm anxious
to get rid of this horrid Win7 that was preinstalled (XP is genuinely
a possible option for me). Most of my recent Linux experience is
debian-based ((Ku/U)buntu a few years back and Debian 6 more recently).
I'm planning to give Mint a test drive in a VM. Is that any good for
laptops, or is "laptop" a non-issue for linux these days?



 Geez, we still don't have that?


 
 We spend too much time arguing over optional parenthesis!


Heh :)

Honestly, I'm *really* surprised that I didn't notice the continued lack
of += on properties. Must have gotten used to avoiding it or something,
I guess? I dunno.
Jan 24 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 22:59:38 +0100
"monarch_dodra" <monarchdodra gmail.com> wrote:

 
 --------
 IMO: We should be able to keep the optional parenthesis for all 
 functions (except maybe those that return delegates).


I'm not a fan of that as I think the need for special-casing of
functions returning delegates is not worth what I still don't see as a
benefit.

Side note: I know at least one person here likes this [ ;) ], but I
really hate code like:

foo.doStuff;
foo.makeFizzBar;
foo.updateBlorg;

Have to do a double-take every time. Just looks like a bunch of
no-ops, and sets off mental red flags every single time.


 Things that 
 are marked as property, however, MUST respect two things:
 1) properties should *NEVER* have parentheses.


Agreed


 2) you should not be able to take the address of a property 
 function.


Agreed

One could argue that you should be able to take the address of a
property, just like any other function, and to end up with a delegate.
But if you need to do that you can just use a lambda. It may be an
extra function call and indirection, but that's optimizable out, right?
That way you get to eat your delegate cake and still have no accedental
surprises arising from "&foo.bar" being an unexpected type.



 3) The "a.prop = value" should call "a.prop(value)" IFF prop is 
 declared property.
 


Agreed

I would also add:

4) Setters must be called like "a.prop = value", never "a.prop(value)"

5) Finally get rid of the damn -property switch (or maybe just make it
a no-op for build script backwards-compatibility, at least for a few
releases)
Jan 23 2013
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 24 January 2013 at 04:00:44 UTC, Nick Sabalausky 
wrote:

 On Wed, 23 Jan 2013 22:59:38 +0100
 "monarch_dodra" <monarchdodra gmail.com> wrote:

 
 --------
 IMO: We should be able to keep the optional parenthesis for 
 all functions (except maybe those that return delegates).


 I'm not a fan of that as I think the need for special-casing of
 functions returning delegates is not worth what I still don't 
 see as a
 benefit.

 Side note: I know at least one person here likes this [ ;) ], 
 but I
 really hate code like:

 foo.doStuff;
 foo.makeFizzBar;
 foo.updateBlorg;

 Have to do a double-take every time. Just looks like a bunch of
 no-ops, and sets off mental red flags every single time.


 Things that are marked as property, however, MUST respect two 
 things:
 1) properties should *NEVER* have parentheses.


 Agreed


The irony here though is that "-property" enforces the opposite 
:/ (non-properties always have parens...)
Jan 23 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, January 24, 2013 07:20:22 monarch_dodra wrote:

 The irony here though is that "-property" enforces the opposite
 
 :/ (non-properties always have parens...)


-property is thoroughly broken. It was supposed to do strong property 
enforcement (never parens with properties and always parens with functions), 
but it doesn't. But not only does it not do strong enforcement right, it 
doesn't even do weak enforcement right, as weak enforcment would mean 
enforcing that property functions don't get called with parens but functions 
could be called either way. And of course it's buggy in how well it even 
enforces the part that it's currently trying to enforce.

Given the increasing sentiment against strong property enforcement (due in 
large part to UFCS), I'd expect that what we'll ultimately end up with is weak 
property enforcement, but -property obviously doesn't help with that at all. 
Much as I'd love to have strong property enforcement, -property really doesn't 
help us much at this point.

- Jonathan M Davis
Jan 23 2013
prev sibling next sibling parent reply "Tommi" <tommitissari hotmail.com> writes:
I've always secretly hated the ambiguity in D's syntax. E.g:

foo.bar

What could foo and bar be? D has many more answers than C++:

                     D           C++
                     foo bar     foo bar
Module/Namespace    x   x
Type                x   x
Variable            x   x       x   x
Method                  x
Free function       x   x

For this reason I initially agreed with Nick Sabalausky on 
disallowing calling non-property functions without parenthesis.

...but now I'm thinking that this ambiguity stops being an issue 
once we have an IDE that can render different things in different 
colors (or different fonts or with other visual cues if you're 
color-blind). Color is a much stronger and faster visual cue than 
having parenthesis at the end of a name. For this reason, I think 
that it's fine to allow non-property functions to be called 
without parenthesis. But I still think that property functions 
should not be allowed to be called with parenthesis.
Jan 24 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 3:38 AM, Tommi wrote:

 I've always secretly hated the ambiguity in D's syntax. E.g:

 foo.bar

 What could foo and bar be? D has many more answers than C++:

 D C++
 foo bar foo bar
 Module/Namespace x x
 Type x x
 Variable x x x x
 Method x
 Free function x x


Nah, C++ has also namespace, inner classes and function-local classes... 
lookup and resolution are actually more complicated than D.

Andrei
Jan 24 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 16:27:02 UTC, Andrei Alexandrescu 
wrote:

 On 1/24/13 3:38 AM, Tommi wrote:

 I've always secretly hated the ambiguity in D's syntax. E.g:

 foo.bar

 What could foo and bar be? D has many more answers than C++:

 D C++
 foo bar foo bar
 Module/Namespace x x
 Type x x
 Variable x x x x
 Method x
 Free function x x


 Nah, C++ has also namespace, inner classes and function-local 
 classes... lookup and resolution are actually more complicated 
 than D.


No. C++ has no forward references, no UFCS, and no way to 
introduce new symbols during semantic analysis.

C++ is an horrible beast, but on the identifier side, D is far 
worse.
Jan 24 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/24/13 11:32 AM, deadalnix wrote:

 On Thursday, 24 January 2013 at 16:27:02 UTC, Andrei Alexandrescu wrote:

 On 1/24/13 3:38 AM, Tommi wrote:

 I've always secretly hated the ambiguity in D's syntax. E.g:

 foo.bar

 What could foo and bar be? D has many more answers than C++:

 D C++
 foo bar foo bar
 Module/Namespace x x
 Type x x
 Variable x x x x
 Method x
 Free function x x


 Nah, C++ has also namespace, inner classes and function-local
 classes... lookup and resolution are actually more complicated than D.


 No. C++ has no forward references, no UFCS, and no way to introduce new
 symbols during semantic analysis.

 C++ is an horrible beast, but on the identifier side, D is far worse.


Well if D is worse, should we give up on forward references, UFCS, or 
mixins?

Andrei
Jan 24 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 07:12 PM, Andrei Alexandrescu wrote:

 On 1/24/13 11:32 AM, deadalnix wrote:

 On Thursday, 24 January 2013 at 16:27:02 UTC, Andrei Alexandrescu wrote:

 On 1/24/13 3:38 AM, Tommi wrote:

 I've always secretly hated the ambiguity in D's syntax. E.g:

 foo.bar

 What could foo and bar be? D has many more answers than C++:

 D C++
 foo bar foo bar
 Module/Namespace x x
 Type x x
 Variable x x x x
 Method x
 Free function x x


 Nah, C++ has also namespace, inner classes and function-local
 classes... lookup and resolution are actually more complicated than D.


 No. C++ has no forward references, no UFCS, and no way to introduce new
 symbols during semantic analysis.

 C++ is an horrible beast, but on the identifier side, D is far worse.


 Well if D is worse, should we give up on forward references, UFCS, or
 mixins?

 Andrei


Also, static if and 'is' expressions.
No, but we must specify and implement a sophisticated evaluation model 
of compile-time code evaluation, introspection, and generation 
constructs. DMD gets it wrong. Semantics of code, or whether it is 
accepted may depend on the order modules are passed on the command line.
I'll release what I have got so far later in spring.
Jan 24 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 18:12:22 UTC, Andrei Alexandrescu 
wrote:

 Well if D is worse, should we give up on forward references, 
 UFCS, or mixins?


No, I don't think we should drop them. I'm just mentioning that 
identifier resolution in harder in D than in C++ , but never said 
that identifier resolution should be easy.
Jan 24 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-24 17:27, Andrei Alexandrescu wrote:


 Nah, C++ has also namespace, inner classes and function-local classes...
 lookup and resolution are actually more complicated than D.


A namespace in C++ would be using a double colon, not a dot.

-- 
/Jacob Carlborg
Jan 24 2013
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-00-24 05:01, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  
wrote:


 On Wed, 23 Jan 2013 22:59:38 +0100
 "monarch_dodra" <monarchdodra gmail.com> wrote:

 --------
 IMO: We should be able to keep the optional parenthesis for all
 functions (except maybe those that return delegates).


 I'm not a fan of that as I think the need for special-casing of
 functions returning delegates is not worth what I still don't see as a
 benefit.

 Side note: I know at least one person here likes this [ ;) ], but I
 really hate code like:

 foo.doStuff;
 foo.makeFizzBar;
 foo.updateBlorg;

 Have to do a double-take every time. Just looks like a bunch of
 no-ops, and sets off mental red flags every single time.


Amen!

I do understand Adam's view that foo.bar(10).baz(5) be allowed,
but that could be written with(foo){bar=10;baz=5}. Admittedly more
verbose, but also clearer.


particularly because they could allow for immediate creation of many
const and immutable values.

-- 
Simen
Jan 24 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-23 22:59, monarch_dodra wrote:


 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".


It's for a method emulating being a field/public instance variable.


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


You cannot do this in D. There are at least two issues:

1. You cannot replace a non-final property, i.e. a method, with a field. 
Someone might have overridden the method in a subclass. In other 
languages like Scala a public instance variable is implemented as a 
method. In these cases you can switch freely between a property and an 
instance variable.

2. There are some issues with fields of a struct type being changed to a 
property, since they are usually passed by value. Example:

struct Bar
{
     int a;
}

class Foo
{
     Bar bar;
}

void main ()
{
     auto foo = new Foo;
     foo.bar.a = 1;
     assert(foo.bar.a == 1);
}

Changing Foo.bar to be a porperty like this:

class Foo
{
     Bar bar_;

      property Bar bar ()
     {
         return bar_;
     }

      property Bar bar (Bar bar)
     {
         return bar_ = bar;
     }
}

Now the assertion in main won't pass since the property is returning a 
value type that is copied. If you instead return by reference it will 
work, but then you can also set "bar" directly, bypassing the setter.

For this to work properly we would need property rewrite:

foo.bar.a = 1;

Should be turned into:

auto _tmp = foo.bar();
_tmp.a = 1;
foo.bar(_tmp);

-- 
/Jacob Carlborg
Jan 24 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 24 January 2013 at 08:41:34 UTC, Jacob Carlborg 
wrote:

 On 2013-01-23 22:59, monarch_dodra wrote:


 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".


 It's for a method emulating being a field/public instance 
 variable.


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


 You cannot do this in D. There are at least two issues:

 1. You cannot replace a non-final property, i.e. a method, with 
 a field. Someone might have overridden the method in a 
 subclass. In other languages like Scala a public instance 
 variable is implemented as a method. In these cases you can 
 switch freely between a property and an instance variable.


Ture, it *is* a one way street, but would at least be a street 
none the less.

Imagine you used to have a field in the base class "myInt", but 
now you need a virtual myInt. You can replace your field with a 
virtual property that returns by ref. Your old code:

//----
int* p = &myClass.myInt;
//----

Will still work, but the actual field will be resolved at 
runtime. This does require my "point 2" to be implemented though: 
You can't take the address of a property.

If "myInt" was implemented as a simple function, here, you'd end 
up taking the address of the function myInt, and break code.


 2. There are some issues with fields of a struct type being 
 changed to a property, since they are usually passed by value. 
 Example:


They shouldn't have to. That'd be an interface change. If you do 
that, then breakage is inevitable, property or no.


 If you instead return by reference it will work, but then you 
 can also set "bar" directly, bypassing the setter.


I think this is a limitation. If bar is a property, and has a 
setter, then "bar = 5" should *always* call the setter, 
regardless of ref or not.

IMO, it not currently doing so is a limitation
Jan 24 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-24 10:11, monarch_dodra wrote:


 IMO, it not currently doing so is a limitation


Yes, that's what I'm saying. You cannot swap properties and fields willy 
nilly using the current implementation.

-- 
/Jacob Carlborg
Jan 24 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 21:54:54 +0100
Jacob Carlborg <doob me.com> 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. But if you
 do:
 
 auto t = ago(days(2));
 
 It's backwards[...]


I'll certainly grant that, insofar as the written order is backwards
from the execution order. I think the "ago" is that part that bugs me
the most. It's too clever. I could live with "2.days", but I'd prefer
"days(2)" since that looks like a type constructor, and "days" isn't a
property of 2. Maybe "2.toDays()", but at that point I'd still rather
just do the simpler "days(2)".
Jan 23 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-24 00:16, Nick Sabalausky wrote:


 I'll certainly grant that, insofar as the written order is backwards
 from the execution order. I think the "ago" is that part that bugs me
 the most. It's too clever. I could live with "2.days", but I'd prefer
 "days(2)" since that looks like a type constructor, and "days" isn't a
 property of 2. Maybe "2.toDays()", but at that point I'd still rather
 just do the simpler "days(2)".


If you don't have "ago" how would you determine the differences compared 
to the opposite, which looks like this in Ruby on Rails:

time = 2.days.from_now

"2" is the duration, "days" is the unit and ago/from_now indicates if 
it's positive or negative.

-- 
/Jacob Carlborg
Jan 24 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 24 Jan 2013 09:52:38 +0100
Jacob Carlborg <doob me.com> wrote:


 On 2013-01-24 00:16, Nick Sabalausky wrote:
 

 I'll certainly grant that, insofar as the written order is backwards
 from the execution order. I think the "ago" is that part that bugs
 me the most. It's too clever. I could live with "2.days", but I'd
 prefer "days(2)" since that looks like a type constructor, and
 "days" isn't a property of 2. Maybe "2.toDays()", but at that point
 I'd still rather just do the simpler "days(2)".


 
 If you don't have "ago" how would you determine the differences
 compared to the opposite,


now - blah vs. now + blah


 which looks like this in Ruby on Rails:
 
 time = 2.days.from_now
 
 "2" is the duration, "days" is the unit and ago/from_now indicates if 
 it's positive or negative.
Jan 24 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/24/2013 10:52 AM, Nick Sabalausky wrote:

 now - blah vs. now + blah


Now we have caught you.
Jan 24 2013
prev sibling next sibling parent Mike Wey <mike-wey example.com> writes:
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
Jan 23 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 23 Jan 2013 21:33:07 +0100
Jacob Carlborg <doob me.com> wrote:

 
 This is how it should look like. Date ranges in Ruby on Rails can be 
 really beautiful:
 
 date = 2.days.ago
 


Honestly, I really don't like that. It trades clear semantics for a
bunch of magic to achieve the dubious goal of making code look more
like English (a notably high-ambiguity language). If I valued languages
imitating English, I'd be doing everything in HyperCard or COBOL or
some other such design blunder.
Jan 23 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-24 00:07, Nick Sabalausky wrote:


 Honestly, I really don't like that. It trades clear semantics for a
 bunch of magic to achieve the dubious goal of making code look more
 like English (a notably high-ambiguity language). If I valued languages
 imitating English, I'd be doing everything in HyperCard or COBOL or
 some other such design blunder.


That's unclear with the semantics?

-- 
/Jacob Carlborg
Jan 24 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
24-Jan-2013 12:53, Jacob Carlborg пишет:

 On 2013-01-24 00:07, Nick Sabalausky wrote:


 Honestly, I really don't like that. It trades clear semantics for a
 bunch of magic to achieve the dubious goal of making code look more
 like English (a notably high-ambiguity language). If I valued languages
 imitating English, I'd be doing everything in HyperCard or COBOL or
 some other such design blunder.


 That's unclear with the semantics?


+1
It's crystal clear, and the less noise the better IMO.

-- 
Dmitry Olshansky
Jan 24 2013