Call chains with objects that implement Dynamic... about hxcpp HOT 8 CLOSED

I do not think that:
a->resolve("b")->resolve("c")
is possible from the AST, because there is no way to tell the type returned from resolve("b"). I think it should be returning the instance of B, which should then handle the __Fields call by falling back to resolve if all else fails for the implements Dynamic case.

I guess this is equivalent to:

var a:Dynamic = new A();
trace( a.c ); // Should call resolve

That is, build it into the runtime rather than relying on haxe typing.

from hxcpp.

So would you suggest it just doesn't call super._Field?

or instead have it write out (if it implements Dynamic)

Dynamic lastResort = super.__Field();
if (lastResort == null) return resolve_dyn;

from hxcpp.

There is a problem with the fact the "null" nay be a legitimate value.
Currently, cpp and neko give the same result for this:

class Test implements Dynamic
{
   public function new() { }

   public function resolve(name:String) : Dynamic { return "resolved " + name; }

   public static function main()
   {
      var t = new Test();
      trace(t.x);
      var d:Dynamic = t;
      trace(d.x);
   }
}

That is, "resolved x" and "null".
Cpp can be made to give the desired result by changing the base __Field (Object.cpp) call to look for the resolve func:

Dynamic Object::__Field(const String &inString, bool inCallProp)
{
   // Will be true for 'Implements dynamic'
   if (inCallProp && __GetFieldMap())
   {
      Dynamic resolve = __Field(HX_CSTRING("resolve"), false);
      if (resolve.mPtr)
         return resolve(inString);
   }
   return null();
}

I am tempted to make this change even though it diverges from neko output.

from hxcpp.

This is a design question. On the one hand it makes sense to expect resolve to be considered even when accessed through Dynamic. On the other hand achieving this consistently would mean a lot of trouble for dynamic targets because any field access could be one made to a class which has a resolve method.

In summary I would prefer to not introduce target inconsistencies here.

from hxcpp.

Well, there you go. It is a compile-time thing so you must cast the intermediate result. Personally, I would prefer cpp to have the more useful solution.

from hxcpp.

I wonder if we could encode in the type system that a resolve method returns a type which itself has a resolve method, rather than plain Dynamic. Instead of implements Dynamic you would have implements Dynamic<Something with a resolve method>.

from hxcpp.

I agree with Simon : we don't want to introduce a platform specific runtime solution here.
We could add support in Haxe compiler for the following, but it would only work if of the resolvable fields of A have a resolve() method:

typedef Resolve = { function resolve( name : String ) : Resolve; }
class A implements Dynamic<Resolve> {
}
class B impements Dynamic<Resolve> {
}

a.b.c will be a.resolve("b").resolve("c")

However you would have to have the whole access chain resolved. You would not be able to access core class fields this way, for instance if c is an Array, accessing a.b.c.length would make a runtime error because of the missing resolve on c.

You could still create "resolvable wrapper" in your B.resolve, not sure how practical it would be, I guess it highly depends on the actual problem you're trying to solve.

from hxcpp.

Since the resolve function is not typed, it is only syntactic sugar you are
missing by not using "resolve" explicitly. So today
a.resolve(b).resolve(c).length should work. Even a.b.resolve(c).length.
This seems a reasonably easy work-around.

Does javascript have some kind of native member resolving? If so there
would be a precedence, and c++ could just do it since there would already
be some inconsistency.

On Sun, Feb 16, 2014 at 5:48 PM, Nicolas Cannasse
[email protected]:

I agree with Simon : we don't want to introduce a platform specific
runtime solution here.
We could add support in Haxe compiler for the following, but it would only
work if of the resolvable fields of A have a resolve() method:

typedef Resolve = { function resolve( name : String ) : Resolve; }
class A implements Dynamic {
}
class B impements Dynamic {
}

a.b.c will be a.resolve("b").resolve("c")

However you would have to have the whole access chain resolved. You would
not be able to access core class fields this way, for instance if c is an
Array, accessing a.b.c.length would make a runtime error because of the
missing resolve on c.

You could still create "resolvable wrapper" in your B.resolve, not sure
how practical it would be, I guess it highly depends on the actual problem
you're trying to solve.

Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-35181122
.

from hxcpp.