rowley@bath.cs.ucla.edu (Michael T Rowley) (02/06/91)
In article <1081@tetrauk.UUCP>, rick@tetrauk.UUCP (Rick Jones) writes: |> Has anyone tried to address this problem by considering that a class |> essentially has two interfaces? One - the "read" interface - provides |> information about the object in its current (abstract) state. The other - the |> "write" interface - offers facilities to change the object. It seems that if |> the language supported the ability to define not only the class TYPE of a |> variable, but also the class USAGE (read or write), then the restrictions would |> be clearer, both to the compiler and to the programmer. It's a little like the |> C++ "const" qualifier, but taking the semantic implications a lot further. I think this would be a very good idea. It would be possible to achieve this effect by requiring that programmers divide all their read_only feature definitions into seperate super-types. However, I think such an explicit division would detract from the readability of programs. Having the compiler automatically create such super-types would give the benefits of more precise typing without burdening the programmer. The fact that it is really only syntactic sugar means that the elegance of the existing typing mechanism would be maintained. My understanding of the usage of the read_only specification with the RECTANGLE/POLYGON example: - RECTANGLE would inherit from "read_only POLYGON" - Any code which deals only with the read_only aspects of a polygon would declare that variable or parameter as "read_only POLYGON" - If the add_vertex() method or any other write-method would be used, the variable or parameter would be declared as "POLYGON" - Type conformance for "read_only POLYGON" works exactly as if there was a user defined super type -- READ_ONLY_POLYGON. It is true that the concept of having a read_only interface for a class could be generalized by allowing an arbitrary number of interfaces to be defined for a class (as suggested by other posters). However, since such interfaces can be expressed by defining super-types of the class, I think the syntactic sugar should be limited to the division of the class interface that would be most useful to have automatically generated, i.e. the read_only interface. Michael Rowley
alms@cambridge.apple.com (Andrew L. M. Shalit) (02/07/91)
In article <1991Feb5.204144.26857@cs.ucla.edu> rowley@bath.cs.ucla.edu (Michael T Rowley) writes:
My understanding of the usage of the read_only specification with
the RECTANGLE/POLYGON example:
- RECTANGLE would inherit from "read_only POLYGON"
Um... What if you want to change the size of the rectangle?
Just because one attribute is read-only, doesn't mean all the
other ones are going to be read-only as well.
-andrew
--chip@tct.uucp (Chip Salzenberg) (02/07/91)
>In article <1081@tetrauk.UUCP>, rick@tetrauk.UUCP (Rick Jones) writes: > Has anyone tried to address this problem by considering that a class > essentially has two interfaces? One - the "read" interface - provides > information about the object in its current (abstract) state. The other > - the "write" interface - offers facilities to change the object. Correct me if I'm wrong, but I believe that the C++ |const| modifier already provides this feature. Or is something missing? -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Most of my code is written by myself. That is why so little gets done." -- Herman "HLLs will never fly" Rubin