Re: Issues with the logical consistency of The Third Manifesto

> Actually, an object is always a value, and simultaneously always a
> variable (assuming it has any mutable fields.)

Don't forget references, which are variables on which operations are invoked. Operations are almost always delegated to the "valuable" (value/variable) instance to which the reference points, of course.

> It is also always a conceptual entity. But this is such triviality
> that I've never seen anyone bother to mention it. No one is
> *confusing* values and variables; an object is both, and which
> one we are talking about is, most of time, immediately obvious.

I disagree. I think there's more confusion than you'd like to believe, and furthermore that it's very easy, even for experienced programmers, to unknowingly attempt to treat instances as both values and variables. Look for "aliasing" on citeseer - this is a serious problem, and I've run into it on many projects.

> There *is* an issue with the difference between equality and
> identity in OOP, but this is fairly easily mastered by beginners.

A moment to learn, a lifetime to master - if mastery is possible. This is an ugly concept, of little value in my opinion. Perhaps caches and other "manager" services can use this, but I think this is a hack.

> Yes, but this doesn't matter. There are specific models associated
> with each specific OOPL, and they are quite well documented
> down to the last detail. There are also substantial commonalities
> among the different models.

I agree, but I also think the models are weak to have allowed such aliasing. For example, the Java new keyword makes a hard (and unnecessary) distinction between value CREATION and value SELECTION (a la Third Manifesto). Hence the frequent use of static methods to return new (or shared) instances, factory patterns, etc. Yes, all that may be admitted by the model, but that don't mean it's a good idea.

> > They know that to bundle operators with a single type is not a good
idea.
> The binary method issue? This is again a fairly unimportant issue.

Perhaps, but it leads to nonsense like double-dispatch and Visitor patterns - more hacks around language failings. It forces an abritrary choice that also limits builds, deployment, and configurations.

> Does they have methods specific to the specific join? I think
> that is what the guy was referring to. Ideally this would be
> done dynamically, not via code generation

If you generate proxies or class dynamically, based on the most-specific type of the relational expression, then how can the function be assigned to that combination, in the absence of a predefined class name? I'm a little confused here...

• erk