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
