Possreps, Objects, Mutability, Immutability, and Developing Non-database Applications.
Quote from johnwcowan on June 24, 2019, 11:28 pmQuote from Erwin on June 24, 2019, 11:17 pmSeems to me like you are assuming that "restricted visibility mechanisms" such as java's are a fundamental part of OO [and in particular its feature called "encapsulation"].
It is not. Encapsulation is the property of internal state being invisible by definition (except through exposed methods). Java does not do that because java allows internal state to be protected or even public, *direclty*.
Apparently the term encapsulation, like many other technical terms, is used with two different meanings by different people. Per Wikipedia (see the page for hyperlinks and references):
In object oriented programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:
- A language mechanism for restricting direct access to some of the object's components.
- A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.
Some programming language researchers and academics use the first meaning alone or in combination with the second as a distinguishing feature of object-oriented programming, while some programming languages that provide lexical closures view encapsulation as a feature of the language orthogonal to object orientation.
The second definition is motivated by the fact that in many of the OOP languages hiding of components is not automatic or can be overridden; thus, information hiding is defined as a separate notion by those who prefer the second definition.
You are evidently using it in the first meaning, but with the further requirement that only methods and not other components can be exposed.
(The Unicode glossary shows that the term character is used with four different meanings, so this is nothing unusual.)
John, "the second definition is provided as a consolation to those programmers who don't like the rigidity imposed on them by the first".
I mean, ***LOOK AT WHAT YOU SAY*** "the second definition is motivated by the fact that languages exist that don't abide by the first".
I don't know if Dijkstra still has any matter left to erode turning around in his grave, but over this I'm convinced if he did he would.
Quote from Dave Voorhis on June 24, 2019, 4:44 pmI suppose my -- perhaps flippant -- answer is, implement whatever you like. TTM certainly doesn't preclude implementing a classic object-oriented approach for modularising run-time state and code, but might (but that's only a might, not necessarily a would) frown on its instances winding up in the database.Or, explicitly provide modules, with module-local scope.
Or, strictly pass the file handle from operator to operator via parameters.
Or, pass a "state" tuple from operator to operator via parameters.
Or, provide higher-order operators and pass operators -- perhaps with closures -- from operator to operator via parameters.
Etc. There isn't one right answer here. Whatever approach is "right" depends on the nature of the language.
Again, this does not answer my question. Modules control visibility, but do not address the 'instance' side of OO. The file handle is just a reference, not the state value. But the Wikipedia article provides a hint. The answer might lie in the combination:
- Define the state value as a named compound type (UDF scalar)
- Provide a module-based mechanism to control visibility (named type publicly visible, scalar components not)
- A selector provides an initial instance of the type
- An operator returns a modified state value
- Destructive assignment records the new state.
So the TTM type system can do what OO does, but only if complemented by a visibility-controlling module system or equivalent.
Quote from dandl on June 25, 2019, 3:13 amQuote from Dave Voorhis on June 24, 2019, 4:44 pmI suppose my -- perhaps flippant -- answer is, implement whatever you like. TTM certainly doesn't preclude implementing a classic object-oriented approach for modularising run-time state and code, but might (but that's only a might, not necessarily a would) frown on its instances winding up in the database.Or, explicitly provide modules, with module-local scope.
Or, strictly pass the file handle from operator to operator via parameters.
Or, pass a "state" tuple from operator to operator via parameters.
Or, provide higher-order operators and pass operators -- perhaps with closures -- from operator to operator via parameters.
Etc. There isn't one right answer here. Whatever approach is "right" depends on the nature of the language.
Again, this does not answer my question. Modules control visibility, but do not address the 'instance' side of OO. The file handle is just a reference, not the state value. But the Wikipedia article provides a hint. The answer might lie in the combination:
- Define the state value as a named compound type (UDF scalar)
- Provide a module-based mechanism to control visibility (named type publicly visible, scalar components not)
- A selector provides an initial instance of the type
- An operator returns a modified state value
- Destructive assignment records the new state.
So the TTM type system can do what OO does, but only if complemented by a visibility-controlling module system or equivalent.
You've just summarised TTM, using some slightly different terminology. (E.g., your "instance of the type" = TTM's "value")
Again, search for "protected operators" in DTATRM, a phrase that Date & Darwen use to allude to what object-orientation often describes as "private members" and the like.
Note that "private members" are information hiding, which is distinct from (but often conflated with) encapsulation (as I pointed out in https://forum.thethirdmanifesto.com/forum/topic/possreps-objects-mutability-immutability-and-developing-non-database-applications/?part=2#postid-984880). Encapsulation is provided by POSSREPs.
In short, your file handle may be a value, defined by a POSSREP, with "protected operators" mapping the exposed value to some hidden (and per TTM, so hidden it's outside the model) internal/physical representation.
But beware of trying to turn the TTM type system into a strict analogue for object-oriented programming (with references, etc.) It isn't, and attempts to make it so will end in frustration. TTM clearly wants to put mutable state in scalar variables and relvars, not object-oriented instances, which per TTM are at best some not-quite-value, not-quite-variable, bit-of-both hybrid.
Quote from johnwcowan on June 24, 2019, 11:28 pm(The Unicode glossary shows that the term character is used with four different meanings, so this is nothing unusual.)
...Or function being used in C/C++ and elsewhere to ambiguously mean either a function or a procedure.
Quote from Erwin on June 24, 2019, 11:17 pmQuote from dandl on June 24, 2019, 4:33 pmThe proposition has been put that a value-based type system such as TTM describes can adequately replace one based on OO. I want to know what feature or principle is proposed to replace or implement encapsulation: packets of state with extended lifetime but restricted visibility.Seems to me like you are assuming that "restricted visibility mechanisms" such as java's are a fundamental part of OO [and in particular its feature called "encapsulation"].
I prefer not to assume anything other than what is stated. And no, java does not figure in my thinking.
It is not. Encapsulation is the property of internal state being invisible by definition (except through exposed methods). Java does not do that because java allows internal state to be protected or even public, *direclty*.
And the visibility technique as applied to the methods themselves has proved to have been crippled too : see the story of the com.sun packages (none of them intended to be visible except to the methods of the java runtime itself, but that was a kind of visibility predicate that the visibility mechanism could not support, so everyone knew they were there and the dumber ones trod into the pitfall).
I don't take horror stories as indicative of anything. I simply ask for a mechanism that provides for packaging of state with fine-grained control over lifetime and visibility. I don't care that some people use it badly; I care if you say I can't do it at all.
Show me how to do it right, otherwise get off the pot and let someone else have a go.
Quote from dandl on June 25, 2019, 6:31 amQuote from Erwin on June 24, 2019, 11:17 pmQuote from dandl on June 24, 2019, 4:33 pmThe proposition has been put that a value-based type system such as TTM describes can adequately replace one based on OO. I want to know what feature or principle is proposed to replace or implement encapsulation: packets of state with extended lifetime but restricted visibility.Seems to me like you are assuming that "restricted visibility mechanisms" such as java's are a fundamental part of OO [and in particular its feature called "encapsulation"].
I prefer not to assume anything other than what is stated. And no, java does not figure in my thinking.
It is not. Encapsulation is the property of internal state being invisible by definition (except through exposed methods). Java does not do that because java allows internal state to be protected or even public, *direclty*.
And the visibility technique as applied to the methods themselves has proved to have been crippled too : see the story of the com.sun packages (none of them intended to be visible except to the methods of the java runtime itself, but that was a kind of visibility predicate that the visibility mechanism could not support, so everyone knew they were there and the dumber ones trod into the pitfall).
I don't take horror stories as indicative of anything. I simply ask for a mechanism that provides for packaging of state with fine-grained control over lifetime and visibility. I don't care that some people use it badly; I care if you say I can't do it at all.
Show me how to do it right, otherwise get off the pot and let someone else have a go.
How to "do it right" inevitably depends on the specific language; it's not specified by TTM aside from RM Pre 26, plus what is implied by DTATRM's "protected operators".
Quote from dandl on June 25, 2019, 6:31 amI don't take horror stories as indicative of anything. I simply ask for a mechanism that provides for packaging of state with fine-grained control over lifetime and visibility. I don't care that some people use it badly; I care if you say I can't do it at all.
As I pointed out, first-class procedures with local mutable variables are just such a mechanism; though TTM doesn't actually require first-class procedures, I think it would be hard to argue against them at this point. The only thing they lack relative to "class"-ical objects is a straightforward means of introspection; then again, many OO languages don't have introspection, and those that do often have obviously bolted it on.
I'm quite sure first-class procedures with closures on mutable variables are a worthwhile feature. C# and JavaScript have them, Java and Rel seem content to manage without.
I'm less sure they provide a usable substitute for the encapsulation (information hiding) inherent in OO. Maybe it's just a matter of coming up with some syntactic sugar, maybe it's more.
I'm reasonably sure that TTM's compound scalars plus destructive assignment can do what OO does. Having operators that are not bundled (OO VSS 2) implies having multiple dispatch, which OO typically does not.
But in TTM everything is public, and that's not good, especially for larger systems. It may be that a relatively simple feature to control visibility is all that is needed, but I can't tell. The only one that comes to mind is the import/export of JS ES6.
Quote from dandl on June 25, 2019, 5:07 pmI'm quite sure first-class procedures with closures on mutable variables are a worthwhile feature. C# and JavaScript have them, Java and Rel seem content to manage without.
Java and Rel both have them. As noted previously, in Java they have to be wrapped. Determining whether this is a quirk or a feature is left as an exercise for the reader.
Quote from dandl on June 25, 2019, 5:07 pmBut in TTM everything is public, and that's not good, especially for larger systems. It may be that a relatively simple feature to control visibility is all that is needed, but I can't tell. The only one that comes to mind is the import/export of JS ES6.
No, everything in Tutorial D is notionally public, but why wouldn't it be? It's a pedagogic language.
There's nothing in TTM that precludes implementing information hiding via whatever mechanisms you like in your own D, as long as they're not in violation of the pre/pro-scriptions.