Official definition of call-by-value (Re: Finding the instance reference...)

[rurpy at yahoo.com]

On Nov 15, 4:12 pm, Terry Reedy <tjre... at udel.edu> wrote:
> rurpy at yahoo.com wrote:
>> On Nov 14, 8:56 pm, Terry Reedy <tjre... at udel.edu> wrote:
...snip...
>>>> * Does an object's behavior (methods) affect
>>>>  its value?
>>> My first answer is No.  Instance methods are attributes of a class and,
>>> in most cases, the value of a class.

So if method .foo() is an instance attribute it
is part of the object's value, but if it is part
of the object's class, it is part of the object's
behavior?  Even though calling obj.foo() causes
exactly same results?  I can see that a case can
be made for defining things that way, but it doesn't
seem desirable.

>> The value of a class is it's attributes?
>> Are you saying that attributes of an object are
>> part of its value?
>
> Either: objects have 4 aspects -- id, class, attributes, and value
> Or: attributes are included with value, so that obs have 3 aspects --
> id, class, and value.
> [Or: (Aprano) id, class, and attributes are included with value.]

Or: object attributes are considered together with class
attributes to define an object's behavior leading to:
obs have 3 aspects -- id, behavior, and value.
(The definition of "type" might be stretched a little to
make it synonymous with behavior.)

> I an not sure yet which viewpoint/formulation is the more useful. I
> answered from the 3-aspect viewpoint.  It is more traditional, but
> probably predates 'objects with attributes' as opposed to 'strucures
> with fields'.  But I suspect that the values of the fields would be
> considered the value of the structure. In any case, I have also
> considered the 4-aspect view also.
>
>> That would mean that 'a'
>> and b' below have different values?
>>
>> class My_int(int):
>>     def __init__(self): self.foo = None
>> a = int(3)
>> b = My_int(3)
>
> Yes, and indeed, a.foo raises an exception and b.foo does not.

But raising an exception is a aspect of behavior,
not of value.

> If attributes are included with value, then value must be subdivided
> into attributes and private value.  For numbers, the private value is
> the numerical value; it cannot be accessed separate from the number
> object itself.  Strings have a private value which can be exposed a
> character or slice at a time.  Numbers and strings are the two classes
> with literals.

It seems to me that what I think of as "value" is
indeed a sort of private attribute (that's how I
am trying out thinking of it.)  But it is its
privateness, its totally different way of getting
created, used, and changed, that is the very thing
that makes it unique and worthy of getting it's
own name.

>> I propose that attributes are not part of a class'
>> (or any other object's) value and that a class object
>> has no value.
>
> That is the first choice of the either/or choice above.  It is okay as
> long as it is understood that 'value' is being used in a restrictive sense.

Which seems to me to most closely match the intuitive
sense of value.  To me it is intuitive that int(3)
and subclass_of_int(3) have the same value, 3.  To
learn that their values are different because one
has an attribute the other didn't, or because the
values in a common (in name) attribute were different,
would be very surprising to me.

> Here is one reason I have not adopted it yet (and I need to make a
> choice for the algorithm book I am writing).  Consider a(b).  This means
> 'call a with argument b'.  I would rather say 'the value of a is what it
> does with b (for all possible b), which is to say, the mapping it
> implements', than to explain calling in terms of an
> implementation-dependent, essentially private, attribute structure.

I can see viewing functions in general as a mapping
of arguments values to results in the context of describing
algorithms.  I am not sure it is the best way to view
them in the context of how objects are manipulated in
the Python runtime environment.

> So I am thinking I may go with
> class: determines universe of possible values of instances and (with
> superclasses) functions such instances can work with.

If attributes are part of an object's value, that
universe is effectively infinite, isn't it?  For
the vast majority of objects (those created in
Python from a class not designed to impose bondage
and discipline by using slots for example) I can
add any attributes I wish with any values I wish
to an object.  So class doesn't really determine
much under that definition, does it?

>  'Functions'
> includes all types of syntactic expressions.

Doesn't that use of the word "function" conflict
with the already established use of "function"
in Python.  I.e., I think of functions as just
another object, albeit one with a code attribute
that the Python VM knows how to call.

I think of evaluation of expressions as a series
of method (or other callable) executions, each
returning an object that is used in the next step
of the series.

> value: determine specific result when used as argument in functions

You are prepared to redefine everything about
objects.  I was trying to restrict my redefinition
to only value.  But I see your point that the
existing definition of object does not handle
instance attributes very well either.

In comparing your definitions with mine, I think
I see a difference in view point.  It seems to me
you give greater attention to class, whereas my
mental model of Python focuses more on individual
objects.  I think I was led to that view by Python's
very dynamic behavior.  One can dynamically coerse
an A instance into behaving nearly indistinguishably
from a B instance.  So what A was before seems some-
what academic.

I tend to think of an object's class as a template
for creating new instances and a convenient place
to stash common attributes to avoid duplicating them
in each instance.  (Is this too simplistic?)  So I
think of behavior (as defined by attributes) to be
more closely related to the instance than the class.
In my model, there is not a big problem not making
a strong distinction between class attributes and
an instance's attributes -- I think of the union of
the object's attributes, its class' attributes (and
superclass attributes recursively) as all being virtually
part of the instance.

Python itself encourages this view I think.  A while
ago I tried to write an object examiner and found it
hard to figure out, in the results for inspect.getmembers(obj),
which belonged to obj, which obj's class, obj's class'
superclass, etc.  Same with dir()'s results.