Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When objects are not enough (2021)

tonysm.com

Post reply on HN
Print view View original

21–30 of 58 posts

Re: When objects are not enough (2021)

#21

Post by c-linkage »

meheleventyone wrote: post #7
artemonster wrote: post #3

I never liked „OOPs world“ obsession with a receiver. Why the hell receiver of a message gets to dispatch the implementation at very late moment? Why not context? And when there are many receivers? I.e. a composite object of an int and a float receive message „add“ - who decides which implementation to use and why the heck any of them may even know how to add self to another? There were many attempts to solve this an…

Maybe I'm misunderstanding but the whole point of any messaging system is that the sender "doesn't know how to process the message" and it's up to the receivers to process it and coordinate amongst themselves. Otherwise you could just do the processing where the message was sent. For non-OOP examples you have most service architectures. So from that perspective an int-float object would be built by composition and th…

In OOP as I understood it, messages are first-class entities at the same level as "objects". This is strikingly different from modern OOP languages where a message is conflated with "function calls". This is pointed out in the article: "[I]n Smalltalk, messages 'were not real messages but disguised synchronous function calls', and this mistake was also repeated in other languages[...]".

If a message is a first class entity, then an object can technically have only one "function call" -- receive message.

So that an object can simulate an arbitrary set of functions with arbitrary arguments, the implementation of the "receive message" function cannot impose conditions on the format or content of the message. Instead, the message must be encoded in a self-describing format so that the object can interrogate the message and its contents, and only then decide what to do with that message, up to an including ignoring the message entirely.

To make this more concrete, imagine having an JavaScript object that has only one method: receive messages encoded as JSON strings. With JSON strings we can say that the message is self-describing and is easily parsed by the object. Once the JSON string is parsed, the object can then decide what to do based on the content of the message. This is both a late-binding and a dispatching activity.

It should be clear that the version of OOP does not include anything about types. That's because OOP was designed with LISP-like languages in mind, where symbols were processed and strongly-typed objects. It also means that build-/complile-time checking wasn't possible.

I'd say the modern web with JavaScript and HTTP calls is more like the original OOP design than any modern "OOP"-like programming language.

Re: When objects are not enough (2021)

#22

Post by niam »

ChrisMarshallNY wrote: post #5

> An object has state and operations combined. My own definition has always been that an object has state and identity . I have never considered functions/methods to be a requirement for something to be an object.

I think you're right that, in the object-oriented world, a method isn't a necessary condition for most people to consider something an "object".

What the author seems to be saying is that if someone asked you to sell OOP, one way you'd sell it is by mentioning that an object can couple logic and state. That's a distinguishing factor between objects and other data structures.

Re: When objects are not enough (2021)

#23

Post by artemonster »

meheleventyone wrote: post #7
artemonster wrote: post #3

I never liked „OOPs world“ obsession with a receiver. Why the hell receiver of a message gets to dispatch the implementation at very late moment? Why not context? And when there are many receivers? I.e. a composite object of an int and a float receive message „add“ - who decides which implementation to use and why the heck any of them may even know how to add self to another? There were many attempts to solve this an…

Maybe I'm misunderstanding but the whole point of any messaging system is that the sender "doesn't know how to process the message" and it's up to the receivers to process it and coordinate amongst themselves. Otherwise you could just do the processing where the message was sent. For non-OOP examples you have most service architectures. So from that perspective an int-float object would be built by composition and th…

then why the receiver would know too? There are more parties in this orgy: message receiver, message sender (method caller), environment (static: like imports), context (dynamic: like stack). Why the heck of all of those the receiver decides?

Re: When objects are not enough (2021)

#24

Post by dexwiz »

c-linkage wrote: post #21
meheleventyone wrote: post #7

Earlier quoted context omitted.

Maybe I'm misunderstanding but the whole point of any messaging system is that the sender "doesn't know how to process the message" and it's up to the receivers to process it and coordinate amongst themselves. Otherwise you could just do the processing where the message was sent. For non-OOP examples you have most service architectures. So from that perspective an int-float object would be built by composition and th…

