From: itsme213 <itsme213@...>
Date: 2005-01-15T05:41:12+09:00
Subject: Re: Duck Typing and automated Conversions


"Robert Klemme" <bob.news@gmx.net> wrote
> >> >     silly_example will not have other access to x, y
> >> >     (*: since you did: str=str.to_str; count=count.to_int)
> >>
> >> Wrong, because to_str need not create a new instance:
> >
> > The fact that String#to_str returns self, and Fixnum.to_int returns
self,
> > is
> > purely coincidental aliasing (from inside your method body). The
original
> > parm-list variables might as well be anonymous.
>
> But it's aliasing nevertheless and thus the caller can't rely on that the
> instances he provides remain unchanged thinking that the body of the
method
> never gets access to them.  In fact, the aliasing might even be desired as
> object creations are rather expensive and people are likely to provide
> String instances where #to_str is needed.
>
> Of course you can view "original arguments" as anonymous but what
difference
> would that make?
>
> I don't seem to get your point with this.  Can you attempt another
> explanation?

Thank you. I may have stated too strongly, and you may have read more into
it. It's not a central part of your scheme (or my generalization). Here is
my re-explanation:

First, let's limit the scope: In any object graph just about any object can
be accessible from anywhere (via transitive returns from other methods,
aliasing, globals, and constants like ObjectSpace). So in that extreme, just
about any method can be invoked on just about any object. We are not about
address aliasing, so let's just focus on those objects that are passed back
and forth via method parameters.

For these objects, your scheme allows us to say that the method body only
has named references to things returned by methods on the object. Which
means that it will not have references to the objects themselves (unless
those methods on the objects themselves lead there, or it uses other paths
through the object graph, such as via ObjectSpace).

Any better?