Re: Ada requires too much typing!

["Martin Krischik" <krischik@users.sourceforge.net>]

Am 07.06.2010, 20:30 Uhr, schrieb Luis Espinal <Luis_member@newsguy.com>:

> In article <op.vdvcs3b5z25lew@macpro-eth1.krischik.com>, Martin Krischik  
> says...
> Not having the C++ equivalent of const member
> functions and const return types can be quite hurtful, too.

cost is a reserved word in Java. That's for future use as keyword. So is  
goto ;-).

>
>> And if we are at it - setter functions should use «this.x = x.clone  
>> ()».
>> Those who did Ada or C++ know that. In Ada setter and getter functions
>> usually take a copy and in C++ setter and getter functions take a
>> reference to a constant object. That is: not the reference is constant -
>> the object itself is constant (un-mutable).
>>
>
> You are going to have forgive my C++/Ada peasantry since I haven't  
> touched
> either for more than a decade (since I left grad school.) Why exactly  
> would we
> want (in Java) to return a clone wrt to a setter/getter?

I thing this example should explain it:

java.util.ArrayList evilChange = someInstance.getPreciousList ();

evilChange.clear();

O course retuning a const would protect just as good and render better  
performance.

Having immutable object like java.lang.String helps as well.

> By default, we have to assume that if a getter returns a reference to an
> instance of a class that is not immutable (.ie. extensions of  
> java.lang.Number
> or String), then we have the ability to modify it (while still being  
> part of the
> enclosing class exposing the getter method.)

In Java. Most other OO languages see that differently. The OO principle is  
the the internal state of a class can only be changed true a setter. If I  
have a state called preciousList you should not be able to change  
preciousList using getPreciousList(). You should do so be using  
setPreciousList(), setPreciousList(int) or appendPreciousList().

Why? For example my class states are usually bound. If you get the list  
and change it behind my back the observers are never notified of change.  
The hole observer/notifier pattern collapses. And with it the  
model/view/controller pattern. And eh voila what is shown in the view is  
not what is stored data access object and a difficult to find bug in the  
middle.

> That's the default modus operandi. Anything else (returning a deep or  
> shallow clone, for instance) has to be explicitly documented.

This in my eye is turning a fault into a virtue.

> only do so in Java by convention and by structuring our classes as either
> mutable and immutable (the later being Scala's route.)

immutable data access objects?

>> As it is most setter and getter functions in Java are placebos - they  
>> give
>> you you the feeling to do it the proper OO way but you are don't!

> I'm not sure I follow here either. I'm saying this genuinely, and I'd be  
> happy to see your POV on this subject.
>
> To me a chain of calls P.getQ.getR...X.getY.getZ is simply a chain of  
> messages
> from the caller to an given entity(Z) all the way through different  
> contexts.

That's ok. What I argue is that the following should not be allowed:

P.getQ.setR(…)

It should be:

q = P.getQ
q.setR(…);
p.setQ(q);

And the simplest of all examples are bound properties (that's  
observer/notifier pattern for non Java developers). If you do the first  
then the observers of P are not notified. of the change to Q.  I would not  
be surprised if observer/notifier was considered an anti pattern in Java  
[1]. That again would be turning a fault into a virtue. Observer /  
Notifier worked marvellously great in the IBM open class (C++).

> ps... I'll add to the discussion that one thing we sorely miss in Java  
> is the
> ability to write nested functions as in Ada, Pascal and ALGOL. IMO they  
> lead to
> cleaner, more organized code.


int f ()
    {
    class c
    {
       int g ()
          {
          …
          };
    }

    c i = new c();

    return i.g();
}


just about as painful as using local packages to add static variables to  
Ada procedures.

Martin

[1] Like the singleton pattern. I read the rationale why singleton is  
considered an anti pattern and it was all about Java quirks which do not  
apply to Ada or C++. Still the Java advocates cry “anti pattern”. For me  
anti pattern need to be anti pattern in all (or at least most) programming  
languages.

PS: I am doing my SCJD  right now. I think the assignment has been  
specificity designed to make you hate Java. Or maybe I should not have  
chosen rmi over socket communication after all...

-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik