Re: [phix] Ambiguity of 'object'
- Posted by petelomax Feb 22, 2021
- 915 views
I object!
The weird thing is, cmiiw, there is no "object" in most programming languages: there are classes and instances and methods, but no objects.
(Ignoring theoretical yap, and type-less languages, reading wikipedia I get the feeling we nail object in a way few others could ever hope to.)
The closest thing to object I can think of is void* in C++, but even that's quite helpless as an entity without programmer-assisted casting.
This has made me think the "five core types" diagram we've seen regularly in the past two months is not quite right:
<--------- object --------->
| | |
+-number +-sequence +-class
| | |
+-integer +-string +-struct
| |
<-------- user defined types ------->
Technically a class (instance) is a special kind of sequence, but that's an implementation detail and if you perform any of the normal sequence operations on it (append, slice, etc) you'll hose it.
Sequences and classes can contain other objects, but with different access methods (integer subscript vs. dot notation and string subscripts), different semantics (copy on write vs reference), and integer standing in as a routine-id in classes.
A struct implies a simpler "class without methods" with fields public by default, but in reality it is just a pure alias (of class) and any such implied differences are not enforced, apart from the easily changed public vs private default.
User defined types simply attach a clarifying name along with (optionally nested) run-time validation and verification code to the builtin types, without otherwise fundamentally changing them.
Note that a class implicitly defines a perfectly sufficient user defined type of the same name, but there is no deliberate bar on further nested layers of type wrappers, which is what "class extends" effectively does.
I think the main objections in the past were that we had object without object oriented programming.
