Make dur a property?

[monarch_dodra]

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