4 ms·

What about Pure OOP? It has one way to represent things, everything is an Object. Details of the data-structures can be hidden behind the method-interface.

Tomte 6y ago
And everything has only one method in common: GetIdentifier(). So you've got components that cannot talk to each other, because the available methods differ (not just by name, but by what you can actually do), even though they are working on the same conceptual thing. The article argues for more "base datatypes" that are in common use. It doesn't matter whether the language/runtime exposes them as objects or PODs.
- galaxyLogic 6y ago
  The "base datatypes" have to be accessed somehow. If you have base-type Array you have to access its elements somehow. In C-type language you would access the elements by calculating a memory-offset and reading that location in memory. The problem is that now your code depends on elements of Array being stored in memory in specific (relative) locations. Whereas in an Object Oriented language you would access the elements by calling a method myArray.at(123). The benefit is you don't need to know how that data is stored or where. In OOP the elements of an Array of course can be Arrays too, whose elements you can similarly only access via a method-call.
choeger 6y ago
This doesn't help you to eliminate impossible values. A large aspect of datatype modeling is to encode constraints from the problem domain. Once encoded they are automatically enforced. Maybe the Builder pattern comes close to that ideal in OO, but it is really tedious to do right.
- stult 6y ago
  This has been my experience as well. It can be extraordinarily difficult to design a consistent OO type system to represent things like quantities with units and references, alongside quantities with just units and neither units nor references. For example, altitude is a quantity plus a unit of distance plus a reference (eg above ground level). Except some references require different data to convert. So AGL requires elevation for conversion to mean sea level, for example. Designing an OO system to represent that and constrain against invalid operations gets super complex and the developer ergonomics rapidly degrade in most languages. I’ve only ever successfully done it in C#, and even then I’ve found maintaining the unit conversion code annoying.
  - Smaug123 6y ago
    Have you tried F#, which has units of measure (with no runtime cost, due to erasure) built in?
  - TeMPOraL 6y ago
    Using your example, in the limit you end up with a data type carrying a chain of conversions with it, that reference some database that you don't own, but have to maintain access to. That altitude's reference itself is a particular geographical coordinate system (of many possible GCSes) that references a particular datum ("on what planet are we, and how does it look", of many possible datums), both of which are maintained by third-party organizations and political in nature. And then when you have another altitude with a slightly different reference, you have to handle conversions between them. At which point you may decide you just want to represent altitude with reference = "same as everywhere else in the program, because if it's the same, it doesn't matter what it is". Which is what most non-GIS code does, except it isn't documented explicitly, and it's up to the user or integrator to ensure the data fed to the program uses the same reference as the user expects to see.
HelloNurse 6y ago
Details could be usefully hidden, but also exposed or partially exposed in unexpected and undocumented ways. OOP is only an attractive and helpful conceptualization of doing something with a data representation in a computer's memory, not a magical way to suppress differences. It doesn't help with incompatible representations, operations and expectations about them except by providing some tools to deal with problems. On a more formal side, as already noted in other comments, if everything is an Object everything is nothing more than an Object: a one-type programming language is certainly coherent but no good if one wants to write meaningful programs.
- galaxyLogic 6y ago
  There is Smalltalk, where everything is an Object including numbers. And many "meaningful" programs have been written in Smalltalk I believe. In Smalltalk even the 'nil' meaning no object at all is an Object.
- ridiculous_fish 6y ago
  "Everything is an object" is a very deep idea. Make a system where everything is an object and every object knows what it can do: it becomes dynamically self-describing. The "formal side" assumes a static environment, but our OS and apps and browsers are constantly churning. When the runtime reality diverges from the compile-time model, you'll want dynamicism: can this object do that? What happens if I try to invoke an unsupported operation? etc.
  - hibbelig 6y ago
    But which object does what I need? If a is an array and s is a separator, do I write s.join(a) or a.join(s) or String.join(s, a)?
    - scroot 6y ago
      In Smalltalk, if you really need to find this, there is the Finder in which you can provide examples of input and output and it will suggest messages that implement the desired functionality. Also, the message does not need to be called "join," especially since it's use in the culture is ambiguous and confusing.
