Attention Library Maintainers!

[Hugh]

I have just committed a change to the haxe compiler, which will show up in the 3.2 compiler release, and will break code that tries emulates flash native properties, or uses properties on Dynamic variables.

Now, if you access a property via an untyped variable (Dynamic), the property wont get called in hxcpp by more.  This matches the neko behaviour.

Library maintainers now need to explicitly tag either the whole class or the particular property with "@:nativeProperty" metadata.

Developers using the library can use the haxe define "-D force_native_property" to restore the 3.1 behaviour for the transition period, but it is recommended that each of the classes be tagged.

Hugh

[Lars Doucet]

Can you give an example of what you mean?

Is it this?

var myThing = new Dynamic();
myThing.whatever = "something";

Or this?

var myThing:Dynamic = existingObject; //say existingObject is class Foo with string property bar
myThing.bar = "something";

I assume you mean the latter but I just want to be sure. And in that case I would need to tag class Foo with "@:nativeProperty" from then on? And "@:nativeProperty" is meant to stick around, not just a transitional property like "-D force_native_property" ?

[Simon Krajewski]

Am 28.02.2015 um 20:03 schrieb Lars Doucet:

Can you give an example of what you mean?

Is it this?

var myThing = new Dynamic();
myThing.whatever = "something";

Or this?

var myThing:Dynamic = existingObject; //say existingObject is class Foo with string property bar
myThing.bar = "something";

I assume you mean the latter but I just want to be sure. And in that case I would need to tag class Foo with "@:nativeProperty" from then on? And "@:nativeProperty" is meant to stick around, not just a transitional property like "-D force_native_property" ?

Yes.

Simon

[Lars Doucet]

What are the benefits of this change? Is this just to bring things in line with neko's behavior, or does it give us more performance or some other benefit?

On Saturday, February 28, 2015 at 12:52:11 AM UTC-6, Hugh wrote:

[Hugh]

No there is absolutely no benefit to hxcpp targets - there is now extra code in there to cripple the hxcpp feature and it is a step backwards.

However, if neko, js and flash are changed to be consistent with this metadata, then the haxe language as a whole will be better off.

Hugh

[Lars Doucet]

I see. Well, thanks for the heads up!

[Simon Krajewski]

Am 01.03.2015 um 02:33 schrieb Hugh:
> No there is absolutely no benefit to hxcpp targets - there is now
> extra code in there to cripple the hxcpp feature and it is a step
> backwards.

Let's be fair here: The one yet very important implicit benefit is that
there are less cases where users switch code from another target to
hxcpp and come across a different behavior.

However, I understand that people who use hxcpp exclusively are "pissed
off" about this change because now assigning something to Dynamic can
change behavior. Still, I would just like to point out that that's how
Haxe properties have been designed and documented from the start.

Simon

[Sven Bergström]

HXCPP_ALLOW_DYNAMIC_PROPERTY_I_KNOW_WHAT_IT_MEANS_THANKS

[Nicolas Cannasse]

Le 02/03/2015 05:25, Sven Bergström a écrit :
> HXCPP_ALLOW_DYNAMIC_PROPERTY_I_KNOW_WHAT_IT_MEANS_THANKS

We don't want to introduce flags that globally affect compilation, or
else if you require it for your library you will end up affecting third
party libraries as well, introducing bugs.

Best,
Nicolas

[Hugh]

This is there "-D force_native_property", although I suspect JS will never respect this, while it may one day respect the @:nativeProperty meta.

In the real world, I would be amazed if this define did anything other than make the code work better.

Hugh

[Nicolas Cannasse]

Le 02/03/2015 13:51, Hugh a écrit :
> This is there "-D force_native_property", although I suspect JS will
> never respect this, while it may one day respect the @:nativeProperty meta.
> In the real world, I would be amazed if this define did anything other
> than make the code work better.

Yes, but this should only be transitional, I don't think we will keep
that in the long term.

Best,
Nicolas

[Joshua Granick]

On the subject

I have had serious problems using Reflect.setField and Reflect.setProperty
across targets, I'm not sure if this has been addressed for the 3.2
release?

I suspect that if we have "typed as dynamic breaks property access"
enforced as a feature, then we'll need to rely more on reflection and
other features like that.

This is what I had to use in Actuate:

if (Reflect.hasField (target, propertyName)) {

#if flash
untyped target[propertyName] = value;
#else
Reflect.setField (target, propertyName, value);
#end

} else {

#if (haxe_209 || haxe3)
Reflect.setProperty (target, propertyName, value);
#end

}

Unless it has gotten better since I last checked, the documentation
suggested that "Reflect.setField" should work (basically) in all cases
except Haxe getters and setters, while "Reflect.setProperty" should work
in all cases. I have experiences with "Reflect.setProperty" not working
for ordinary fields, and Flash native properties (get/set in Flash, not in
Haxe) behaving unusually as well.

