Object Architecture

An Object Architecture describes how one's (abstract) "objects" relate to the underlying TuringMachine / HardwareArchitecture. This is in slight contrast to an ObjectModel which describes how one's Objects relate to machine memory.

Programmatically, the distinction relates to the issue of an object grouping operator/symbol vs. raw data. Of this distinction marks a divergence point where many arguments have been made: where a class definition starts and were the data starts. Without this boundary being clear, people conflate issues of subtyping vs. subclassing -- two similarly sounding items but have opposite structural relationships.

An ObjectArchitecture is friendly with AbstractDataTypes (as they come from the implicit ObjectArchitecture in C++), in that they are both rooted to the machine, but separate from an ObjectModel, which is rooted in an abstraction of "Object".

Please explain the difference between ObjectModel and ObjectArchitecture. The whole point of a program in CeePlusPlus is to avoid bugs which break the model, so I cannot see the difference for well formed program. -- JohnFletcher

In CeePlusPlus (as noted elsewhere on the wiki), the one key distinction between machine types (or structs) and class objects is that the latter has privacy by default.

• [It is true that in C++, struct and class are equivalent, except member elements of structs are public by default whereas class member elements are private by default. However, "machine types (or structs)" does not make sense in this context. How do machine types relate to classes and structs?]

• This is where the term "magic happens" is appropriate. As long as there's a clear distinguishing between physics and magic, it's not a problem.

• [I'm not clear what point you're making by "distinguishing between physics and magic" -- in your previous post, were you attempting to draw some equivalence between machine types and structs? If so, that's perhaps not inappropriate in some respects, but I don't see how it relates to private member elements. I could guess, but I'd rather not. In short, could you explain what you meant by, "the one key distinction between machine types (or structs) and class objects is that the latter has privacy by default" in terms of machine types? Do you mean that machine types hide their internal representation, similar to private members of a class?]

One common architecture is given by AlanKay in his AlanKaysDefinitionOfObjectOriented. It is being claimed that this experiment went the wrong way. See ObjectOrientedRefactored.

This text needs more refinement: How does Object Architecture differ from TypeModel or TypeTheory? A type system relates to underlying registers.

Yes, you are correct. These distinctions need to be clarified. I would suggest that an ObjectArchitecture is synonymous with TypeModel; and "ObjectModel", while not synonymous with TypeTheory, works in the same domain of such. See also ComputerScienceVersionTwo.

{A type system is an abstraction. Certain types are often related to underlying registers, but they certainly don't have to.}

Yes, that seems to be a convention within academia, but I argue that this is also cause for enormous confusion. The relationship to mathematics is the source of confusion. Mathematical models of computation relate to a Platonic space where there are no "real" types. But ComputerScience should also relate to concrete facts of the machine and these facts are not mere abstractions. What is the use of a programming language that cannot be implemented on a machine?

{A type system that does not reflect the underlying registers is certainly implementable and hardly a source of confusion. It's perfectly reasonable and not confusing, for example, to have a language whose only integer type is infinite precision but runs on machines with fixed-precision integer registers. Arguably, it's more confusing to have integers with seemingly-arbitrary limits and machine dependencies that complicate code portability.}

Yes, I understand that hooking types to machine registers seems an unnecessary and ugly limitation to the pure theorists, but the point of an architecture (as this page title says) is to build a higher-order relationship to the underlying realities of the lower-order hardware. Please see UnifiedDataModel for more information.

{I can't speak for pure "theorists", but hooking types to general-purpose machine registers is perfectly reasonable if you want to maximise performance, and hooking types to special-purpose machine registers or memory addresses is -- among other things -- the way to write device drivers using higher-level languages. My point is that it's perfectly reasonable -- and, depending on requirements, desirable -- to have languages with no types based on machine registers. It's also reasonable -- and, depending on requirements, desirable -- to have languages with types based on machine registers.}

{Similarly, it's reasonable, depending on requirements, to write code employing the LiskovSubstitutionPrinciple. In other cases, it's reasonable (again, depending on requirements) to write code that violates the LiskovSubstitutionPrinciple.}

{There is no "enormous confusion" in any of this, and working programmers happily embrace these notions as a matter of course. Whilst I can appreciate that your goal of a GrandUnification with a UnifiedDataModel perhaps benefits from a particular combination of the above language characteristics and approaches, it would be unreasonable to expect that all programming, everywhere, will take part in said GrandUnification or that it would benefit from doing so.}

---

See ObjectOriented.