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 =3D false
self.social =3D true
self.bookish =3D false
super(&block)
end
end

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

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

field =3D Field.new {
julian =3D Nerd.new
dave =3D Jock.new
greginsky =3D 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=