DIP26: properties defined

Rob T alanb at ucora.com
Fri Feb 8 21:13:20 PST 2013


On Friday, 8 February 2013 at 23:53:40 UTC, Robert wrote:
> Ok. Here finally it is:
>
> http://wiki.dlang.org/DIP26
>
>
> Best regards,
>
> Robert

"Properties as defined in this DIP are a way of encapsulation of 
fields of an entity (class, struct, module) in a way that the 
class/struct/module can actually control the access and thus 
encapsulates it, such that the field in reality might not even 
exist or be in a different format than presented, ... "

This part of the definition seems to be sensible: A property 
implementation that meets the encapsulation test has to prevent 
direct access to the underlying property variables so that access 
can be controlled.

Unfortunately the current proposed implementation fails to meet 
the encapsulation test for structs and classes and also for 
globals inside modules because no matter if a field is marked 
private inside a class or struct, it is directly accessible from 
outside the class or struct within the same module, thus breaking 
encapsulation, therefore control is not assured, i.e., the 
property methods are easily circumvented from within the module.

If we make an exception to the encapsulation definition and allow 
encapsulation to be circumvented only within the module level but 
not from outside the module, then module level properties can 
meet the encapsulation test since private globals are not 
accessible from outside, but that works only if module level 
properties are allowed, but I understand that the currently 
proposed implementation is in a conflict with UCFS, so another 
exception to the definition is needed to disallow module level 
properties only because the implementation is inadequate which 
seems absurd to have to do.

In summary, the definition of property encapsulation is good, but 
to meet the definition, the @property implementation is not 
adequate, and D will require the ability to mark variables as 
private at the module level (this is something I don't understand 
why we don't have).

--rt


More information about the Digitalmars-d mailing list