www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - ufcs and integer params

reply "Jay Norwood" <jayn prismnet.com> writes:
I was looking at the xtend example 4 Distances  here, and see 
that their new generation capability includes ability to do 3.cm 
10.mm , and these result in calls to cm(3) and mm(10).

  http://blog.efftinge.de/



I see that similar capability was discussed for D previously at 
the link below.  How was this issue resolved for D?

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=97661
Jul 14 2012
parent reply "Jay Norwood" <jayn prismnet.com> writes:
I see from this other discussions that it looks like 2.059 ( or 
maybe 2.060) does support something like 3.cm().   Not sure from 
the discussion if it would also accept 3.cm as in the xtext/xtend 
example.

http://forum.dlang.org/thread/smoniukqfxerutqrjshf forum.dlang.org
Jul 14 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:

 I see from this other discussions that it looks like 2.059 ( or
 maybe 2.060) does support something like 3.cm().   Not sure from
 the discussion if it would also accept 3.cm as in the xtext/xtend
 example.
 
 http://forum.dlang.org/thread/smoniukqfxerutqrjshf forum.dlang.org


UFCS (universal function call syntax) was added in 2.059. If cm is a function, 
then 3.cm() will work. If it's a property function, then 3.cm will work. If 
you don't compile with -property, then 3.cm will still work with cm being a 
non-property function, but -property will become the normal behavior 
eventually, so you shouldn't expect that 3.cm will work long term unless cm is 
a property function.

- Jonathan M Davis
Jul 14 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 05:40 AM, Jonathan M Davis wrote:

 On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:

 I see from this other discussions that it looks like 2.059 ( or
 maybe 2.060) does support something like 3.cm().   Not sure from
 the discussion if it would also accept 3.cm as in the xtext/xtend
 example.

 http://forum.dlang.org/thread/smoniukqfxerutqrjshf forum.dlang.org


 UFCS (universal function call syntax) was added in 2.059. If cm is a function,
 then 3.cm() will work. If it's a property function, then 3.cm will work. If
 you don't compile with -property, then 3.cm will still work with cm being a
 non-property function, but -property will become the normal behavior
 eventually,  so you shouldn't expect that 3.cm will work long term unless cm is
 a property function.


I expect it to stay.

Another reason why  property-'enforcement' is flawed:

 property auto cm(int arg){ .. }

cm=2;   // ok
2.cm;   // ok

The two code snippets would in fact be equivalent.
What is enforced here? Why would it matter if anything is 'enforced'?
Jul 15 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 19:50:18 Timon Gehr wrote:

 On 07/15/2012 05:40 AM, Jonathan M Davis wrote:

 On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:

 I see from this other discussions that it looks like 2.059 ( or
 maybe 2.060) does support something like 3.cm().   Not sure from
 the discussion if it would also accept 3.cm as in the xtext/xtend
 example.
 
 http://forum.dlang.org/thread/smoniukqfxerutqrjshf forum.dlang.org


 
 UFCS (universal function call syntax) was added in 2.059. If cm is a
 function, then 3.cm() will work. If it's a property function, then 3.cm
 will work. If you don't compile with -property, then 3.cm will still work
 with cm being a non-property function, but -property will become the
 normal behavior eventually,  so you shouldn't expect that 3.cm will work
 long term unless cm is a property function.


 
 I expect it to stay.
 
 Another reason why  property-'enforcement' is flawed:
 
  property auto cm(int arg){ .. }
 
 cm=2;   // ok
 2.cm;   // ok
 
 The two code snippets would in fact be equivalent.


 property isn't perfect, and I admit that the fact that both cm = 2 and 2.cm 
works here is undesirable, given what's trying to be done here, but it makes 
sense given that it's abstracting a variable. It's just undesirable that you 
can't make it so that it functions only as a getter. But the overall situation 
is still a whale of a lot better than the laxity of letting just any function 
be called with or without parens depending no what each particular programmer 
feels like doing with it. If it's a property, it should be treated as such, 
and if it isn't, it shouldn't.


 What is enforced here? Why would it matter if anything is 'enforced'?


If you marked it as a property, then it's supposed to be abstracting a 
variable and should be treated as one, just like if it's a normal function, it 
should be invoked as a function, just like ++ shouldn't suddenly do --, and / 
shouldn't *.