chriswarbo 6y ago
There's a nice object model called 'id' described at https://piumarta.com/software/cola https://piumarta.com/software/cola which is really simple and general-purpose. In this system, an object is simply a pointer to some memory (where instance data can be stored), preceded by a pointer to a 'vtable'; i.e. `myObject` is a pointer to some memory, and `myObject[-1]` is a pointer to a vtable. Vtables are themselves objects, implemented in the same way as above. There is a "vtable API" defining methods that a vtable should support, and a default 'vtable vtable' is defined during a bootstrap step (which is its own vtable). The resulting object system has objects which are completely opaque: they're just arbitrary chunks of memory, which are only useful to the methods defined by their associated vtable. Since those vtables are also opaque objects, we can provide our own objects which implement the idea of 'method call' in whichever way we like.
- scroot 6y ago
  Piumarta's COLAs work, and Maru, does not get enough attention. I only understand maybe understand 30% of the COLAs paper but one can intuit that there is real power there.
Mikhail_Edoshin 6y ago
The methods (messages) will need parameters anyway.
- galaxyLogic 6y ago
  Right, but those parameters can be Objects too
  - Mikhail_Edoshin 6y ago
    You still have to stop somewhere and supply actual numeric data (which is the only real data there is). I think it was in one Smalltalk book: so there are objects that send messages to each other, but how things are really done in Smalltalk? :) At some points there are primitive actions that actually do the work. Similarly with data we can define objects or any other higher-level concepts, but somewhere there must be actual data under all these abstractions.
    - scroot 6y ago
      It is in the final section of the Blue Book [1], where the virtual machine is described in Smalltalk itself. Basically you have tagged integer values and pointers and that's it. The VM describes a bytecode set that involves manipulation of memory structures that are the objects, along with very primitive arithmetic operations on low level integers. [1] http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....

Tomte 6y ago

And everything has only one method in common: GetIdentifier(). So you've got components that cannot talk to each other, because the available methods differ (not just by name, but by what you can actually do), even though they are working on the same conceptual thing. The article argues for more "base datatypes" that are in common use. It doesn't matter whether the language/runtime exposes them as objects or PODs.

galaxyLogic 6y ago
The "base datatypes" have to be accessed somehow. If you have base-type Array you have to access its elements somehow. In C-type language you would access the elements by calculating a memory-offset and reading that location in memory. The problem is that now your code depends on elements of Array being stored in memory in specific (relative) locations. Whereas in an Object Oriented language you would access the elements by calling a method myArray.at(123). The benefit is you don't need to know how that data is stored or where. In OOP the elements of an Array of course can be Arrays too, whose elements you can similarly only access via a method-call.

choeger 6y ago

This doesn't help you to eliminate impossible values. A large aspect of datatype modeling is to encode constraints from the problem domain. Once encoded they are automatically enforced. Maybe the Builder pattern comes close to that ideal in OO, but it is really tedious to do right.

stult 6y ago
This has been my experience as well. It can be extraordinarily difficult to design a consistent OO type system to represent things like quantities with units and references, alongside quantities with just units and neither units nor references. For example, altitude is a quantity plus a unit of distance plus a reference (eg above ground level). Except some references require different data to convert. So AGL requires elevation for conversion to mean sea level, for example. Designing an OO system to represent that and constrain against invalid operations gets super complex and the developer ergonomics rapidly degrade in most languages. I’ve only ever successfully done it in C#, and even then I’ve found maintaining the unit conversion code annoying.
- Smaug123 6y ago
  Have you tried F#, which has units of measure (with no runtime cost, due to erasure) built in?
