I think you didn't understand me.
When you have:
class Base {}
class C extends Base {}
and you write:
val b:Base = ...;
val c:C = b as C; // this does normal casting (like in Java)
That's what your code does (the compiler prefers the normal casting ala Java
over the user-defined casting),
and if the dynamic type of "b" is not C, then it will throw
ClassCastException (which it does).
There is no bug in the compiler or runtime, but the behavior is tricky and
not trivial to understand.
I actually have an easier solution for you:
Don't use user-defined "as" operator.
They don't exists in Java, and I personally believe that they only cause
confusion.
You can just define your own static/instance methods that knows how to
convert a base object to type C.
Cheers,
Yoav
2011/2/9 Kröhnert, Manfred <manfred.kroehn...@kit.edu>
> Hi,
>
> Am 09.02.2011 um 15:44 schrieb Yoav Zibin:
>
> > It's a spec thing, and the compiler is doing the right thing:
> > The normal casting takes precedence over user-defined casting.
> >
> > Bard, please update the spec and specify priorities for casting:
> > - if a regular (java-like) casting can be done, we do that.
> > - otherwise we try user-defined casts
>
> thanks for the information.
>
> > for example:
> >
> > public class Hello
> > {
> > public static def main(Array[String])
> > {
> > val b1:B = new B();
> > Console.OUT.println("b1 as C: " + b1 as C); // Must use the
> > user-defined casting, so we get: b1 as C: C@a32b
> > val b2:Base = b1;
> > Console.OUT.println("b2 as C: " + b2 as C); // Can use the regular
> > casting, so we get: x10.lang.ClassCastException: C
> > }
> > }
> >
> > protected class Base
> > {
> > public static operator (base: Base) as C = new C();
> > }
> > protected class B extends Base {}
> > protected class C extends Base {}
>
> Ok, but that is not the original intent of my sample.
> There each class knows how it can be cast to type 'C'
> which is specified in the polymorphic 'asC()' method.
> The 'asC()' method is then called in the static cast operator.
>
> I am only using the approach with the polymorphic method
> because non-static cast operators which can be overridden
> in subclasses didn't work for me.
>
> So the problem I am having is that I don't understand why the cast should
> fail when I specified that it is possible and how to do it.
>
> > PS
> > Your examples always gives me the same output:
> > $ x10 Hello
> > b: 15
> > b as C: 42
> > c: 51
> > c as C: 51
> >
> > b2: 15
> > b2 as C: 42
> > c2: 51
> > c2 as C: 51
> >
> > b3: 15
> > x10.lang.ClassCastException: C
> > at x10.rtt.Types.cast(Types.java:338)
> > at Hello.main(Hello.java:117)
> > at Hello$$Main.runtimeCallback(Hello.java:26)
> > at x10.runtime.impl.java.Runtime$3.$apply(Runtime.java:109)
> > at x10.lang.Runtime$$Closure$144.$apply(Runtime.java:4138)
> > at x10.lang.Activity.run(Activity.java:594)
> > at x10.lang.Runtime$Worker$$Closure$137.$apply(Runtime.java:1347)
> > at x10.lang.Runtime.runAtLocal(Runtime.java:215)
> > at x10.lang.Runtime$Worker.loop(Runtime.java:1055)
> > at x10.lang.Runtime$Worker.$apply(Runtime.java:988)
> > at x10.lang.Runtime$Pool.$apply(Runtime.java:1659)
> > at x10.lang.Runtime.start(Runtime.java:2368)
> > at x10.runtime.impl.java.Runtime.$apply(Runtime.java:87)
> > at x10.runtime.impl.java.Thread.run(Thread.java:48)
>
> Yes, it always gives the output shown above.
> But instead of the ClassCastException I would expect the output of the last
> section to look like this:
>
> b3: 15
> b3 as C: 42
> c3: 51
> c3 as C: 51
>
> Thanks for your time and best regards,
>
> Manfred
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> X10-users mailing list
> X10-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/x10-users
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
X10-users mailing list
X10-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/x10-users