I don't want to get into this argument again. The current plan is (and has 
been for some time) that -property will become the normal behavior, and there  
have been no indications that that's going to change. I know that you don't 
like it, but some of us think that it's a major improvement, even if the 
result isn't perfect. The only way that it's going to change is if Walter 
changes his mind.

- Jonathan M Davis
Jul 15 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 08:56 PM, Jonathan M Davis wrote:

 On Sunday, July 15, 2012 19:50:18 Timon Gehr wrote:

 On 07/15/2012 05:40 AM, Jonathan M Davis wrote:

 On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:

 I see from this other discussions that it looks like 2.059 ( or
 maybe 2.060) does support something like 3.cm().   Not sure from
 the discussion if it would also accept 3.cm as in the xtext/xtend
 example.

 http://forum.dlang.org/thread/smoniukqfxerutqrjshf forum.dlang.org


 UFCS (universal function call syntax) was added in 2.059. If cm is a
 function, then 3.cm() will work. If it's a property function, then 3.cm
 will work. If you don't compile with -property, then 3.cm will still work
 with cm being a non-property function, but -property will become the
 normal behavior eventually,  so you shouldn't expect that 3.cm will work
 long term unless cm is a property function.


 I expect it to stay.

 Another reason why  property-'enforcement' is flawed:

  property auto cm(int arg){ .. }

 cm=2;   // ok
 2.cm;   // ok

 The two code snippets would in fact be equivalent.


  property isn't perfect, and I admit that the fact that both cm = 2 and 2.cm
 works here is undesirable, given what's trying to be done here, but it makes
 sense given that it's abstracting a variable. It's just undesirable that you
 can't make it so that it functions only as a getter.


cm=2 is in fact a getter call. I don't mind this, because I don't need 
to write that code if I don't want to. The 'puritanical' view is simply
incompatible with how the whole thing is laid out.


 But the overall situation
 is still a whale of a lot better than the laxity of letting just any function
 be called with or without parens depending no what each particular programmer
 feels like doing with it. If it's a property, it should be treated as such,
 and if it isn't, it shouldn't.


 What is enforced here? Why would it matter if anything is 'enforced'?


 If you marked it as a property, then it's supposed to be abstracting a
 variable and should be treated as one, just like if it's a normal function, it
 should be invoked as a function,


This seems to be tautological. But what this statement presumably
really meant to say was 'it should be invoked as a function using the
notation present in eg. C or Java'.


 just like ++ shouldn't suddenly do --, and / shouldn't *.


That depends entirely on the domain of these functions.


 I don't want to get into this argument again.


Yah, we have gone through this before.


 The current plan is (and has been for some time)
 that -property will become the normal behavior,


It is obvious that -property is broken and will not become the normal 
behaviour.
Jul 15 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 23:29:04 Timon Gehr wrote:

 The current plan is (and has been for some time)
 that -property will become the normal behavior,


 
 It is obvious that -property is broken and will not become the normal
 behaviour.


It is obvious that -property needs to be fixed before it becomes the normal 
behavior. It is _not_ obvious that it will not become the normal behavior. The 
-property flag was created explicitly so that its implementation could be fixed 
_before_ making it the normal behavior and so that programmers had time to fix 
their code before it become enforced.

- Jonathan M Davis
Jul 15 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 11:35 PM, Jonathan M Davis wrote:

 On Sunday, July 15, 2012 23:29:04 Timon Gehr wrote:

 The current plan is (and has been for some time)
 that -property will become the normal behavior,


 It is obvious that -property is broken and will not become the normal
 behaviour.


 It is obvious that -property needs to be fixed before it becomes the normal
 behavior. It is _not_ obvious that it will not become the normal behavior. The
 -property flag was created explicitly so that its implementation could be fixed
 _before_ making it the normal behavior and so that programmers had time to fix
 their code before it become enforced.

 - Jonathan M Davis