It's been so long, I can't see which platform and which exact issue, but
this is something that may become more important, and (ideally) should be
wrapped in a single function call instead of this type of thing.

Hopefully generics are also stable enough in Haxe 3.2 that we can use them
to help solve this type of issue as well

Thanks



On Mon, 02 Mar 2015 04:56:21 -0800, Nicolas Cannasse <ncan...@gmail.com>
wrote:

[Simon Krajewski]

Am 02.03.2015 um 18:38 schrieb Joshua Granick:
> I have had serious problems using Reflect.setField and
> Reflect.setProperty across targets, I'm not sure if this has been
> addressed for the 3.2 release?

I don't see any open issues about setField/setProperty, so either all
issues have been addressed or nobody reported them in the first place.

Simon

[Joshua Granick]

I don't want to be weird, but I'm still not sure I understand the decision.

Neko has traditionally broken when "passing through" a Dynamic:


var sprite:Sprite = new Sprite ();
sprite.name = "Hello"; // works

var renameObject = function (object:Dynamic) {
object.name = "Hello";
}

renameObject (sprite); // breaks


This exact sample might work, but I'm just stating the principle of what
I've seen occur.

So you're saying that C++ will now break as well?

Both the Flash and JavaScript targets will work -- they are dynamic
targets that will still set the "name" property of the dynamic "object"
value properly.

It seems like the change, here, really just makes the C++ target a lot
less useful, at the expense of making it break similar to Neko -- but Neko
is really used just for testing and tools, not production, so it really
just reduces the value of the C++ target in production. Am I
misunderstanding this?

[Fernando Serboncini]

What I understood from Hugh's email is that Flash/Javascript changes would also follow. That's where the "language consistency" gains were. If those changes don't follow, then things get even weirder than the current (old?) state, it seems.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Nicolas Cannasse]

Le 02/03/2015 21:22, Joshua Granick a écrit :
> I don't want to be weird, but I'm still not sure I understand the decision.
>
> Neko has traditionally broken when "passing through" a Dynamic:
>
>
> var sprite:Sprite = new Sprite ();
> sprite.name = "Hello"; // works
>
> var renameObject = function (object:Dynamic) {
> object.name = "Hello";
> }
>
> renameObject (sprite); // breaks
>
>
> This exact sample might work, but I'm just stating the principle of what
> I've seen occur.
>
> So you're saying that C++ will now break as well?
>
> Both the Flash and JavaScript targets will work -- they are dynamic
> targets that will still set the "name" property of the dynamic "object"
> value properly.

Up to Haxe 3.1, C++ was the only target that was calling the set_name()
method when the class instance was accessed with Dynamic or Reflect.setField

This is no longer the case in 3.2: C++ will behave as other targets,
which is to set directly the "name" field in these cases, not going
through the set_name() method.

Of course if you're inside a "pure" getter/setter method (ie you have no
actual "name" field on your class instance) this will throw an
exception, as it would too in Flash/C#/Java, but not in Neko/PHP/JS
which are dynamically typed targets.

PS: the same goes with the getter method of course.

Best,
Nicolas

[Philippe Elsass]

Joshua I think this is a bad example because the Flash Sprite's name/x/width properties are "native" properties. Normal Haxe properties' getter/setter are replaced by get_xxx/set_xxx which are unknown for dynamically typed objects.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

--- You received this message because you are subscribed to the Google Groups "Haxe" group.

For more options, visit https://groups.google.com/d/optout.

--

Philippe

[Joshua Granick]

Then perhaps I'm thinking of another issue, which is that Neko gets upset with objects it cannot understand the type for, for ordinary properties and methods.

[Simon Krajewski]

Am 02.03.2015 um 22:40 schrieb Joshua Granick:

Then perhaps I'm thinking of another issue, which is that Neko gets upset with objects it cannot understand the type for, for ordinary properties and methods.

Could we get something with a bit more substance, ideally in the form of a code example?

Simon

[Philippe Elsass]

Neko is easily upset anyway ;)

[Ashiq A.]

I may have an example, if I'm understanding Joshua's case correctly.

Take a look at this documentation for creating sandboxed modules:
http://old.haxe.org/doc/advanced/neko_sandbox

It uses this neko-only code to load a module:

var safeLoader = Loader.make(loadPrimitive, Loader.local().loadModule);
var module = safeLoader.loadModule("plugin");
var classes : Dynamic = module.exportsTable().__classes;

If I recall correctly, if you iterate over the "classes" variable, you
see instances with a "name" property. But trying to access "c.name"
throws an exception about a missing field.

--Ashiq

[Joshua Granick]

On this note, are there plans to support @:nativeProperty on JavaScript, using JS getters/setters, or @:nativeProperty on Flash (unifying the syntax with the Flash-specific @:getter/@:setter tags)?

It would be nice if this were possible

[Yaroslav Sivakov]

https://github.com/HaxeFoundation/haxe/issues/2469 - last discussion about that