Re: Messaging Passing and context

On Sun, Apr 7, 2013 at 4:47 AM, Julian Leviston <[e-mail]>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/