Whereever I say "something is wrong", that of course only
reflects my own opinion. And this opinion is often (but not
always) a result of a misunderstanding. I'm glad if you
point those out, but please don't ever feel offended by them.
They unfortunately happen sometimes.
Some other disagreements are not about misunderstandings,
but about different views of how it should be.
Harold Yarmouth said:
Lack of methods seems like a pretty big distinction between Cloneable
(and Serializable) and "normal" interfaces.
So you do intend a special case for marker interfaces so
marker interfaces need to be explicitly "implemented", but all
others are auto-implemented if all it's method signatures exist.
explicitly implementing a non-marker interface then has only
one purpose: let the compiler make sure I didn't forget a method.
Did I get it right? If so, then I do not like it at all.
If it's still a misunderstanding, then my comment obviously
doesn't really apply to your idea.
How would you judge the *runtime* penalty of checking the existence
of all necessary methods upon each attempted cast?
Eh -- I don't read using Google, and you don't appear to have posted
this using Google, so why would Google distort it?
As Lew guessed right, it was intended for anyone who does read the
posting with google. Btw., That doesn't need to be a gmail'er, but
could be anyone just using google's news-archive at a later time,
as I've frequently done myself in the past. There is no such thing
as a private conversation in a newsgroup.
With the added proviso that extensions of final classes can't see their
protected fields and methods. Essentially, "protected == private if the
class is final" would be maintained.
Yes (furthermore leaving aside the "same-package" special case).
I'd even go further to do this regardless of final'ity
of the wrapped class. It doesn't seem right to me for a
class that *doesn't really* subclass a given class to still
access it's more-restricted bits.
Verbiage alert. This is a slight modifier that would be very
common on reference declarations,
In some way you're right, but Joshua also made a good point
recently by quoting a sample of some new keyword-less syntax
of some "newer C++": just seeing the new syntax makes it
almost impossible to look it up in order to get to know
what it means.
As soon as some keyword or other constant verbiage is used,
it becomes possible to look it up.
However, there are new problems I see with it (non-nullness) now:
Assume I wanted to use a HashMap<String,Integer*> I'd expect it
to only contain non-nulls, but get() would still produce nullable
values, as it returns null for unknown keys. HashMap's implementation
is ofcourse not aware of whether it's Value type is nullable, so it
has no clue as to how to declare it still-nullable when it returns
the Type parameter or null. There may exist solutions, but I fear
it's getting more and more complex, rather than just the simple
nonnull marker you started out with.
String*[] noNullsArray = array; // Runtime check that no element
// is null gets generated here.
Huh!? I thought the whole point of it was to guarantee null-freeness
at compile time.
Compare it with ClassCastExceptions: they can only be thrown at explicit
casts (implicit casts are only possible where no runtime-check is necessary)
Alternative: new method in java.utils.Arrays such that
noNullsArray=Arrays.nonNull(array);
will assign the instance only after a successful runtime nonnull check
(otherwise throw a NullPointerException immediately)
String*[] another = {"Foo", "Bar", "Baz"};
Ok, that's fine, but a special case (only hardwired number
of elements possible).
Of course we could get into hairiness with noting whether the array
reference itself can be null:
String*[]* -- which * means which?
That will need some more and better ideas, expecially also for
multidimensional arrays (i.e. arrays of arrays of arrays ...).
I like the principle, though.
The cases I was thinking of are e.g. [...]
catch (IOException _) {
.... = new ...() { public void actionPerformed (ActionEvent _) {
These cases hardly ever accumulate, but if they do, there's still
"__" and "___" and ... as further dummy names.
(I admit that these cases were not covered by my previous arguments.)
I'm just asking for
Map<Key,Value> map = new HashMap();
without any need to repeat the <Key,Value>, that's all!
Sorry, my misunderstanding once again.
I think I've read that this particular syntax will indeed
be added in 7.0 (regardless of this discussion here).
StringBuilder sb = new(10);
I don't like that at all.
classes be both uninstantiable and unsubclassable. As things stand, you
have to put a private no-argument constructor in, which says the same
thing as "final" but in a much more verbose and less readable manner.
My point is that I see no relevant need to prevent anyone from
instantiating or subclassing a Utility class, e.g. like java.lang.Math.
What bad could one do with it, if it were possible?
Playing around I tried this ugly idiom:
class Test { static Math m; static { m.sin(m.PI); } }
interestingly the bytecode contains "getField m"
immediately followed by "pop".
I think you've misunderstood me. The point was that this would be a
corner case, where the compiler would think that an exception could be
thrown somewhere where it actually wouldn't occur for exactly the
reasons you state.
What did you mean should actually happen to checked exceptions
thrown within run() (and not caught there)?
Why not just least common denominator?
Because such an array may not be compatible with what I want to use it
for:
void foo(Number[] a) ...
foo({1,2,3,5,8,13}); // wouldn't work, because the auto-inferred
type would be Integer[] which is not castable to Number[].
It's a generalisation. it's about like
try { ... errors caught }
continue { ... errors not caught }
tryalso { ... errors caught again }
continue { ... errors not caught }
tryalso { ... errors caught again }
catch ...
finally ...
except it could be even nested:
try {
for (...;...;...) { // loop header may throw excs to be caught.
dontcatch { doSomething(); } // propagate all errors from that call.
}
} catch (...) { ... } finally {...}
I don't think I'd need the feature myself, but it does
appear to have an aura of usefulness
Someone else would have to find a better verbiage for it.
Oh, and the finally block would still need to be executed
even if it was doSomething() that threw an exception.
The existence of IdentityHashMap is proof that someone at Sun also
thought that such a thing could be useful. They just didn't generalize it.
That's a very very special and otherwise rare usecase (serialization helper).
Don't let my opinion against it discourage you.
ReferenceQueue already exists and somewhere there is code that enqueues
references on them. So the "hooking into the GC" at issue here is
already being done.
Sun did a few special tricks to prevent users from hooking in.
I do not exactly understand Sun's reasons for that, but it most
definitely hasn't just been forgotten - it has actively been
worked against by sun.
As it is, I think the effect can be achieved by making a Thread that
calls the blocking poll method
There is no blocking poll for the ReferenceQueue, and also no way to
create one as derivative. The thread would have to run a busy loop
(yuck!).
Referring to the enum implementation, which has the enum constants
actually singleton instances of same-named subclasses.
Thanks for explaining. I really didn't know that.
Not on disk, no, but there are four classes in the system at runtime;
some ClassLoader magic sees to that.
Strange. I utterly fail to see the reason behind that.
The case I could imagine was a SubEnum, that allowed a free
selection of a subset of BaseEnum's instances, and otherwise
behaves like a wrapper based on my own class-wrapper proposal
(messageid [still quoted somewhere above] ).
Wrap, reduce range, or both. Yep.
* Now finally, I add one more idea to the list:
Distinguish between "using" and "implementing" an interface with
respect to accessibility.
The point being to allow to publish an (internal) interface
for return values (cookies), that foreign code may use as type
for variables, but not in "implements"-lists for classes.
There's already a few other ways to do this:
But none of them (including even my WeakHashMap approach)
allow checking at compile time, as the proposed change would.
