Possible @property compromise
Chad Joan
chadjoan at gmail.com
Tue Jan 29 18:26:43 PST 2013
On 01/29/2013 08:40 PM, 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?
No, it means that style of programming is no longer bad.
It is already possible to write public member variables. It's pretty
much as dangerous to do so as the wisdom says.
We avoid using public member variables specifically because, in most
languages, this makes it impossible to add hooks into the
assignment/retrieval of the variable later without breaking the API.
Now, in D, we might one day be able to add those assignment/retrieval
hooks onto a variable without breaking API. That makes it no longer
necessary to avoid public variables, though you will probably have to
mark them @property to get the safety.
More information about the Digitalmars-d
mailing list