From: Robert Klemme Date: 2013-04-07T20:13:34+09:00 Subject: Re: Messaging Passing and context --f46d0447890314d0a304d9c369b5 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 7, 2013 at 4:47 AM, Julian Leviston wrote: > Hi, > > I've often wanted what I'm about to describe. > > Some history about me, so you know this isn't a complete noob question: I > understand separation of concerns and encapsulation quite well (at least, I > think I do). I've been programming in object oriented languages for most of > my life (I'm 37, and I started SmallTalk when I was 17). I've programmed in > most languages: SmallTalk, Java, Ruby, forth, Python, C/C++, BASIC, > VisualBasic, ASM, LISP (common, scheme, racket), JavaScript, Self, bit of > Haskell, Erlang etc., etc. > > Context here is object-oriented message sending: > So what I'm interested in, when an object sends a message to another > object, why is there no context-sensitivity? In other words, (all > judgements aside as this is just a trivial example), I'd like the nerd to > be defined as a person who dislikes outside areas, therefore behaves > according to his mood when he's outside perhaps. > Maybe your design is not appropriate for the type of application you have in mind: why not make Place a member of Person since a person can be in one place at a time only anyway? Also: you put boolean properties inside Place and subclasses which are set in each sub class constructor. They are obviously intended to control some form of behavior. If you tie values of these properties to the class so closely it is much, much more reasonable to encode that differing behavior into implementations of sub class methods. See also state and strategy patterns. Instantiating a Nerd inside a FIeld... or messaging him with the say_hi > type message should be able to bear some context on what that nerd's reply > is. I'm not stipulating a tight coupling of context to object, I *like* > decoupled contexts, and I like interfaces, but just like the mechanism of > introspection, it'd be useful and nice to be able to garner *some* > information about the calling context, especially if (and this is my real > beef) the calling context WANTS TO GIVE THE INFORMATION. The obvious > solution is simply to change the interface so it contributes a variable > which passes across this information, but versioning interfaces is a > complete pain - I'd like to have a common object (called caller, possibly) > that I could query from within a method without the caller having to pass > through "self" every single time. That is usually a bad idea. What you accomplish with this is non explicit passing of state around. That usually interferes with testability: if you pass in everything explicitly it is no problem to create a mock environment to test the class. If there is implicit passing this is much harder or even impossible. Plus, the code is much harder to understand since passing of the implicit data is not part of the interface. Also, logic of a class is much more difficult to understand if it does not only depend on the instance's state but also on some kind of hidden state which is made accessible to method implementations. Caveat: I often find it difficult to have this type of discussion on synthetic examples because in a real world case there is so much more context and information about the purpose which is missing here. So please take everything I write with a grain of salt. > Thus we could then apply some duck typing in the callee side and get it to > ask some questions of its context before responding to messages. > I am not sure I understand what you mean by "duck typing" here - I get the impression that you might not have fully understood the concept. With duck typing you would just invoke methods on the context and work from there. > Am I missing some obvious design considerations here? > > I guess I'm talking more about language design than language usage, so > there might be a better place to discuss this. Comments? > I think this place is OK. In fact I am missing these types of discussions which seem to have become very rare. Thank you for bringing this up and giving an opportunity to once again reason about design! Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ --f46d0447890314d0a304d9c369b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Apr 7, 2013 at 4:47 AM, Julian Leviston &= lt;julian@coret= ech.net.au> wrote:
Hi,

I've often wanted what I'm about to describe.

Some history about me, so you know this isn't a complete noob question:= I understand separation of concerns and encapsulation quite well (at least= , I think I do). I've been programming in object oriented languages for= most of my life (I'm 37, and I started SmallTalk when I was 17). I'= ;ve programmed in most languages: SmallTalk, Java, Ruby, forth, Python, C/C= ++, BASIC, VisualBasic, ASM, LISP (common, scheme, racket), JavaScript, Sel= f, bit of Haskell, Erlang etc., etc.

Context here is object-oriented message sending:
=A0
=
So what I'm interested in, when an object sends a message to another ob= ject, why is there no context-sensitivity? In other words, (all judgements = aside as this is just a trivial example), I'd like the nerd to be defin= ed as a person who dislikes outside areas, therefore behaves according to h= is mood when he's outside perhaps.

Maybe your design is not appropriate= for the type of application you have in mind: why not make Place a member = of Person since a person can be in one place at a time only anyway?

Also: you put boolean properties inside Pla= ce and subclasses which are set in each sub class constructor. =A0They are = obviously intended to control some form of behavior. =A0If you tie values o= f these properties to the class so closely it is much, much more reasonable= to encode that differing behavior into implementations of sub class method= s.

See also state and strategy patterns.
=

Instantiating a Nerd inside a FIeld... or messaging him with the say_hi typ= e message should be able to bear some context on what that nerd's reply= is. I'm not stipulating a tight coupling of context to object, I *like= * decoupled contexts, and I like interfaces, but just like the mechanism of= introspection, it'd be useful and nice to be able to garner *some* inf= ormation about the calling context, especially if (and this is my real beef= ) the calling context WANTS TO GIVE THE INFORMATION. The obvious solution i= s simply to change the interface so it contributes a variable which passes = across this information, but versioning interfaces is a complete pain - I&#= 39;d like to have a common object (called caller, possibly) that I could qu= ery from within a method without the caller having to pass through "se= lf" every single time.

That is usually a bad idea. =A0What you accomplis= h with this is non explicit passing of state around. =A0That usually interf= eres with testability: if you pass in everything explicitly it is no proble= m to create a mock environment to test the class. =A0If there is implicit p= assing this is much harder or even impossible. =A0Plus, the code is much ha= rder to understand since passing of the implicit data is not part of the in= terface.

Also, logic of a class is much more difficu= lt to understand if it does not only depend on the instance's state but= also on some kind of hidden state which is made accessible to method imple= mentations.

Caveat: I often find it difficult to have t= his type of discussion on synthetic examples because in a real world case t= here is so much more context and information about the purpose which is mis= sing here. =A0So please take everything I write with a grain of salt.
=A0
Thus we could then apply some= duck typing in the callee side and get it to ask some questions of its con= text before responding to messages.

I am not sure I understand what you = mean by "duck typing" here - I get the impression that you might = not have fully understood the concept. =A0With duck typing you would just i= nvoke methods on the context and work from there.
=A0
Am I missing some obvious design considerations here?

I guess I'm talking more about language design than language usage, so = there might be a better place to discuss this. Comments?

I think this place is OK. =A0In fact I am missing these types of= discussions which seem to have become very rare. =A0Thank you for bringing= this up and giving an opportunity to once again reason about design!

Kind regards

robert


--
remember.g= uy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
--f46d0447890314d0a304d9c369b5--