Thread overview | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jay Norwood | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jay Norwood | 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 | ||||
---|---|---|---|---|
| ||||
Attachments:
| > 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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. |
Copyright © 1999-2021 by the D Language Foundation