On Wednesday, 30 January 2013 at 00:26:11 UTC, q66 wrote:
> It deeply disturbs me that people even take the original post seriously.

That said, obviously, propreties should be implemented in the library using opDot, with std.property implementing several property-handling policies and abstracted away in some kind of OO interface with inheritance to implement custom ones. That's gonna be awesome. Don't you think?

On Wednesday, 30 January 2013 at 00:25:41 UTC, Jonathan M Davis wrote:
>
> I believe that two main things are needed:
>
> 1. Make it possible to mark a variable such that you can't do anything with it
> that you couldn't do with a property function (e.g. taking its address needs
> to be illegal).
>
> 2. Add property rewrites to make it so that stuff like ++ and += work.
>
> You'll never get a property function to operate 100% like a variable, but you
> _can_ make it so that it's very close.. C# gets away with making variables and
> property functions swappable because it do stuff like let you take the address
> of a variable or a function. We basically need to do the same by restricting
> variables which are properties and improving the rewrites that the compile
> does for property functions.
>
> - Jonathan M Davis

I agree partial emulation can work, and I see you've pointed out that the usage of a property will have to be restricted so that it can work, but this means you have to mark your naked variables as @property ahead of time, otherwise you'll discover that you cannot replace a naked variable with a property without doing plenty of re-work.

Given that we won't be able to drop in a property without rework unless preplanned ahead of time, I'm not so sure we'll be gaining anything new here with specially marked properties, and even if we could drop them in, I'm still not sure it's a big gain.

I can see some value I suppose if you can mark a naked variable as @property because you know it will likely be wrapped into a function call later but don't want to implement the wrappers immediately, but I don't know if that's something a lot of people really need or care that much about.

I find the discussion we're having in another thread on the possibility of using a struct-like implementation for gaining property-like behaviors much more compelling a change for D because it extends D with interesting ways to implement variables and functions that can be used in more generalized situations AND it solves the property implementation issues too (in similar "restricted" ways as you've suggested can be done).

See last few posts ...
http://forum.dlang.org/thread/kdukid$stg$1@digitalmars.com

If we can not only implement @property as hoped for, but also get more expressive language features introduced along with it, then it may be something worth doing.

--rt

On Wed, Jan 30, 2013 at 01:58:16AM +0100, Rob T wrote: [...]
> I agree partial emulation can work, and I see you've pointed out that the usage of a property will have to be restricted so that it can work, but this means you have to mark your naked variables as @property ahead of time, otherwise you'll discover that you cannot replace a naked variable with a property without doing plenty of re-work.
[...]

Why do you have to mark naked variables as @property? Isn't that redundant?

As for using struct to implement @property, I like the idea, but it does raise tricky issues about how struct methods reference the parent lexical scope. I don't think it's as simple as just rewriting 'this' to point to the outer scope instead, because it breaks language expectations that 'this' should refer to the immediately-containing struct/class. There's bound to be corner cases that will break because of this. Consider, for example, what happens if the inner struct's methods need to call opAssign of the parent struct for whatever reason.

There's also the consideration of what happens if you take the address of the 'pseudo' variable: the inner struct would then be effectively dissociated from the parent struct, and you'll need that hidden context pointer (along with its gotchas) in order to have things still work as before.


T

-- 
The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst

On Wednesday, 30 January 2013 at 01:09:12 UTC, H. S. Teoh wrote:
> As for using struct to implement @property, I like the idea, but it does
> raise tricky issues about how struct methods reference the parent
> lexical scope. I don't think it's as simple as just rewriting 'this' to
> point to the outer scope instead, because it breaks language
> expectations that 'this' should refer to the immediately-containing
> struct/class. There's bound to be corner cases that will break because
> of this. Consider, for example, what happens if the inner struct's
> methods need to call opAssign of the parent struct for whatever reason.

outer.this
outer.opAssign

> There's also the consideration of what happens if you take the address
> of the 'pseudo' variable: the inner struct would then be effectively
> dissociated from the parent struct, and you'll need that hidden context
> pointer (along with its gotchas) in order to have things still work as
> before.

Compiler detects a struct which holds no data of its own and disallows taking its address.

On Tuesday, January 29, 2013 17:06:32 H. S. Teoh wrote:
> Why do you have to mark naked variables as @property? Isn't that redundant?