I'd say the -property switch is there to make the fruitless
bikeshedding discussions about  property disappear. Nothing else makes
sense. Its inclusion obviously has been rushed (the error message does 
not even follow English grammar) and it _only_ implements the one
restriction that does not objectively matter.
Jul 15 2012
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 11:56:57 Jonathan M Davis wrote:

 What is enforced here? Why would it matter if anything is 'enforced'?


 
 If you marked it as a property, then it's supposed to be abstracting a
 variable and should be treated as one, just like if it's a normal function,
 it should be invoked as a function, just like ++ shouldn't suddenly do --,
 and / shouldn't *.


And on a purely objective note, if you don't have property enforcement, you 
can't turn a property function into a variable, because even though it's 
supposed to be used as one, you can't guarantee that everyone's using it that 
way, and if they're using it as a function, changing the property into a 
variable will break their code. And part of the point of properties is to be 
able to switch between variables and property functions depending on whether 
additional protections or calculations or whatnot are required for that 
variable/property. Property enforcement is required in order to allow that.

- Jonathan M Davis
Jul 15 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 09:41 PM, Jonathan M Davis wrote:

 On Sunday, July 15, 2012 11:56:57 Jonathan M Davis wrote:

 What is enforced here? Why would it matter if anything is 'enforced'?


 If you marked it as a property, then it's supposed to be abstracting a
 variable and should be treated as one, just like if it's a normal function,
 it should be invoked as a function, just like ++ shouldn't suddenly do --,
 and / shouldn't *.


 And on a purely objective note, if you don't have property enforcement, you
 can't turn a property function into a variable, because even though it's
 supposed to be used as one, you can't guarantee that everyone's using it that
 way,  and if they're using it as a function, changing the property into a
 variable will break their code.  And part of the point of properties is to be
 able to switch between variables and property functions depending on whether
 additional protections or calculations or whatnot are required for that
 variable/property. Property enforcement is required in order to allow that.

 - Jonathan M Davis


No it is not, assuming that property enforcement is supposed to mean
that function 'foo' cannot be called like 'foo' if it is not annotated
 property.

There is no objective argument for banning this, except that the syntax
would be made free for alternative use.

 property means: always implicitly call if it can be called without
arguments. If it cannot, disallow calls that are not of the form fun = 
argument; (After the op= operators have been properly rewritten.)

And that is completely sufficient for transparently switching between
variable/property. Stuff that is *not* annotated  property has no
relevance.
Jul 15 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 22:47:41 Timon Gehr wrote:

 On 07/15/2012 09:41 PM, Jonathan M Davis wrote:

 On Sunday, July 15, 2012 11:56:57 Jonathan M Davis wrote:

 What is enforced here? Why would it matter if anything is 'enforced'?


 
 If you marked it as a property, then it's supposed to be abstracting a
 variable and should be treated as one, just like if it's a normal
 function,
 it should be invoked as a function, just like ++ shouldn't suddenly do
 --,
 and / shouldn't *.


 
 And on a purely objective note, if you don't have property enforcement,
 you
 can't turn a property function into a variable, because even though it's
 supposed to be used as one, you can't guarantee that everyone's using it
 that way,  and if they're using it as a function, changing the property
 into a variable will break their code.  And part of the point of
 properties is to be able to switch between variables and property
 functions depending on whether additional protections or calculations or
 whatnot are required for that variable/property. Property enforcement is
 required in order to allow that.
 
 - Jonathan M Davis


 
 No it is not, assuming that property enforcement is supposed to mean
 that function 'foo' cannot be called like 'foo' if it is not annotated
  property.
 
 There is no objective argument for banning this, except that the syntax
 would be made free for alternative use.
 
  property means: always implicitly call if it can be called without
 arguments. If it cannot, disallow calls that are not of the form fun =
 argument; (After the op= operators have been properly rewritten.)
 
 And that is completely sufficient for transparently switching between
 variable/property. Stuff that is *not* annotated  property has no
 relevance.


There are two levels to enforcement. Neither exist without -property. The 
absolutely minimal level is that anything marked with  property must be used 
as a property. Without this, you can't swap out a property function for a 
variable without breaking code.

The second level - i.e. strict property enforcement - also requires that non-
property functions be called as functions.

-property is supposed to be doing strict property enforcement, but it's pretty 
buggy at the moment, so you can't really use it to guarantee much yet.

- Jonathan m Davis
Jul 15 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 11:11 PM, Jonathan M Davis wrote:

 There are two levels to enforcement. Neither exist without -property. The
 absolutely minimal level is that anything marked with  property must be used
 as a property.  Without this, you can't swap out a property function for a
 variable without breaking code.


If it means what I think it means then that should be done and this is
where -property fails.


 The second level - i.e. strict property enforcement - also requires that non-
 property functions be called as functions.


Exactly. This part is useless.

(The 'Without this, you can't...' part is notably missing.)
Jul 15 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:

 The second level - i.e. strict property enforcement - also requires that
 non- property functions be called as functions.


 
 Exactly. This part is useless.


And there, we will forever disagree.

- Jonathan M Davis
Jul 15 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 11:43 PM, Jonathan M Davis wrote:

 On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:

 The second level - i.e. strict property enforcement - also requires that
 non- property functions be called as functions.


 Exactly. This part is useless.


 And there, we will forever disagree.


If it is a matter of personal preference, then it shouldn't be in the 
compiler.
Jul 15 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 23:47:58 Timon Gehr wrote:

 On 07/15/2012 11:43 PM, Jonathan M Davis wrote:

 On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:

 The second level - i.e. strict property enforcement - also requires that
 non- property functions be called as functions.


 
 Exactly. This part is useless.


 
 And there, we will forever disagree.


 
 If it is a matter of personal preference, then it shouldn't be in the
 compiler.


It's a matter of enforcing the correct syntax, which the compiler does all the 
time. It's just that you don't think that the compiler should care in this 
particular case, since it hasn't cared in the past.

- Jonathan M Davis
Jul 15 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 11:56 PM, Jonathan M Davis wrote:

 On Sunday, July 15, 2012 23:47:58 Timon Gehr wrote:

 On 07/15/2012 11:43 PM, Jonathan M Davis wrote:

 On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:

 The second level - i.e. strict property enforcement - also requires that
 non- property functions be called as functions.


 Exactly. This part is useless.


 And there, we will forever disagree.


 If it is a matter of personal preference, then it shouldn't be in the
 compiler.


 It's a matter of enforcing the correct syntax,


This post seems to attempt to distract from the fact that the topic of 
the discussion is which syntax is correct.


 which the compiler does all the
 time. It's just that you don't think that the compiler should care in this
 particular case, since it hasn't cared in the past.


The compiler does not and has never 'not cared'. It has to do slightly 
more work. This is a designed language feature, although it's a trivial
one. eg. Eiffel and Scala have the same thing.

The prime reason why I think it is beneficial if no more restrictions
than necessary are applied is UFCS:

array(map!(x=>2*x)(range));   // should be fine

range.map!(x=>2*x).array;     // so should this

range.map!(x=>2*x)().array(); // who needs this?
Jul 15 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-07-16 00:33, Timon Gehr wrote:


 This post seems to attempt to distract from the fact that the topic of
 the discussion is which syntax is correct.


 which the compiler does all the
 time. It's just that you don't think that the compiler should care in
 this
 particular case, since it hasn't cared in the past.


 The compiler does not and has never 'not cared'. It has to do slightly
 more work. This is a designed language feature, although it's a trivial
 one. eg. Eiffel and Scala have the same thing.

 The prime reason why I think it is beneficial if no more restrictions
 than necessary are applied is UFCS:

 array(map!(x=>2*x)(range));   // should be fine

 range.map!(x=>2*x).array;     // so should this

 range.map!(x=>2*x)().array(); // who needs this?


Exactly.

-- 
/Jacob Carlborg
Jul 15 2012
prev sibling parent reply "Chris NS" <ibisbasenji gmail.com> writes:
Having been around long enough to remember when the ability to 
call "foo()" as "foo" first appeared, I feel it necessary to 
point out that this was *not* in fact a deliberate design, but 
rather a sort of "accident" that arose out of D's first attempt 
at properties.  It was the same "accident" loaded compiler 
release that gave us pseudo-members -- the precursors to UFCS.

The community discovered that these things were accepted by the 
compiler -- which was actually against the language spec at the 
time -- and further that the resulting code did the intuitively 
correct thing.  Response to the "accidents" being generally 
positive, it was decided to work toward making them legitimate 
language features.  Some flavor of  property (or of a certain 

that camp) has been in the plan ever since.

I find the ongoing debate/discussion of  property and -property 
to be... well, moot.  But hey, I'm just one crazy among an army 
of crazies.

-- Chris NS
Jul 16 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/16/2012 10:55 AM, Chris NS wrote:

 Having been around long enough to remember when the ability to call
 "foo()" as "foo" first appeared, I feel it necessary to point out that
 this was *not* in fact a deliberate design, but rather a sort of
 "accident" that arose out of D's first attempt at properties.


Afaik this first attempt was implemented roughly as designed. It is my
understanding that  property was added later in order to fix the
introduced ambiguities.


 It was the same "accident" loaded compiler release that gave us pseudo-members
--
 the precursors to UFCS.


I still wonder how that could possibly happen.


 The community discovered that these things were accepted by the compiler
 -- which was actually against the language spec at the time -- and
 further that the resulting code did the intuitively correct thing.
 Response to the "accidents" being generally positive, it was decided to
 work toward making them legitimate language features. Some flavor of

 properties... I was in that camp)


That would certainly be more pretty -- OTOH it is hard to think of a
way to extend this to UFCS that is as natural as what happens if
everything is conflated in functions.


 has been in the plan ever since.

 I find the ongoing debate/discussion of  property and -property to be...
 well, moot. But hey, I'm just one crazy among an army of crazies.


Well, this newsgroup has the property that the stuff that is actually
important is usually unilaterally agreed upon rather quickly. :o)
Jul 16 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
I'm another who is /vehemently/ against the utter
idiocy that is the -property switch.

I wonder: if we had another poll, a recall election
if you will, how many people who said "yes" the
first time would change their minds now?

I betcha it'd be quite a few.
Jul 16 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Monday, 16 July 2012 at 23:18:10 UTC, Adam D. Ruppe wrote:

 I'm another who is /vehemently/ against the utter
 idiocy that is the -property switch.


Arguments! Yay!
Jul 18 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 18 July 2012 at 11:37:43 UTC, David Nadlinger wrote:

 Arguments! Yay!


I've gone over this a dozen times on the group and on
bugzilla, and I'm kinda sick of repeating it.

-property breaks craploads of code. That's a huge negative,
and nobody has even come close to countering that.

"-property will be the standard" is utterly worthless, yet
that's really the only thing I see brought up again.

The other most common thing is "I don't like how writeln = 10
looks". Easy response: then don't write that.

If you're going to break code because someone might write
something you find ugly - note this is different than the 
arguments
people like Crockford make about, say, Javascript's ==, which he 
argues
is a bug 95% of the time you see it, this is just "I don't like 
how
that looks".

But if we're going to let the possibility for subjective ugliness
be justification for BREAKING CODE, I can't stress that enough,
we might as well just nuke the whole language.



BTW, a common fallacy I also here is bringing up the edge cases
like returning a delegate in a property. Two points:

1) That has *nothing* to do with syntax. The  property decoration
takes care of that, regardless of syntax. Why do we have to
break a common case to fix an edge case.... especially when
we /can/ have our cake and eat it too?

2) -property doesn't even get that right anyway. Not kidding,
try it. -property might as well be renamed -break-my-code-and-
give-me-ABSOLUTELY-NOTHING-in-return.

Why, why would we ever consent to having that standard?
Jul 18 2012
next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 18 July 2012 at 12:30:46 UTC, Adam D. Ruppe wrote:

 2) -property doesn't even get that right anyway. Not kidding,
 try it. -property might as well be renamed -break-my-code-and-
 give-me-ABSOLUTELY-NOTHING-in-return.

 Why, why would we ever consent to having that standard?


I actually tend to agree with this part – I see -property more 
like an experiment help determining the behavior we want to make 
the default with real-world testing. We should definitely try to 
fix/improve the implementation of -property before we consider to 
make it the default. But without it, the discussion might have 
never gotten to the point where we are now, so I still consider 
it a success.

David
Jul 18 2012
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 7/18/2012 5:30 AM, Adam D. Ruppe wrote:

 On Wednesday, 18 July 2012 at 11:37:43 UTC, David Nadlinger wrote:

 Arguments! Yay!


 
 I've gone over this a dozen times on the group and on
 bugzilla, and I'm kinda sick of repeating it.
 
 -property breaks craploads of code. That's a huge negative,
 and nobody has even come close to countering that.
 
 "-property will be the standard" is utterly worthless, yet
 that's really the only thing I see brought up again.