- TeMPOraL 6y ago
  Using your example, in the limit you end up with a data type carrying a chain of conversions with it, that reference some database that you don't own, but have to maintain access to. That altitude's reference itself is a particular geographical coordinate system (of many possible GCSes) that references a particular datum ("on what planet are we, and how does it look", of many possible datums), both of which are maintained by third-party organizations and political in nature. And then when you have another altitude with a slightly different reference, you have to handle conversions between them. At which point you may decide you just want to represent altitude with reference = "same as everywhere else in the program, because if it's the same, it doesn't matter what it is". Which is what most non-GIS code does, except it isn't documented explicitly, and it's up to the user or integrator to ensure the data fed to the program uses the same reference as the user expects to see.

HelloNurse 6y ago

Details could be usefully hidden, but also exposed or partially exposed in unexpected and undocumented ways. OOP is only an attractive and helpful conceptualization of doing something with a data representation in a computer's memory, not a magical way to suppress differences. It doesn't help with incompatible representations, operations and expectations about them except by providing some tools to deal with problems. On a more formal side, as already noted in other comments, if everything is an Object everything is nothing more than an Object: a one-type programming language is certainly coherent but no good if one wants to write meaningful programs.

galaxyLogic 6y ago
There is Smalltalk, where everything is an Object including numbers. And many "meaningful" programs have been written in Smalltalk I believe. In Smalltalk even the 'nil' meaning no object at all is an Object.
ridiculous_fish 6y ago
"Everything is an object" is a very deep idea. Make a system where everything is an object and every object knows what it can do: it becomes dynamically self-describing. The "formal side" assumes a static environment, but our OS and apps and browsers are constantly churning. When the runtime reality diverges from the compile-time model, you'll want dynamicism: can this object do that? What happens if I try to invoke an unsupported operation? etc.
- hibbelig 6y ago
  But which object does what I need? If a is an array and s is a separator, do I write s.join(a) or a.join(s) or String.join(s, a)?
  - scroot 6y ago
    In Smalltalk, if you really need to find this, there is the Finder in which you can provide examples of input and output and it will suggest messages that implement the desired functionality. Also, the message does not need to be called "join," especially since it's use in the culture is ambiguous and confusing.

chriswarbo 6y ago

There's a nice object model called 'id' described at https://piumarta.com/software/cola https://piumarta.com/software/cola which is really simple and general-purpose. In this system, an object is simply a pointer to some memory (where instance data can be stored), preceded by a pointer to a 'vtable'; i.e. `myObject` is a pointer to some memory, and `myObject[-1]` is a pointer to a vtable. Vtables are themselves objects, implemented in the same way as above. There is a "vtable API" defining methods that a vtable should support, and a default 'vtable vtable' is defined during a bootstrap step (which is its own vtable). The resulting object system has objects which are completely opaque: they're just arbitrary chunks of memory, which are only useful to the methods defined by their associated vtable. Since those vtables are also opaque objects, we can provide our own objects which implement the idea of 'method call' in whichever way we like.

scroot 6y ago
Piumarta's COLAs work, and Maru, does not get enough attention. I only understand maybe understand 30% of the COLAs paper but one can intuit that there is real power there.

Mikhail_Edoshin 6y ago

The methods (messages) will need parameters anyway.

galaxyLogic 6y ago
Right, but those parameters can be Objects too
- Mikhail_Edoshin 6y ago
  You still have to stop somewhere and supply actual numeric data (which is the only real data there is). I think it was in one Smalltalk book: so there are objects that send messages to each other, but how things are really done in Smalltalk? :) At some points there are primitive actions that actually do the work. Similarly with data we can define objects or any other higher-level concepts, but somewhere there must be actual data under all these abstractions.
  - scroot 6y ago
    It is in the final section of the Blue Book [1], where the virtual machine is described in Smalltalk itself. Basically you have tagged integer values and pointers and that's it. The VM describes a bytecode set that involves manipulation of memory structures that are the objects, along with very primitive arithmetic operations on low level integers. [1] http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....