When objects are not enough (2021)
tonysm.com
When objects are not enough (2021)
1–10 of 58 posts
Re: When objects are not enough (2021)
#2Needs "2021" in the headline
Re: When objects are not enough (2021)
#3I 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 and all were horrible (i.e. extension methods). I have been experimenting with these concepts too (i.e. a receiverless message is a throw, which will be picked up by an enclosing effect handler via pattern match), but its all unreadable and unmaintainble mess. Anyone doing the same thing? I would love to exchange thoughts :) extras to read: ian piumarta‘s papers on his OOP system and a paper on Korz programming language
Re: When objects are not enough (2021)
#4I 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…
> Why the hell receiver of a message gets to dispatch the implementation at very late moment? Why not context?
Well, then it is the context who is the actual receiver, isn't it? Since in this scenario the object may never even receive the message since the context has already processed it on its own, so calling it a "receiver" would be incorrect.
> a composite object of an int and a float receive message „add“ - who decides which implementation to use
The composite object itself, who else? It can do anything, including doing nothing, or not using any of their implementations, or dividing its int by its float, etc.
Re: When objects are not enough (2021)
#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.
Re: When objects are not enough (2021)
#6> 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.
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.
Re: When objects are not enough (2021)
#7I 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 the containing object would receive and process the message before dispatching to it's component objects as it saw fit to accomplish the task of being an int-float object.
Re: When objects are not enough (2021)
#8> 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.
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.
We could say that mutability (or having functions/methods/etc) is part of the object’s identity.
Re: When objects are not enough (2021)
#9[deleted]
Re: When objects are not enough (2021)
#10> 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.
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.
Maybe, but mutability does not require inbuilt operations.
I have often used data-only objects, and passed them to fixed-context functions.
It's a cheap way to get OO behavior, in non-OO languages.