The author contrasts "objects" and "ADTs" (abstract data types), but uses - to my mind - an improvished definition of ADTs. I've always thought of On the criteria to be used in decomposingsystems into modules (Parnas) as the key paper for ADTs, which the author cites (at [26]) but doesn't use for this purpose. Of course, different definitions are available. The distinction the author uses is that objects can have dif…
The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]
31–40 of 45 posts
Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]
#32This seems to be throwing the rhetorical baby out with the bathwater - programming is not only a technical activity, but in large part a technical activity performed BY HUMANS, and generally to satisfy requirements generated by other humans.
Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]
#33"Some of the advantages of object-oriented programming may be psychological in nature. For example, Schwill argues that “the object-oriented paradigm...is consistent with the natural way of human thinking” [28]. Such explanations may be important, but they are out of scope in this inquiry; I am instead interested in whether there might be significant technical advantages of object-oriented programming." This seems to…
Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]
#34When we can do that we can also replace the messagee with an instance of some other conformant class, and thus we can reuse the client-side implementation of the interaction-protocol with many different types of recipients.
Using the word "replace" here is easily misleading. A better word is "reuse". We don't typically DELETE the original service object at all. More likely we just REUSE the same client-code with different types of "service objects". The point is it can interact with many differently implemented service-objects that offer the same interface.
If each class defined only one message it responds to, that wouldn't look like OOP, would it? It would look like FP where functions basically understand just one message, "Tell me your value!".
Of course FP languages can simulate OOP and vice versa. Smalltalk for instance defines the class BlockClosure which understands the message #value: (among others). That means - "Tell me your value for this argument". But BlockClosure also understands other messages, like #asString, #class etc. That is OOP.
We could say that OOP is a generalization of FP in this sense. Objects can do what functions do, calculate their "value" for a given argument. But this operation is explicitly declared as just one of the operations that object can perform. There is NO SPECIAL syntax for it, like "()" in FP languages.
JavaScript can be characterized as a functional-object -language because its functions are first-class citizens but they can also have other operations than calculating their value. We can for instance "send the message" .toString() to them to get their source-code.
You could have a "messaging conversation" with a JavaScript function (-object) like this:
Me to function: "Hey tell me your source-code". The function returns it
Me to my Helper -object: "Hey helper, does this source-code look secure?". Helper returns "Yes".
Me to function: "OK, I trust you. Tell me your value for argument 42!". Function returns it.
The conversation / messaging above could be reused with some other type of object without having to modify the client-side code at all.
Summary: The essence of OOP is that objects can declare MULTIPLE messages they respond to, thus defining the protocol they can be interacted with. Many objects can support the same protocol of interacting with them, but provide a different implementation as to how they actually calculate some (or all) responses to the messages they get.
Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]
#35From a discussion we had about this paper, in the context of the relational logic language we are working on: Data abstraction is an interesting topic in a language that doesn't really have data structures. ADTs are usually used to describe the allowable operations on either a data structure or some side-effectful system. For describing data models , we have tables and (soon) integrity constraints. An integrity const…
Why would stable ids be a problem? Is it because immutability doesn't give you any stable references to latch on to?
EDIT: Thinking about it, the issue is definitely not that it is immutable but that it is declarative. In the absence of control flow, `new` is not sufficient to provide unique identity because the rule in question may be run zero or more times.
Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]
#36I agree with the idea that the abstractions provided are "inevitable." I disagree with the idea that the way we're using them is optimal. I've just spent time in my code reducing polymorphic classes into simpler type identifier + record combinations. The rationale I am going by is that every class I introduce proliferates new symbols: the class definition, the instances, the methods, the values, the references to yet…
http://bitsquid.blogspot.com/2014/08/building-data-oriented-...
http://bitsquid.blogspot.com/2014/09/building-data-oriented-...
http://bitsquid.blogspot.com/2014/10/building-data-oriented-...
Data is stored in flat, homogeneous blobs and linked together by integer ids instead of pointers.
Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]
#37Earlier quoted context omitted.
Why would stable ids be a problem? Is it because immutability doesn't give you any stable references to latch on to?
Have a look at the Edelweiss paper I linked. Stable ids are needed for that model. We would probably be fine with eg random uuids if we stuck with Bloom. EDIT: Thinking about it, the issue is definitely not that it is immutable but that it is declarative. In the absence of control flow, `new` is not sufficient to provide unique identity because the rule in question may be run zero or more times.
Though if you are completely declarative, why would object identities be necessary?
Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]
#38The author also has some curious opinions about FP approaches. For example, he points out that Haskell's type system distinguishes between homogenous and heterogeneous lists, but then considers this to be a disadvantage. I get the strong impression that the paper is arguing backward; assuming that the properties of common OOP languages are the ideal, and then deriving from that assumption the answer that OOP is the best paradigm.
Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]
#39The author contrasts "objects" and "ADTs" (abstract data types), but uses - to my mind - an improvished definition of ADTs. I've always thought of On the criteria to be used in decomposingsystems into modules (Parnas) as the key paper for ADTs, which the author cites (at [26]) but doesn't use for this purpose. Of course, different definitions are available. The distinction the author uses is that objects can have dif…
You can't have large flexible systems of any kind without some sort of fixed interfaces or protocols. There must be millions of examples. Sockets, ODBC, drivers, USB, nuts and bolts etc etc.
This also applies implicitly to any client for interop: you don't have to use the whole interface, just the festures you want. In effect, you are using different, smaller interface.
Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]
#40Earlier quoted context omitted.
Have a look at the Edelweiss paper I linked. Stable ids are needed for that model. We would probably be fine with eg random uuids if we stuck with Bloom. EDIT: Thinking about it, the issue is definitely not that it is immutable but that it is declarative. In the absence of control flow, `new` is not sufficient to provide unique identity because the rule in question may be run zero or more times.
Alot of work in glitch goes into solving this problem. In the new case, we are able to form stable (reproducible) IDs through a memoized lexical stream (re-lex will produce the same tokens if possible) and by using the call stack (so the id is a path with special ids for loop indices). For a declarative (rule based?) language, perhaps rule firing context could be used for a similar purpose; I'll try to look at that p…
For now we synthesise ids out of contextual information eg "the user created at time T by event X". This works for now but it feels a little awkward. Once we have written more code in Eve we will have a better set of examples to guide thinking about a solution.