From: Julian Leviston <julian@...>
Date: 2013-04-07T11:47:37+09:00
Subject: Messaging Passing and context

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:

class Person
attr_accessor :mood
def say_hi_to(someone)
puts "hiya"
end
end

class Nerd < Person
# likes inside, dislikes outside
end

class Jock < Person
# likes outside, dislikes inside
end

class Socialite < Person
# doesn't care in or outside, but only likes places where people are interacting socially
end

class Place
attr_accessor :inside, :social, :bookish
def initialize(&block)
if block
yield
end
end
end

class Playground < Place
def intiialize(&block)
self.inside = false
self.social = true
self.bookish = false
super(&block)
end
end

def Library < Place
def initialize(&block)
self.inside = true
self.social = false
self.bookish = true
super(&block)
end
end

def Field < Place
def initialize(&block)
self.inside = false
self.social = false
self.bookish = false
super(&block)
end
end

field = Field.new {
julian = Nerd.new
dave = Jock.new
greginsky = Socialite.new
}

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.

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. 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.

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?

Julian