Re: Clean Object Class Design -- Circle/Ellipse

bbadour_at_golden.net (Bob Badour) wrote (abridged):
> Let's see if I can decipher what you are saying. Are you claiming that
> the reference identifies some location that has contained the
> representation of the same value since the big bang?

No. I am saying that a Smalltalk variable that contains the number 5 is not referring to a location at all. There is only one location involved, that of the variable itself. We don't need a second location to store 5 in, because 5 is a value. Smalltalk variables don't have to refer to locations. They can refer to pure values (ie objects) directly.

> Not according to the ANSI definition of the language. The value at
> that location or offset is itself a reference to a variable.

No. ANSI says that variables refer to objects. This idea that objects are always variables are something you have invented yourself. It is not in ANSI. ANSI does not say that variables refer to variables.

> I don't recall the standard specifying that "byte" is an object
> anything.

See 3.3.2.1. A byte is a small integer. Integers are objects. We can send messages to bytes. An object is defined as something we can send messages to.

> > a := 2 + 4.
>
> Since instances of SmallInteger are stateless, am I to infer that 'a'
> is not an instance of SmallInteger?

Correct. 'a' is a variable. Variables are not objects, and so not instances of any class. This variable happens to be attached to an instance of SmallInteger, but it is not an instance of SmallInteger.

> How does Smalltalk represent 6 differently from 7 without state?

They have different identities, or different values if you prefer.

> > Assignment is always an operation on a variable, and messages
> > are always sent to objects. We cannot assign to objects.
>
> I agree that assignment is always an operation on an object variable,

Not what I said. "Object variable" is just confusing here, a contradiction in terms. Variables are not objects. We cannot assign to objects.

> and messages are always sent to object variables.

Again this conflating of "object" with "variable" is confusing. We cannot send a message to a variable.

> We cannot assign to object values. We can, however, assign to
> the instance variables of an object variable.

If an object has instance variables, we can assign to them. That is an example of assigning to a variable. We might reasonably say that an object with instance variables is mutable, but calling it an "object variable" is confusing two terms with very precise, and different, meanings. Further it says nothing about objects which do not contain instance variables.

> How do we make the object instances immutable assuming we can use the
> setFoci or the setMajorAxis operation on Ellipse variables?

You are contradicting yourself. Either they are mutable or they are not. If they are, then they are not subtypes. This has little to do with the language.

> > > > C++. In C++ 5 is an rvalue, meaning it does not have an address.
> > > > It is not a variable.
> > >
> > > In C++, it is not an instance, either.
> >
> > True, but irrelevant.
>
> How is it irrelevant

Because the same rules apply to instances. For example:

    class Complex {

        double r, im;
    public:

        Complex( double r, double im );
    };

   Complex *p = &Complex( 1, 0 ); // Illegal.

The last line will not compile in ANSI C++ because Complex(1,0) is an rvalue. We cannot take its address for the same reason we cannot take the address of 5. Rvalues do not have addresses.

As you point out, this rather conflicts with the notion of a "this" pointer. That is why I say C++ is confused. C++ also has the notion of "const" - in fact, it has 2 kinds of "const". This further confuses the matter. (The temporary Complex(1,0) isn't const according to either of them.) And it has references as well as pointers, which is another complication.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,

      brangdon_at_cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed