January 30, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rob T | On 2013-01-30 00:55, Rob T wrote: > Given how D currently works, I don't see how we can realistically > implement a function as a drop in replacement for a variable and expect > code to continue working as if nothing had changed. > > One of the bigger problems is that the getter returns by value, not ref, > so everything that expects a ref return will fail. > > I expect to make precise variable emulation through properties will > require a lot of compiler magic, and there will be inevitable bugs and > conflicts that follow. I really don't see that there's enough value with > the property concept to justify the costs of precise variable emulation. > > You know a lot more about implementing compiler magic than I do, so I'll > ask you if you think the effort is doable enough to justify having > property functions that can act like a drop in replacement for existing > variables? Implement this: struct Foo { @property int a; } Lowered to: struct Foo { private int a_; @property int a () { return a_; } @property int a (int value) { return a_ = value; } } -- /Jacob Carlborg |
January 30, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to TommiT | On 2013-01-30 02:40, TommiT wrote: > I always thought that having public member variables is a bad style of > programming because of the lack of encapsulation. So, if there's a > language feature that enables you to write public member variables, and > later on, replace them with property functions, wouldn't that mean that > the language is encouraging this particular kind of bad style of > programming? I really don't see much point in properties/methods that just forwards to an instance variable. -- /Jacob Carlborg |
January 30, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rob T | On 2013-01-30 03:15, Rob T wrote: > Even with @property restrictions, I still don't think it will work as > expected. For example, if the variable is a struct, then you have to > disallow operations on the struct from outside. > > Example: > > struct Y { int a; } > > struct X{ @property Y y; } > > X x; > > x.y.a = 4; // <- this has to be illegal! > > Reason? > > struct X{ > > Y _y; > > @property Y y{ return _y; } > > } > > // this won't change _y as it did before. > x.y.a = 4; That would require some property rewrite by the compiler. -- /Jacob Carlborg |
January 30, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On 1/30/13 10:10 AM, Jacob Carlborg wrote:
> On 2013-01-30 02:40, TommiT wrote:
>
>> I always thought that having public member variables is a bad style of
>> programming because of the lack of encapsulation. So, if there's a
>> language feature that enables you to write public member variables, and
>> later on, replace them with property functions, wouldn't that mean that
>> the language is encouraging this particular kind of bad style of
>> programming?
>
> I really don't see much point in properties/methods that just forwards
> to an instance variable.
Insurance.
Andrei
|
January 30, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Wednesday, 30 January 2013 at 15:10:37 UTC, Jacob Carlborg wrote:
> I really don't see much point in properties/methods that just forwards to an instance variable.
I assume you mean something like this:
struct S
{
private T _t;
ref T get() { return _t; }
void set(T t) { ... }
}
The benefit of the above type of coding versus having a public T variable, is that you can change the implementation of S without changing S's interface. Perhaps I would like to change it to this (or whatever):
private static T[5] tees;
struct S
{
private byte _idx;
ref T get() { return tees[_idx]; }
void set(T t) { ... }
}
|
January 30, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 01/30/2013 03:29 AM, Jonathan M Davis wrote:
> ... C# manages it ...
Nope.
|
January 30, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Wednesday, January 30, 2013 18:54:20 Timon Gehr wrote:
> On 01/30/2013 03:29 AM, Jonathan M Davis wrote:
> > ... C# manages it ...
>
> Nope.
It was my understanding that it did. Everything that I've read on it indicated that it did. But I have used C# minimally (and not recently), so I could easily be wrong when it comes to much of anything about C#.
- Jonathan M Davis
|
January 30, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 01/30/2013 08:44 PM, Jonathan M Davis wrote:
> On Wednesday, January 30, 2013 18:54:20 Timon Gehr wrote:
>> On 01/30/2013 03:29 AM, Jonathan M Davis wrote:
>>> ... C# manages it ...
>>
>> Nope.
>
> It was my understanding that it did. Everything that I've read on it indicated
> that it did. But I have used C# minimally (and not recently), so I could
> easily be wrong when it comes to much of anything about C#.
>
> - Jonathan M Davis
>
(C# has ref parameters. Properties cannot be passed by ref, but public fields can.)
|
January 30, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to TommiT | On 2013-01-30 17:26, TommiT wrote: > I assume you mean something like this: > > struct S > { > private T _t; > > ref T get() { return _t; } > > void set(T t) { ... } > } > > The benefit of the above type of coding versus having a public T > variable, is that you can change the implementation of S without > changing S's interface. Perhaps I would like to change it to this (or > whatever): > > private static T[5] tees; > > struct S > { > private byte _idx; > > ref T get() { return tees[_idx]; } > > void set(T t) { ... } > } Sure, but I think that's what properties are for. We currently don't have that in D but I think it would be great if fields could be exchanged with methods without breaking the API. -- /Jacob Carlborg |
January 30, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 2013-01-30 20:44, Jonathan M Davis wrote: > It was my understanding that it did. Everything that I've read on it indicated > that it did. But I have used C# minimally (and not recently), so I could > easily be wrong when it comes to much of anything about C#. Last time I used C# it didn't have property rewrite when returning structs. -- /Jacob Carlborg |
Copyright © 1999-2021 by the D Language Foundation