Re: [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi Stas, hi Etienne, let’s get practical and apply LSP to property accessors. Find below what I would read from the characteristics of LSP. Am 31.10.2012 um 20:46 schrieb Stas Malyshev <smalyshev@sugarcrm.com>: [...] >> Instead, LSP simply states that, given B <: A, all objects of A can be >> substituted by objects of B while preserving the validity of the >> method calls on these objects, and the validity of their return >> values. This is guaranteed here: Characteristics 1: Contravariance of method arguments in subtypes This applies to properties in so forth, that weaker requirements need to be allowed. This means: - Redeclaring a property without a specific type is OK (e.g. parent DateTime, children everything) - Redeclaring a property with a supertype is OK (e.g. parent MyDateTime, children DateTime) - Redeclaring a property that was read only as read-writable is OK in theory (it isn’t because of the history rule) - Redeclaring a property with as less visible is not OK (parent public, children protected) - Redeclaring a property with as more visible is OK (parent protected, children public) - Redeclaring a property as read-only is not OK (parent rw, children ro) Characteristics 2: Covariance of method return values in subtypes - For properties, this basically mirrors the rules from rules from characteristics 1 Characteristics 3: Preconditions cannot be strengthened: This is something we cannot and should not prevent in the language itself but it’s up to the programmer to do this correctly Characteristics 4: Postconditions cannot be weakened: See 3 Characterestics 5: History rule. See 3 cu, Lars