In OOP as I understood it, messages are first-class entities at the same level as "objects". This is strikingly different from modern OOP languages where a message is conflated with "function calls". This is pointed out in the article: "[I]n Smalltalk, messages 'were not real messages but disguised synchronous function calls', and this mistake was also repeated in other languages[...]". If a message is a first class…

Does send() and method_missing() in Ruby fit that bill? From what I remember from Ruby, and it’s been a while, all method calls are just a message via send() with a symbol and arguments. Normal method calls are just syntactic sugar over this system. With method_missing() you can handle any messages that use a symbol that doesn’t match a method name. You could make the object handle messages in a completely dynamic way.

Re: When objects are not enough (2021)

#25

Post by jghn »

niam wrote: post #22
ChrisMarshallNY wrote: post #5

> An object has state and operations combined. My own definition has always been that an object has state and identity . I have never considered functions/methods to be a requirement for something to be an object.

I think you're right that, in the object-oriented world, a method isn't a necessary condition for most people to consider something an "object". What the author seems to be saying is that if someone asked you to sell OOP, one way you'd sell it is by mentioning that an object can couple logic and state. That's a distinguishing factor between objects and other data structures.

> one way you'd sell it is by mentioning that an object can couple logic and state

Depends on the OOP paradigm. This is not always the case.

Re: When objects are not enough (2021)

#27

Post by goatlover »

menotyou wrote: post #26

Yet another article about problems you'd never have if you wouldn't use object oriented paradigm.

But then you'd have other problems that come with using another paradigm, since there's no silver bullet, and no paradigm that handles all problems better than other paradigms. Probably popular languages tend to be multi-paradigm.

Re: When objects are not enough (2021)

#28

Post by cypherpunk666 »

artemonster wrote: post #3

I never liked „OOPs world“ obsession with a receiver. Why the hell receiver of a message gets to dispatch the implementation at very late moment? Why not context? And when there are many receivers? I.e. a composite object of an int and a float receive message „add“ - who decides which implementation to use and why the heck any of them may even know how to add self to another? There were many attempts to solve this an…

possibly related food for thought: google up DCI?

https://duckduckgo.com/?q=trygve+dci

Re: When objects are not enough (2021)

#29

Post by odipar »

eyelidlessness wrote: post #20
asgeir wrote: post #6

Earlier quoted context omitted.

It's not a requirement, but an immutable object has fewer uses than a mutable one. Functions/methods/actions/operations are just different names for the operations which mutate the state of the object. So, I would argue that they are a necessary attribute of mutable objects.

Object identity effectively implies mutability. Without that implication, two objects of the same structured value being non-equal doesn’t mean anything (and would probably be better classified as a mistake). Another way to look at it is that property setters (or whatever mechanism is used to directly mutate an object’s sub-data) is not meaningfully different from a method doing the same. You could even call it synta…

My take is that identity doesn't imply mutability, if you version objects. It could well be that your are looking at an old version of an object, using its unique identity combined with its version (number).

Objects refer to other objects using their (immutable) identity. In turn, resolving identities to objects requires (version) scope which can be in the past or present.

Re: When objects are not enough (2021)

#30

Post by smackeyacky »

PaulHoule wrote: post #13

+1 for use of the word "Reification"! There's another universe of object-adjacent systems that may or may not be connected with conventional OO programming languages. Two examples I'd point to are Microsoft's COM (designed so it is straightforward to write and call COM objects from C) and the "objects" in IBM's OS/400. In both of those cases I think the reification is the important thing, although you can see reifica…

COM dates back to a time when OO languages were uncommon but the techniques were being used in C.

I worked on a system back then that had “objects” that was based heavily around function pointers.

When we first got hold of the cfront C++ pre processor it did much the same thing but automated all the kludges we had for compile time checking.

So I wouldn’t really class something like COM as object adjacent, it was more “proto” OO

Post reply on HN