Jump to page: 1 24  
Page
Thread overview
ufcs and integer params
Jul 14, 2012
Jay Norwood
Jul 15, 2012
Jay Norwood
Jul 15, 2012
Jonathan M Davis
Jul 15, 2012
Timon Gehr
Jul 15, 2012
Jonathan M Davis
Jul 15, 2012
Timon Gehr
Jul 15, 2012
Jonathan M Davis
Jul 15, 2012
Timon Gehr
Jul 15, 2012
Jonathan M Davis
Jul 15, 2012
Timon Gehr
Jul 15, 2012
Jonathan M Davis
Jul 15, 2012
Timon Gehr
Jul 15, 2012
Jonathan M Davis
Jul 15, 2012
Timon Gehr
Jul 15, 2012
Jonathan M Davis
Jul 15, 2012
Timon Gehr
Jul 16, 2012
Jacob Carlborg
Jul 16, 2012
Chris NS
Jul 16, 2012
Timon Gehr
Jul 16, 2012
Adam D. Ruppe
Jul 18, 2012
David Nadlinger
Jul 18, 2012
Adam D. Ruppe
Jul 18, 2012
David Nadlinger
Jul 19, 2012
Brad Roberts
Jul 19, 2012
Adam D. Ruppe
Jul 17, 2012
Chris NS
Jul 16, 2012
Jacob Carlborg
Jul 16, 2012
Jacob Carlborg
Jul 15, 2012
Philippe Sigaud
Jul 18, 2012
Marco Leise
Jul 18, 2012
David Nadlinger
Jul 20, 2012
Philippe Sigaud
Jul 20, 2012
David Nadlinger
Jul 21, 2012
Philippe Sigaud
July 14, 2012
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
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
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
> 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
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
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
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
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
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
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