abstract static methods (again)

T

Tomas Mikula

Isn't that a violation of the fundamental semantic of 'static' as
"class-wide, does not use an instance to resolve"?

(Yes, it is.)

This is not a compile-time vs. run-time matter, despite your attempt at
misdirection. The semantic of 'static' applies at run time and compile
time, both. It means "class level". You suggest using an
instance-level semantic to resolve the meaning of a 'static' construct.
That is too fundamental a change.

I will just note that it would be using an instance of a different class
than whose static method is called. This instance would be used to obtain
the class. After that, the invocation of it's static method would not use
any instance-level semantics. The code

class MyClass<V extends Vector<V>> {
void doSomething(){
V v = V.zero();
}
}

could be translated to something like

class MyClass<V extends Vector<V>> {
void doSomething(){
// get the class (uses an instance of MyClass, namely 'this')
Class<V> clazz = Class.getTypeParameterClass(this, "V");

// invoke the static method (no instance of V used)
V v = clazz.getMethod("zero").invoke(null);
}
}
 
T

Tomas Mikula

posting-account=pAbxHwoAAAADCfRr12ntKYVMSzbDntdj



I anticipated shortly after posting that your Vector example might be
what you were getting at. Here's how I think it would go (assuming
reified generics). Your original declaration:

class MyClass<V extends Vector<V>> {
public void someMethod(){
V v = V.zero();
...
}
}

So, on some class whose full implementation you don't know about, you
expect a (V zero()) method - so define an interface type for that:

interface Zero<V> {
V zero();
}

Now express two constraints on the type provided to MyClass:

class MyClass<V extends Vector<V> & V extends static Zero<V>> {
public void someMethod(){
V v = V.zero();
...
}
}

Does that work for you?

Yes, that would work for me. But you need to add a new syntax, namely the
'&' in the generic parameters.
 
A

Andreas Leitgeb

Tomas Mikula said:
I was aware of this simple and only example where the convention can be
checked at runtime quite concisely. What if I want to use another
constructor and, say, two static methods. Things get a little messy.

The task itself is messy, and reflection is the tool designed to handle
the mess :) . Any other tool wouldn't be less messy, but they might
move the mess somewhere else - e.g. create wrapper-classes to do the
static calls.

About this "each class (of some hierarchy) must provide its own
implementation of certain static methods" thing:

This is obviously even stricter as abstract virtual methods, which, once
implemented are inherited by subclasses without them having to reimplement
again. Is it just the factory-pattern, that drove you to this idea, or
are there also other patterns that you think would benefit from enforced
static method implementations? Or is it perhaps just a first step before
requesting also special virtual methods that need to be overridden in
each subclass?
 
A

Arved Sandstrom

Andreas said:
You may of course do that, but that doesn't put any
constructor *requirements* upon the subclasses.
I was way too tired when I wrote that. :)

AHS
 
A

Arne Vajhøj

Andreas said:
Oh, nice! Yet another extra indirection!
Wasn't there some "computer law" that said, that any problem can be
addressed (but not necessarily solved) by adding another level of
indirection?

Yep.

I can not find the source, but it is something like:

"There is no coding problem that can not be solved nicely
by adding another abstraction layer and no performance problem
that can not be solved by removing an abstraction layer."

It is not true, but it definitely has a good point.

Arne
 
A

Arved Sandstrom

Arne said:
Yep.

I can not find the source, but it is something like:

"There is no coding problem that can not be solved nicely
by adding another abstraction layer and no performance problem
that can not be solved by removing an abstraction layer."

It is not true, but it definitely has a good point.

Arne

The point being, too much of a good thing is bad. A very basic
abstraction layer is a single function/method/procedure: apart from the
code re-use issue we typically also elect to use methods so as to hide
implementation details. Used judiciously methods are great, but when
overused you tend to stop understanding the code.

Performance I am less worried about. I judge abstractions by their
impact on maintainability of code during design, implementation and
production use. If their positives don't outweigh the negatives then why
are they there?

AHS
 
T

Tomas Mikula

I have implemented a subset of the proposal with the @ImplementsStatic
annotation. Only later I found Stefan Schulz's blog entry where he
proposed the same. So his code will probably be similar, but I haven't
found it anywhere. Anyway, I created a project
http://code.google.com/p/implementsstatic/
where you can find the code and brief user's guide and examples.
 
T

Tomas Mikula

Is there any reason you need a second field in your annotation for the
generic type parameters? Since they might have parameters of their own,
and you deal with these by inserting them into the same array (as if by
in-order traversal?), could the original type parameters not be
similarly inserted into the main array?

You are right, they could be inserted into the first array. The reason
was that my initial idea was to have yet another array of Strings as
formal parameters that would match to the annotated class's formal type
parameters, like in this example:

@ImplementsStatic(
value={Map.class},
actualTypeParameters={Integer.class, Anything.class},
formalTypeParameters={ "" , "T" }
)
class MyClass<T> {
...
}

The above would be equivalent to

class MyClass<T> implements static Map<Integer,T>

Then I realized that static methods don't inherit the class's type
parameters, so this would be meaningless, yet the actualTypeParameters
array remained there.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top