Martin C. Martin schrieb:

well, if the rhs type is known and the lhs has a type, then we could check if the types are assignable, because you can not change the assignment at runtime. But to what cases would this apply to?

int i="aa"

the rhs is a constant, so we know the type for sure, we could throw an error here.

int i = foo()

In this case you would normally use the return type of foo() to do the check, but we that type is always to take of a grain of salt. If foo returns Object, then the cast may succeed, if foo() return String, hen it still might be replaced at runtime... We can't be sure if it will fail.

int i = j

in this case, if j is a local variable, we normally have a type, and we could say if j is a String we can throw an error. If j is an Object we can not. If j is a field, the same logic applies and if j is a property, then we can't do anything, because it is just like a method call.

So as I see it such a check is possible in some cases, but they are not very useful. We could check assignment of constants, local variables and fields.

[...]

because such a call could not be influenced by any dynamic mechanism we have. I am not saying I do not want that, but we must be careful how to do something like that.

I am not checking the types in case the programmer makes a mistake, I must check the types, because the runtime type might differ form the expected type. For example if you declare something to be Object, then it could still be a String or a JFrame or whatever. If I now call a method that is overloaded with a String parameter, then I have to call this method instead if my argument is a String.

Of course I am concerned about performance, but in the first place I am concerned about correctness. Of course, if the method call is annotated or something so that the normal logic does not apply, then we can do other things, but such an annotation is a syntactic element that is always not so easy to add. You see there are two levels here, the implementation and the syntax. A change to the implementation is easy, as long as the semantics are the same. A change to the syntax is not easy, because it must fit into many heads. Take the annotation Alex proposed for example. No developer is against enabling direct calls if they are marked and recognizable and such. But to be recognized you need a syntax and the syntax is the problem.

So I am trying to make the implementation side faster, which reduces the need for such a syntax.

bye blackdrag

-- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.com/

--------------------------------------------------------------------- To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email