ara.t.howard / noaa.gov wrote:
> On Thu, 4 Jan 2007 dblack / wobblini.net wrote:
>
> >> make sense?
> >
> > It seems a bit drastic to flip things around into that less OO style.  I'm
> > not too worried if something like BlankSlate has to jump through a hoop or
> > two.
>
> i wouldn't say it's less OO.  according to wikipedia
>
> in fact, it's quite OO: Pervasives (Introspector or whatever we might call it)
> is the object that sees through to the pristine unalterable state of any other
> object.  it interacts with these other objects by sending messages.  this is
> quite inline with any OO i've ever heard of, for instance
>
> we might as well say something like
>
>    Guru.send student, message, :compassion
>
> http://en.wikipedia.org/wiki/Object_%28computer_science%29 seems to agree
> somewhat
>
>    "In the programming paradigm, object-oriented programming, an object is an
>    individual unit of run-time data storage that is used as the basic building
>    block of programs. These objects act on each other, as opposed to a
>    traditional view in which a program may be seen as a collection of
>    functions, or simply as a list of instructions to the computer. Each object
>    is capable of receiving messages, processing data, and sending messages to
>    other objects.  Each object can be viewed as an independent little machine
>    or actor with a distinct role or responsibility."
>
> i understand the sentiment.  still, what we after is a methodology which
> ensures that some aspects of objects can always be reached.  it's quite OO to
> delegate the responsibility of locating and preserving that aspect to another
> object.  syntactically one might prefer
>
>    reveal{ object }.send msg
>
> but the impl would obviously be the same since, here, we've just popped up to
>
>    (Kernel|Object).reveal
>
> remember that much of ruby works this way: puts, fork, exit, raise, etc are
> all hung off of Kernel|Object.
>
> > In practice, has the name conflict issue with send actually been much of a
> > problem?
>
> yes. and the related object_id, instance_eval, instance_variable_get, etc.
> the fact that some, but not all, methods of an object are required for it to
> function at a reasonble level, and that those same methods are not protected
> or separated from 'normal' methods in any way has frequently been an issue for
> the few metaprogramming libs i've written such as traits, attributes, xx, etc.
>
> regards.

you make a strong argument ara. i know we've discussed this particular
question before, i forget what we came up with then. i'll have to
search for it. but at the moment it would be nicer with a shorter
notation. what about some type of alternate "dot" that demands the Guru
module definition:

  obj$send message

or something. (Hmm... didn't someone suggest using the dollar sign in a
similar syntax before? What was that about?)

T.