Re: Alternatives languages on the JVM: which one or is there no alternative?
On 27.11.2013 06:13, Volker Borchert wrote:
Robert Klemme wrote:
On 26.11.2013 22:28, Volker Borchert wrote:
No language that is to run on the JVM can overcome its fundamental
shortcoming of missing multiple implementation inheritance.
I have come to believe that omitting things that other languages do was
actually a wise decision of the language designers. Avoiding MI might
be one of them. Granted, you cannot use implementation inheritance.
But sometimes not making these things easy is actually an advantage. At
least I think that when comparing C++ and Java. The equation might
calculate differently when comparing Java to other languages (Eiffel?).
Maybe so, but then why did the make multihreading - which is even
easier to get really wrong - so easy to use...
Probably because MT is necessary given physical limits to what a single
CPU can do.
> OO without MI is like
> a Ford Mustang with a two cylinder two stroke engine. Yes, it might
> eventually take you from A to B, but is it fun?
Why do you use Java if you dislike it so much?
Then you need a pair of setters or one setter and one method which
switches reference mode. This avoids having two fields and it avoids
"lots of duplicated code".
You still have an extra two-word object header, and you cannot use
WeakReference<T> directly if you want the Foo to act on the
reference being cleared by garbage collection. These 24 extra bytes
hurt if you are doing low-level stuff and expect some tens or
hundreds of thousands of Foo.
It's totally unclear what you mean by "low level stuff".
Why do you think Java got generally known to be slow and bloated?
Probably because a) computers had less memory and CPU power at the time
it entered the stage and b) the JVM was far less efficient than it is today.
getItem() above actually checks for assignment compatibility TWICE -
once for the instanceof and once for the actual cast. JIT should
mitigate this, but I'd still like to have dynamic_cast
What does dynamic_cast in C++ do differently? As far as I am informed
it involves a type check as well. I mean, you can have the same in Java
by catching the exception (which is what you need to do in C++ IIRC).
I do not know your notification requirements but I am sure you are aware
of ReferenceQueue.
Yes, of course, but ReferenceQueue.poll() returns the Reference<T>,
not the Foo, so for the Foo to act, you need something like
class Foo<T> {
// nonstatic inner class uzes 4 bytes for the
// implicit this$0 and 4 more bytes padding
class TPtr<T> extends WeakReference<T> {
Foo foo() {
return Foo.this;
}
}
void gced() {
}
}
Since Foo inherits Object you could as well make Foo<T> inherit
WeakReference<T> avoiding the additional bytes per instance. And it's
basically what Foo seems to be: a reference to a T - so it's actually
not too far fetched.
to do something like
...
while ((ref = queue.poll()) != null) {
((TPtr<T>) ref).foo().gced();
}
...
What does that thread do outside this loop?
How do you do that? The only way I can think of is
having an additional thread blocking in ReferenceQueue.remove().
BTDT
And why did it not work for you?
wouldn't it make more sense to let T know of its container / owner?
Why? What for?
Since Foo references the other object there seems to be a business
relationship between the two. T would then need to be bound by an
interface.
I find it difficult to discuss this without knowing more about your
requirements and situation. But then again, maybe you don't want or
cannot disclose that.
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/