The clear argument for me is that it must be trivial to take an existing member
variable and change it to a property
function pair _and vice versa_.  If someone has  property int foo() and
 property void foo(int) as members of a class
and call sites add (), then yanking those back to just int foo; will fail,
badly.  So that must be explicitly disallowed.

THAT is the argument for enforcing the lack of parens after properties, imho. 
The other bits about non- property
functions is significantly less important as far as I'm concerned.

My 2 cents,
Brad
Jul 18 2012
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 19 July 2012 at 02:57:05 UTC, Brad Roberts wrote:

 The clear argument for me is that it must be trivial to take an 
 existing member variable and change it to a property
 function pair _and vice versa_.


I can see some value in that.


 The other bits about non- property
 functions is significantly less important as far as I'm 
 concerned.



Question to everybody: how would you feel about this
compromise: the strictness is opt in.

So, if you don't use  property, you get the status quo.
These functions can be called either way, but if there's
ambiguity, it tends toward treating them as a function.

If you do use  property, it becomes strict.


This would cover your concerns while keeping the
dual-syntax benefits, and it minimizes code breakage
of existing stuff.


It'd also discourage a lot of the questions of to  property
or not to  property, since you can just ask "is it a real
property" without falsely marking stuff for UFCS chaining or
whatever. It'd save me a lot of headaches on my range.empty's
too.




If we switch to this compromise position, I'm about 98%
sure I'd vote yes (would have to actually try it to be certain).
Jul 18 2012
prev sibling parent "Chris NS" <ibisbasenji gmail.com> writes:
On Monday, 16 July 2012 at 23:13:54 UTC, Timon Gehr wrote:

 On 07/16/2012 10:55 AM, Chris NS wrote:

 Having been around long enough to remember when the ability to 
 call
 "foo()" as "foo" first appeared, I feel it necessary to point 
 out that
 this was *not* in fact a deliberate design, but rather a sort 
 of
 "accident" that arose out of D's first attempt at properties.


 Afaik this first attempt was implemented roughly as designed. 
 It is my
 understanding that  property was added later in order to fix the
 introduced ambiguities.


Effectively yes, this is why I put "accident" in quotes.  The 
accidental part was that it was inadvertently extended to 
functions that it should not have been.  Free functions, for 
example, were not really supposed to be callable in that way... 
it has turned out to sometimes be a nice and useful thing, of 
course, but it wasn't exactly the goal at the time.  The goal was 
simply class/struct/union member functions that could be swapped 
out for exposed fields, or vice versa, without any change in user 
code.


 It was the same "accident" loaded compiler release that gave 
 us pseudo-members --
 the precursors to UFCS.


 I still wonder how that could possibly happen.


You, me, and everyone else.  I recall even Walter being a bit 
surprised by it and reviewing his code afterward.  The oddity was 
identified, but at the same time (almost-) everyone rather liked 
it and it stuck.  At the time I was maintaining an extensive 
library of array extensions, a spiritual ancestor to today's 
std.algorithm and std.range.  (None of that code is in Phobos, 
mind you, but it served a similar purpose.)  It was sort of like 
finding a peppermint in an old coat pocket.


 The community discovered that these things were accepted by 
 the compiler
 -- which was actually against the language spec at the time -- 
 and
 further that the resulting code did the intuitively correct 
 thing.
 Response to the "accidents" being generally positive, it was 
 decided to
 work toward making them legitimate language features. Some 
 flavor of
  property (or of a certain other proposal which was a mimicry 

 properties... I was in that camp)


 That would certainly be more pretty -- OTOH it is hard to think 
 of a
 way to extend this to UFCS that is as natural as what happens if
 everything is conflated in functions.


As I recall, that was essentially how the discussion went back 

 property to be plenty usable, and even admittedly a bet more 
terse.


 has been in the plan ever since.

 I find the ongoing debate/discussion of  property and 
 -property to be...
 well, moot. But hey, I'm just one crazy among an army of 
 crazies.


 Well, this newsgroup has the property that the stuff that is 
 actually
 important is usually unilaterally agreed upon rather quickly. 
 :o)


