From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5af5c381381ac5a7 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news4.google.com!feeder2.cambriumusenet.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.84.MISMATCH!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!news.tele.dk!news.tele.dk!small.news.tele.dk!feed118.news.tele.dk!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Newsgroups: comp.lang.ada Subject: Re: Ada requires too much typing! References: Date: Tue, 08 Jun 2010 08:43:10 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Martin Krischik" Organization: Martin Krischik, Softwareentwicklung Message-ID: User-Agent: Opera Mail/10.53 (MacIntel) NNTP-Posting-Host: 89.236.175.138 X-Trace: news.sunsite.dk DXC=@nh:2QALlcHB^D;0lZCOUDYSB=nbEKnkKabQiRL9@gYMIDiY_4:UK?Cd3Nai^>E:QM5D2e^5VLiC>9F0Cg?Uc_AaUD X-Complaints-To: staff@sunsite.dk Xref: g2news1.google.com comp.lang.ada:11457 Date: 2010-06-08T08:43:10+02:00 List-Id: Am 07.06.2010, 20:30 Uhr, schrieb Luis Espinal : > In article , 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