4 ms·

If I understand you correctly you're saying something like TweedHeads.walk(), TweedHeads.eat() and TweedHeads.rest() make it sensible to define Human as a class

If I understand you correctly you're saying something like TweedHeads.walk(), TweedHeads.eat() and TweedHeads.rest() make it sensible to define Human as a class. But then how would you attach makelove() or fight() or discuss() to a single Human? When do we use TweedHeads.discuss(visitor4rmindia) vs visitor4rmindia.discuss(TweedHeads)?

ivey 18y ago
It took me a minute to realize that TweedHeads was an object and not a class.
- MHollender 18y ago
  I figure humans are best modelled as singletons, each being one instance of his own class... (This is why prototype-based OO would sometimes be more useful)
MHollender 18y ago
(Python) TweedHeads.Say("something", visitor4rmindia.Listen) visitor4rmindia.Say("something else",TweedHeads.Listen) The Say method takes 2 parameters, what is said in a string, and a reference to the listening method of the partner. The Say method will first write into the it's private log "I'll remember for a while, I said to {listenmethod.im_self}: something" and do perhaps do some other stuff, and then call the referred Listen method passing in the "something" as a parameter and also passing self as a parameter, to let him know who said it to him. The Listen method of that object will write into it's own private log "I'll remember for a while: this guy {the passed-in self} told me something", and then perhaps do some other stuff. Of course this is functional/OO, and a pretty awesome kind of OO, it being Python, not just basic mainstream OO.
kilowatt 18y ago
discuss() and fight() and makelove() are usually (hopefully!) commutative. I think the more interesting observation to make is: what is the type of the argument to discuss? SentientBeing? CanDiscussMixin? In the first case, I bet you could imagine objects to "discuss" with that would only awkwardly inherit from SentientBeing, and in the second, your major objects will quickly grow loads of mixins. Of course there's also the "implements interface" appproach. I think all the models break down at some point...maybe the choice of which one to use is dependent on the problem.
- visitor4rmindia 18y ago
  Actually, what I was leading up to was that _neither_ is "valid". The better way (in this case) would be: discuss (TweedHeads, visitor4rmindia); This, to me, underlines some of the problems of the OOPS approach. Everything starts "looking like" methods even when they would be more natural as simple functions.

ivey 18y ago

It took me a minute to realize that TweedHeads was an object and not a class.

MHollender 18y ago
I figure humans are best modelled as singletons, each being one instance of his own class... (This is why prototype-based OO would sometimes be more useful)

MHollender 18y ago

(Python) TweedHeads.Say("something", visitor4rmindia.Listen) visitor4rmindia.Say("something else",TweedHeads.Listen) The Say method takes 2 parameters, what is said in a string, and a reference to the listening method of the partner. The Say method will first write into the it's private log "I'll remember for a while, I said to {listenmethod.im_self}: something" and do perhaps do some other stuff, and then call the referred Listen method passing in the "something" as a parameter and also passing self as a parameter, to let him know who said it to him. The Listen method of that object will write into it's own private log "I'll remember for a while: this guy {the passed-in self} told me something", and then perhaps do some other stuff. Of course this is functional/OO, and a pretty awesome kind of OO, it being Python, not just basic mainstream OO.

kilowatt 18y ago

discuss() and fight() and makelove() are usually (hopefully!) commutative. I think the more interesting observation to make is: what is the type of the argument to discuss? SentientBeing? CanDiscussMixin? In the first case, I bet you could imagine objects to "discuss" with that would only awkwardly inherit from SentientBeing, and in the second, your major objects will quickly grow loads of mixins. Of course there's also the "implements interface" appproach. I think all the models break down at some point...maybe the choice of which one to use is dependent on the problem.

visitor4rmindia 18y ago
Actually, what I was leading up to was that _neither_ is "valid". The better way (in this case) would be: discuss (TweedHeads, visitor4rmindia); This, to me, underlines some of the problems of the OOPS approach. Everything starts "looking like" methods even when they would be more natural as simple functions.