Yeah... usually.  ;)  I rarely speak up anymore, since I just 
don't have the time to commit to proving concepts and whatnot 
anymore.  "I'm old, Dean.  So very old."  I remember proposing a 
foreach statement (opApply was Walter's idea, though).  I also 
remember the horror that was the 'instance' keyword... man do I 
ever love that beautiful !() operator now, no matter what anyone 
else says about it.  Ultimately, I am quite satisfied with it 
all, even if the occasional dead horse takes a beating.  I just 
find it strange that there's such heated debate over something 
that had seemed so settled.  Which, I suppose, might just be an 
indicator that it isn't settled after all, eh?

-- Chris NS
Jul 16 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-07-15 23:56, Jonathan M Davis wrote:


 It's a matter of enforcing the correct syntax, which the compiler does all the
 time. It's just that you don't think that the compiler should care in this
 particular case, since it hasn't cared in the past.


No, it's a matter of _what_ the correct syntax is.

Just as both of these are legal:

if (true)
     writeln(true);

if (true)
{
     writeln(true);
}

Both of these could be legal as well:

void foo ();

foo();
foo;

There are several other languages where the parentheses are optional: 
Ruby, Scala and CoffeeScript to mention a few.

-- 
/Jacob Carlborg
Jul 15 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-07-15 21:41, Jonathan M Davis wrote:


 And on a purely objective note, if you don't have property enforcement, you
 can't turn a property function into a variable, because even though it's
 supposed to be used as one, you can't guarantee that everyone's using it that
 way, and if they're using it as a function, changing the property into a
 variable will break their code. And part of the point of properties is to be
 able to switch between variables and property functions depending on whether
 additional protections or calculations or whatnot are required for that
 variable/property. Property enforcement is required in order to allow that.


Due to various other reasons this is still not possible.

* You cannot turn a virtual method into a variable
* For some type of variables you cannot change the variable into a 
method. We would need some kind of property rewrite

-- 
/Jacob Carlborg
Jul 15 2012
prev sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
 On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:

 I see from this other discussions that it looks like 2.059 ( or
 maybe 2.060) does support something like 3.cm().   Not sure from
 the discussion if it would also accept 3.cm as in the xtext/xtend
 example.




Hi Jay,

I had a little fun with coding a units (SI units) system in D and pushed an
incomplete version on Github a few weeks ago:

https://github.com/PhilippeSigaud/Units

It allows things like:

auto distance = 100.km;
auto speed = 120.km/hour;

auto timeToDestination = distance/speed; // timeToDest is a time (seconds)

The version on Github is grossly limited (it's just a sketch), but it gives
an idea of what's possible. My goal is to code a generic unit system
generator, given user inputs such as a list of units and sub-units.

cheers,

Philippe
Jul 15 2012
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 15 Jul 2012 19:17:11 +0200
schrieb Philippe Sigaud <philippe.sigaud gmail.com>:


 On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:

 I see from this other discussions that it looks like 2.059 ( or
 maybe 2.060) does support something like 3.cm().   Not sure from
 the discussion if it would also accept 3.cm as in the xtext/xtend
 example.




 
 Hi Jay,
 
 I had a little fun with coding a units (SI units) system in D and pushed an
 incomplete version on Github a few weeks ago:
 
 https://github.com/PhilippeSigaud/Units
 
 It allows things like:
 
 auto distance = 100.km;
 auto speed = 120.km/hour;
 
 auto timeToDestination = distance/speed; // timeToDest is a time (seconds)
 
 The version on Github is grossly limited (it's just a sketch), but it gives
 an idea of what's possible. My goal is to code a generic unit system
 generator, given user inputs such as a list of units and sub-units.
 
 cheers,
 
 Philippe


Sounds fun. I mean, it makes me happy to see code written like this instead of
Distance distance = new Kilometers(100);
Speed speed = Speed.fromDistanceByTime(new Kilometers(120), new Hours(1));

:D

-- 
Marco
Jul 18 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 18 July 2012 at 07:30:10 UTC, Marco Leise wrote:

 Am Sun, 15 Jul 2012 19:17:11 +0200
 schrieb Philippe Sigaud <philippe.sigaud gmail.com>:

 […]
 auto distance = 100.km;
 auto speed = 120.km/hour;
 
 auto timeToDestination = distance/speed; // timeToDest is a 
 time (seconds)
 
 The version on Github is grossly limited (it's just a sketch), 
 but it gives
 an idea of what's possible. My goal is to code a generic unit 
 system
 generator, given user inputs such as a list of units and 
 sub-units.
 
 […]


 Sounds fun. I mean, it makes me happy to see code written like 
 this instead of
 Distance distance = new Kilometers(100);
 Speed speed = Speed.fromDistanceByTime(new Kilometers(120), new 
 Hours(1));


I find multiplication to read much more natural:
---
enum km = kilo * meter;

auto distance = 100.0 * km;
auto speed = 100.0 * km / hour;

auto timeToDest = distance / speed;
---

See http://klickverbot.at/code/units/ for a slightly neglected 
implementation of this scheme. It supports stuff like defining 
new units with arbitrary (potentially runtime) conversion 
factors, properly typechecked affine units (think degrees 
celsius), etc. – but any error messages and symbol names will 
probably look like if the compiler had a seizure.

David
Jul 18 2012
parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
Marco:


 auto distance =3D 100.km;
 auto speed =3D 120.km/hour;







 Sounds fun. I mean, it makes me happy to see code written like this




instead of

 Distance distance =3D new Kilometers(100);
 Speed speed =3D Speed.fromDistanceByTime(new Kilometers(120), new




Hours(1));

Yeah, that was exactly one of my goals :)

David:


 I find multiplication to read much more natural:
 ---
 enum km =3D kilo * meter;

 auto distance =3D 100.0 * km;
 auto speed =3D 100.0 * km / hour;

 auto timeToDest =3D distance / speed;
 ---


This is good too. I have code that autogenerate the SI-prefixed versions
(not on Github, I should clean it and push), but thought about offering
prefix functions by themselves. Hmm, looking at it, I guess kilo is just
1000 as an enum in your code? That's a good idea.

Anyway, multiplication is good, I just looked for an excuse to play with
UFCS :)


 See http://klickverbot.at/code/units/ for a slightly neglected


implementation of this scheme. It supports stuff like defining new units
with arbitrary (potentially runtime) conversion factors, properly
typechecked affine units (think degrees celsius), etc.

Ah good. I remembered someone posting something on units-checking, but
couldn't find the message. I also have something on celsius/kelvin and
wondered if I needed to go beyond affine, to fully generalize the concept.

Btw, is =C2=B0C substraction authorized with your module, or multiplication=
? I
wondered what to forbid and what to authorize.

And I (re)discovered while browsing Wikipedia the numerous temperature
units I saw at school 15 years ago :)


 =E2=80=93 but any error messages and symbol names will probably look like=


 if the
compiler had a seizure.

why?
Jul 20 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Friday, 20 July 2012 at 12:28:52 UTC, Philippe Sigaud wrote:

 Hmm, looking at it, I guess kilo is just
 1000 as an enum in your code? That's a good idea.


Sorry, that should have been »kilo!gram«. It actually creates a 
new unit with a conversion factor of 1000 relative to the base 
unit (well, it does a few more things to handle cases like 
kilo!(milli!meter)), with the point being that the quantities are 
actually stored in memory "verbatim", i.e. without being 
normalized to e.g. SI units. Making »kilo * gram« work would be 
easy, but I decided it could lead to confusing situations.

David
Jul 20 2012
parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
 Sorry, that should have been =C2=BBkilo!gram=C2=AB. It actually creates a=


 new unit

 with tbua conversion factor of 1000 relative to the base unit (well, it d=


oes a

 few more things to handle cases like kilo!(milli!meter)), with the point
 being that the quantities are actually stored in memory "verbatim", i.e.
 without being normalized to e.g. SI units. Making =C2=BBkilo * gram=C2=AB=


 work would

 be easy, but I decided it could lead to confusing situations.


At one time, I wanted to make kilo a factory function that would do
the same transformation as your kilo!gram (that is, kilo(milli(gramm))
would in fact return a gram), but I found the style to be too
different from the rest of the code (with value.kg and such).

Btw, how do you handle the fact that in SI, the mass unit is the
kilogram and not the gram?
Jul 20 2012