DIP23 Counter Proposal

Regan Heath regan at netmail.co.nz
Thu Feb 7 07:45:02 PST 2013


On Thu, 07 Feb 2013 15:02:41 -0000, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Wed, 06 Feb 2013 23:26:03 -0500, Chad Joan <chadjoan at gmail.com> wrote:
>
>> On 02/05/2013 09:45 PM, Steven Schveighoffer wrote:
>>> ...
>>>
>>> The semantic rewrite stuff is something I don't feel strongly either
>>> way. It would be nice, but at the same time, it doesn't feel necessary
>>> to me. One can always simply avoid it by not using the operators on
>>> properties.
>>>
>>
>> A core feature of properties is that variables can be migrated to them  
>> (and back) without breaking any of the caller's code.  Forbidding more  
>> than half of D's operators on them will definitely break this attribute.
>
> I find this explanation lacking.  A field supports operations that are  
> impossible to implement with properties, there will never be a  
> non-code-breaking change from a field to a property.  So it's a matter  
> of "how much" breakage you want to allow.  This is really a judgment  
> call, there is no "right" answer.  The closest you can get to a field is  
> to ref an actual field.  But in that case, I don't see the point of the  
> property, since you give unfettered access to the field!
>
> The whole point of having properties that I see is to implement things  
> you CAN'T implement with a field, or are more cumbersome.  Like  
> read-only fields.  Such a change would necessarily and on purpose break  
> code.

There are several "points" to properties it would seem:
http://en.wikipedia.org/wiki/Property_(programming)

I have heard the goal Chad mentions said numerous times in similar  
discussions (to allow migration of fields to properties and back without  
breaking caller code) and I imagine this would be true and work in all  
cases for languages which don't have pointers, perhaps.

But as D has pointers there can and probably does exist caller code which  
takes the address of a public field and would therefore simply break if  
that field was changed into a "property" (AKA method call).

Now, perhaps there is some magic the compiler could do to make it work  
again, but if to achieve this we really have to jump through some crazy  
hoops or add complexity and edge-cases to the language then it's just not  
worth it, IMO.

And, as Steven has said implementing read-only fields and adding layers of  
functionality are 2 other goals/points of properties and these are  
certainly useful by themselves, with or without any other benefits.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


More information about the Digitalmars-d mailing list