In order to restrict what you can do with it to the subset of operations that you can do with a property function. In particular, taking its address would need to be illegal, as that won't work with a property function (or if it did, it would return a different type). It would be impossible to replace a normal variable with a property function without risking breaking code, because there are operations that you can normally do on a variable that couldn't possibly be implemented with a function (such as taking its address). But if you mark it to restrict what it can do, then you could swap it out with a function later without the risk of breaking code (which is one of the main reasons for having properties in the first place). @property doesn't currently do this, but it could, and if we don't have something like that, then it'll never be safe to swap variables and property functions.

- Jonathan M Davis

On Wednesday, 30 January 2013 at 01:20:39 UTC, Zach the Mystic wrote:
> On Wednesday, 30 January 2013 at 01:09:12 UTC, H. S. Teoh wrote:
>> There's also the consideration of what happens if you take the address
>> of the 'pseudo' variable: the inner struct would then be effectively
>> dissociated from the parent struct, and you'll need that hidden context
>> pointer (along with its gotchas) in order to have things still work as
>> before.
>
> Compiler detects a struct which holds no data of its own and disallows taking its address.

Actually, you're right. I see no overloading of the address operator in the documentation. I doubt it's an insurmountable problem, though. opAddress?

On Wed, Jan 30, 2013 at 02:23:26AM +0100, Jonathan M Davis wrote:
> On Tuesday, January 29, 2013 17:06:32 H. S. Teoh wrote:
> > Why do you have to mark naked variables as @property? Isn't that redundant?
> 
> In order to restrict what you can do with it to the subset of operations that you can do with a property function. In particular, taking its address would need to be illegal, as that won't work with a property function (or if it did, it would return a different type).

I see.


> It would be impossible to replace a normal variable with a property function without risking breaking code, because there are operations that you can normally do on a variable that couldn't possibly be implemented with a function (such as taking its address). But if you mark it to restrict what it can do, then you could swap it out with a function later without the risk of breaking code (which is one of the main reasons for having properties in the first place). @property doesn't currently do this, but it could, and if we don't have something like that, then it'll never be safe to swap variables and property functions.
[...]

If this is the case, then I would have to say that @property is fundamentally broken. The whole point of @property is to make functions behave like variables, but if this "variable emulation" isn't even complete, then it defeats the purpose of having it in the first place.


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!

On Wednesday, 30 January 2013 at 00:25:41 UTC, Jonathan M Davis wrote:
> On Wednesday, January 30, 2013 00:55:13 Rob T wrote:
>> [..]
>> 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?
>
> I believe that two main things are needed: [..]

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?

On Tue, 29 Jan 2013 17:32:20 -0800, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Wed, Jan 30, 2013 at 02:23:26AM +0100, Jonathan M Davis wrote:
>> On Tuesday, January 29, 2013 17:06:32 H. S. Teoh wrote:
>> > Why do you have to mark naked variables as @property? Isn't that
>> > redundant?
>>
>> In order to restrict what you can do with it to the subset of
>> operations that you can do with a property function. In particular,
>> taking its address would need to be illegal, as that won't work with a
>> property function (or if it did, it would return a different type).
>
> I see.
>
>
>> It would be impossible to replace a normal variable with a property
>> function without risking breaking code, because there are operations
>> that you can normally do on a variable that couldn't possibly be
>> implemented with a function (such as taking its address). But if you
>> mark it to restrict what it can do, then you could swap it out with a
>> function later without the risk of breaking code (which is one of the
>> main reasons for having properties in the first place). @property
>> doesn't currently do this, but it could, and if we don't have
>> something like that, then it'll never be safe to swap variables and
>> property functions.
> [...]
>
> If this is the case, then I would have to say that @property is
> fundamentally broken. The whole point of @property is to make functions
> behave like variables, but if this "variable emulation" isn't even
> complete, then it defeats the purpose of having it in the first place.
>
>
> T
>

Indeed, but a better idea would be to fix it, throwing it out seems a bit extreme.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Wed, Jan 30, 2013 at 02:40:45AM +0100, TommiT wrote:
> On Wednesday, 30 January 2013 at 00:25:41 UTC, Jonathan M Davis wrote:
> >On Wednesday, January 30, 2013 00:55:13 Rob T wrote:
> >>[..]
> >>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?
> >
> >I believe that two main things are needed: [..]
> 
> 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?

Property functions are precisely what gives you encapsulation.

Think about it. They let you "pretend" that there's a public member variable, but actually you don't know (and don't have to know) what their real implementation is. This is, by definition, encapsulation. So this is actually an argument *for*, rather than against, property functions.

There's nothing wrong with public member variables per se, it's the fact that it makes external code rely on their specific implementation. Property functions alleviate this problem by making it possible to change the underlying implementation without needing to touch user code.


T

-- 
The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis