View mode: basic / threaded / horizontal-split · Log in · Help
July 14, 2012
ufcs and integer params
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
July 15, 2012
Re: ufcs and integer params
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
July 15, 2012
Re: ufcs and integer params
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
July 15, 2012
Re: ufcs and integer params
> 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
July 15, 2012
Re: ufcs and integer params
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'?
July 15, 2012
Re: ufcs and integer params
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
July 15, 2012
Re: ufcs and integer params
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
July 15, 2012
Re: ufcs and integer params
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.
July 15, 2012
Re: ufcs and integer params
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
July 15, 2012
Re: ufcs and integer params
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.
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home