Ada requires too much typing!
in [ADA]
|
Prev: Lost in translation (with SPARK user rules)
Next: Sockets package in SPARK (Was: Lost in translation (with SPARK user rules))
From: Yannick Duchêne (Hibou57) on 6 Jun 2010 00:25 Le Sat, 05 Jun 2010 22:13:46 +0200, Luis Espinal <Luis_member(a)newsguy.com> a écrit: > You didn't have to drop your previous investment in AS/400 machines, for > example. You could run your Java apps there, and as you buy new hardware > (almost > any type of hardware) when you needed to scale up (again, w/o having to > throw > away your previous machinery.) OK. > Google is implementing a different > java virtual machine called Dalvik for the android platform. Dalvik's is > register based whereas Sun's is stack-based. On the margin: I suppose then it will use a kind of âlink registerâ for recursivity and a kind of âlocal data pointer registerâ for locals (funny). > Not to belittle Java's contribution, but it seems that in the long run, > Sun's > long lasting legacy will be its Java virtual machine instead of the Java > language itself. > > - Luis. That is indeed what I feel I have understood after this thread (just wonder how SUN will react in the future, ... I mean, economically, as this is most of time a matter also) -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: Martin Krischik on 6 Jun 2010 04:06 Am 28.05.2010, 07:25 Uhr, schrieb Luis Espinal <Luis_member(a)newsguy.com>: > I don't think that is much of an issue. Mutability is. This is a big > issue for > Java as it has turned out. The commonly accepted best practice now is to > mark > variables and parameters as final unless you know before hand that you > want to > change them. Which only makes the reference to the variable un-mutable, not the content. That combined with language which can do only pass by reference for all complex types and a Clonable interface which was badly sorted out gives you a language where the protection a getter function should give you is just not there - unless you make it a habit to use «return x.clone ()» [1]. 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). 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! Martin [1] provided the class at hand implements the Clonable interface property and does indeed do full deep copy. -- Martin Krischik mailto://krischik(a)users.sourceforge.net https://sourceforge.net/users/krischik
From: Martin Krischik on 6 Jun 2010 04:55 Hi Luis, Am 01.06.2010, 23:30 Uhr, schrieb Luis Espinal <Luis_member(a)newsguy.com>: > Some people still think this is still a better trade-off over C++ styled > multiple inheritance because of the dreaded "diamond" problem. which is easily solved by marking classes virtual. One should just make a habit of defining classes like this: virtual Base { public: virtual ~Base () { … } } And suddenly all your virtual inheritance needs work flawlessly. There are just too many C++ programmers out there who do not know that. > That's a lot of manual shamanism that should be better dealt with > syntactically. As I mentioned before: true Shamans (yes they still exists, mostly Siberia) work a lot with poisonousness substances. If they make a mistake then either they or there customers end up dead. Comparing computer science with shamans is an insult to the professional work of shamans. Martin -- Martin Krischik mailto://krischik(a)users.sourceforge.net https://sourceforge.net/users/krischik
From: Simon Wright on 6 Jun 2010 06:13 "Martin Krischik" <krischik(a)users.sourceforge.net> writes: > One should just > make a habit of defining classes like this: > > virtual Base > { > public: > virtual ~Base () > { > … > } > } > > And suddenly all your virtual inheritance needs work flawlessly. I suppose there must be some cost to doing this? or the language definition would require it to be always so.
From: Dmitry A. Kazakov on 6 Jun 2010 07:03
On Sun, 06 Jun 2010 11:13:46 +0100, Simon Wright wrote: > "Martin Krischik" <krischik(a)users.sourceforge.net> writes: > >> One should just >> make a habit of defining classes like this: >> >> virtual Base >> { >> public: >> virtual ~Base () >> { >> �K >> } >> } >> >> And suddenly all your virtual inheritance needs work flawlessly. > > I suppose there must be some cost to doing this? or the language > definition would require it to be always so. Yes, in C++. No, in Ada, if Ada supported by-value classes. Since in Ada T /= T'Class you need not put as in C++ the type tag into the object. You could put the tag only into T'Class and leave T as is. You would lose view conversions T <-> T'Class, but they don't have sense for by-value objects anyway. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |