Haxe JS ignores getters/setters when using Reflect.setField

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Haxe JS ignores getters/setters when using Reflect.setField

singmajesty
Hi!

I have a problem with how JS is generated, regarding getters, setters and  
Reflect.setField.



This code:



logo.x = 10;



...using setters in jeash, translates to this code in Javascript:



logo.jeashSetX (10);



Which works. However, if you use Reflect.setField:



Reflect.setField (logo, "x", 10);



It creates this Javascript:



logo["x"] = 10;




Any workaround?

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

clemos
Hi Joshua

I think this is the expected behaviour, since getters/setters are
compile-time tricks. This is true on all platforms, afaik.

As a workaround, I actually implemented a macro that adds metadata to
all fields which have getter/setter:
https://github.com/ciscoheat/erazor/blob/master/src/erazor/hscript/ReflectMacro.hx
Then you can wrap your Reflect.getField / Reflect.setField calls in
another method so that they call the appropriate methods instead of
just setting/getting the field (here getProperty, for getting only):
https://github.com/ciscoheat/erazor/blob/master/src/erazor/hscript/EnhancedReflect.hx

Cheers,
Clément

On Wed, Sep 21, 2011 at 3:36 PM, Joshua Granick
<[hidden email]> wrote:

> Hi!
>
> I have a problem with how JS is generated, regarding getters, setters and
> Reflect.setField.
>
>
>
> This code:
>
>
>
> logo.x = 10;
>
>
>
> ...using setters in jeash, translates to this code in Javascript:
>
>
>
> logo.jeashSetX (10);
>
>
>
> Which works. However, if you use Reflect.setField:
>
>
>
> Reflect.setField (logo, "x", 10);
>
>
>
> It creates this Javascript:
>
>
>
> logo["x"] = 10;
>
>
>
>
> Any workaround?
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

singmajesty
Ugh. One more problem.

It seems that the setters aren't being used when using a reference of an  
object:



var hello = new Sprite ();
hello.x = 100 // works


var details = {};
details.target = hello;
details.target.x = 100 // does not work



This definitely seems like an issue.

I need to be able to use Reflect.setField in order to use a tween library.  
If I wanted it to be untyped, I'd call untyped {} or untyped __js__ (); to  
hack something.


I'll look into your macros, though, as a hack/workaround (thanks!)





On Wed, 21 Sep 2011 06:52:21 -0700, clemos <[hidden email]> wrote:

> Hi Joshua
>
> I think this is the expected behaviour, since getters/setters are
> compile-time tricks. This is true on all platforms, afaik.
>
> As a workaround, I actually implemented a macro that adds metadata to
> all fields which have getter/setter:
> https://github.com/ciscoheat/erazor/blob/master/src/erazor/hscript/ReflectMacro.hx
> Then you can wrap your Reflect.getField / Reflect.setField calls in
> another method so that they call the appropriate methods instead of
> just setting/getting the field (here getProperty, for getting only):
> https://github.com/ciscoheat/erazor/blob/master/src/erazor/hscript/EnhancedReflect.hx
>
> Cheers,
> Clément
>
> On Wed, Sep 21, 2011 at 3:36 PM, Joshua Granick
> <[hidden email]> wrote:
>> Hi!
>>
>> I have a problem with how JS is generated, regarding getters, setters  
>> and
>> Reflect.setField.
>>
>>
>>
>> This code:
>>
>>
>>
>> logo.x = 10;
>>
>>
>>
>> ...using setters in jeash, translates to this code in Javascript:
>>
>>
>>
>> logo.jeashSetX (10);
>>
>>
>>
>> Which works. However, if you use Reflect.setField:
>>
>>
>>
>> Reflect.setField (logo, "x", 10);
>>
>>
>>
>> It creates this Javascript:
>>
>>
>>
>> logo["x"] = 10;
>>
>>
>>
>>
>> Any workaround?
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

Drakim
This is actually not an issue but expected behavior. You can read the details here:
http://haxe.org/ref/properties

Due to how getters and setters work it's simply impossible to make them work if you are accessing the object dynamically, or with Reflect.
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

singmajesty
Yeah, I realized last night that the compiler must be converting direct  
variable references to the getter or setter at compile time, but otherwise  
its unhandled.

It would be nice if Reflect.field and Reflect.setField had a lookup table,  
or better still if the resulting code could use real Javascript getters  
and setters. The problem, there, is that Internet Explorer only supports  
getters and setters on DOM objects (and only a select few... not all),  
which means that your objects would have to extend Image or some other  
type. It's a hack, but it still might be worth it.

Maybe. I know not everyone is writing a tween library, which  
(understandably) has to rely on Reflection to update properties. The only  
way to do it without reflection would be to call Actuate.update to call  
your own function... but then you're creating a function for every tween.  
Not really cool.




On Thu, 22 Sep 2011 01:12:03 -0700, Drakim <[hidden email]>  
wrote:

> This is actually not an issue but expected behavior. You can read the  
> details
> here:
> http://haxe.org/ref/properties http://haxe.org/ref/properties
>
> Due to how getters and setters work it's simply impossible to make them  
> work
> if you are accessing the object dynamically, or with Reflect.
>
> --
> View this message in context:  
> http://haxe.1354130.n2.nabble.com/Haxe-JS-ignores-getters-setters-when-using-Reflect-setField-tp6816036p6819315.html
> Sent from the Haxe mailing list archive at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

clemos
Hi Joshua,

I think it's difficult to rely on native getters and setters because
they have really different behaviour across platforms (not to mention
different JS implementations...).
The macro approach allows for more cross-platformness and is not
necessarily a performance loss, since you can sometimes do this
property lookup at compile time (if you know the type of your instance
then).
For a tweening library, you can do this lookup only once at the
beginning and store the setter method somewhere for faster access.
This may actually be faster than "native" (or runtime) getter/setters,
I guess.

Anyway, the last time I mentionned this issue (see recent mail
archive), Nicolas wrote he had ideas about how to solve it, so I guess
something will happen soon.

Cheers,
Clément

On Thu, Sep 22, 2011 at 5:54 PM, Joshua Granick
<[hidden email]> wrote:

> Yeah, I realized last night that the compiler must be converting direct
> variable references to the getter or setter at compile time, but otherwise
> its unhandled.
>
> It would be nice if Reflect.field and Reflect.setField had a lookup table,
> or better still if the resulting code could use real Javascript getters and
> setters. The problem, there, is that Internet Explorer only supports getters
> and setters on DOM objects (and only a select few... not all), which means
> that your objects would have to extend Image or some other type. It's a
> hack, but it still might be worth it.
>
> Maybe. I know not everyone is writing a tween library, which
> (understandably) has to rely on Reflection to update properties. The only
> way to do it without reflection would be to call Actuate.update to call your
> own function... but then you're creating a function for every tween. Not
> really cool.
>
>
>
>
> On Thu, 22 Sep 2011 01:12:03 -0700, Drakim <[hidden email]>
> wrote:
>
>> This is actually not an issue but expected behavior. You can read the
>> details
>> here:
>> http://haxe.org/ref/properties http://haxe.org/ref/properties
>>
>> Due to how getters and setters work it's simply impossible to make them
>> work
>> if you are accessing the object dynamically, or with Reflect.
>>
>> --
>> View this message in context:
>> http://haxe.1354130.n2.nabble.com/Haxe-JS-ignores-getters-setters-when-using-Reflect-setField-tp6816036p6819315.html
>> Sent from the Haxe mailing list archive at Nabble.com.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

singmajesty
Yeah, I thought about methods I could use in my tweening library, but  
concluding that it was the wrong approach. Since I'm bridging  
compatibility with NME and Jeash, to publish applications for Canvas, it  
would be wrong of me to create a special solution for my own library, if  
there would be some way to universally solve the issue for all libraries.

As a result, for now, the (beta) HTML5 installer for NME uses its own  
Reflect class, which is aware of jeash getters or setters. It won't solve  
the issue for all getters or setters, but at least it solves access at a  
framework level, which is much better than Actuate alone.




On Thu, 22 Sep 2011 09:34:22 -0700, clemos <[hidden email]> wrote:

> Hi Joshua,
>
> I think it's difficult to rely on native getters and setters because
> they have really different behaviour across platforms (not to mention
> different JS implementations...).
> The macro approach allows for more cross-platformness and is not
> necessarily a performance loss, since you can sometimes do this
> property lookup at compile time (if you know the type of your instance
> then).
> For a tweening library, you can do this lookup only once at the
> beginning and store the setter method somewhere for faster access.
> This may actually be faster than "native" (or runtime) getter/setters,
> I guess.
>
> Anyway, the last time I mentionned this issue (see recent mail
> archive), Nicolas wrote he had ideas about how to solve it, so I guess
> something will happen soon.
>
> Cheers,
> Clément
>
> On Thu, Sep 22, 2011 at 5:54 PM, Joshua Granick
> <[hidden email]> wrote:
>> Yeah, I realized last night that the compiler must be converting direct
>> variable references to the getter or setter at compile time, but  
>> otherwise
>> its unhandled.
>>
>> It would be nice if Reflect.field and Reflect.setField had a lookup  
>> table,
>> or better still if the resulting code could use real Javascript getters  
>> and
>> setters. The problem, there, is that Internet Explorer only supports  
>> getters
>> and setters on DOM objects (and only a select few... not all), which  
>> means
>> that your objects would have to extend Image or some other type. It's a
>> hack, but it still might be worth it.
>>
>> Maybe. I know not everyone is writing a tween library, which
>> (understandably) has to rely on Reflection to update properties. The  
>> only
>> way to do it without reflection would be to call Actuate.update to call  
>> your
>> own function... but then you're creating a function for every tween. Not
>> really cool.
>>
>>
>>
>>
>> On Thu, 22 Sep 2011 01:12:03 -0700, Drakim <[hidden email]>
>> wrote:
>>
>>> This is actually not an issue but expected behavior. You can read the
>>> details
>>> here:
>>> http://haxe.org/ref/properties http://haxe.org/ref/properties
>>>
>>> Due to how getters and setters work it's simply impossible to make them
>>> work
>>> if you are accessing the object dynamically, or with Reflect.
>>>
>>> --
>>> View this message in context:
>>> http://haxe.1354130.n2.nabble.com/Haxe-JS-ignores-getters-setters-when-using-Reflect-setField-tp6816036p6819315.html
>>> Sent from the Haxe mailing list archive at Nabble.com.
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

jlm@justinfront.net
Just wondered... If you define tweens with a <T> would it help with  
the javascript target?

var t = new Tween<MovieClip>( ...

Because then your not reflecting on Dynamic but on a specific type?

Cheers ;j

On 22 Sep 2011, at 17:48, Joshua Granick wrote:

> Yeah, I thought about methods I could use in my tweening library,  
> but concluding that it was the wrong approach. Since I'm bridging  
> compatibility with NME and Jeash, to publish applications for  
> Canvas, it would be wrong of me to create a special solution for my  
> own library, if there would be some way to universally solve the  
> issue for all libraries.
>
> As a result, for now, the (beta) HTML5 installer for NME uses its  
> own Reflect class, which is aware of jeash getters or setters. It  
> won't solve the issue for all getters or setters, but at least it  
> solves access at a framework level, which is much better than  
> Actuate alone.
>
>
>
>
> On Thu, 22 Sep 2011 09:34:22 -0700, clemos <[hidden email]> wrote:
>
>> Hi Joshua,
>>
>> I think it's difficult to rely on native getters and setters because
>> they have really different behaviour across platforms (not to mention
>> different JS implementations...).
>> The macro approach allows for more cross-platformness and is not
>> necessarily a performance loss, since you can sometimes do this
>> property lookup at compile time (if you know the type of your  
>> instance
>> then).
>> For a tweening library, you can do this lookup only once at the
>> beginning and store the setter method somewhere for faster access.
>> This may actually be faster than "native" (or runtime) getter/
>> setters,
>> I guess.
>>
>> Anyway, the last time I mentionned this issue (see recent mail
>> archive), Nicolas wrote he had ideas about how to solve it, so I  
>> guess
>> something will happen soon.
>>
>> Cheers,
>> Clément
>>
>> On Thu, Sep 22, 2011 at 5:54 PM, Joshua Granick
>> <[hidden email]> wrote:
>>> Yeah, I realized last night that the compiler must be converting  
>>> direct
>>> variable references to the getter or setter at compile time, but  
>>> otherwise
>>> its unhandled.
>>>
>>> It would be nice if Reflect.field and Reflect.setField had a  
>>> lookup table,
>>> or better still if the resulting code could use real Javascript  
>>> getters and
>>> setters. The problem, there, is that Internet Explorer only  
>>> supports getters
>>> and setters on DOM objects (and only a select few... not all),  
>>> which means
>>> that your objects would have to extend Image or some other type.  
>>> It's a
>>> hack, but it still might be worth it.
>>>
>>> Maybe. I know not everyone is writing a tween library, which
>>> (understandably) has to rely on Reflection to update properties.  
>>> The only
>>> way to do it without reflection would be to call Actuate.update to  
>>> call your
>>> own function... but then you're creating a function for every  
>>> tween. Not
>>> really cool.
>>>
>>>
>>>
>>>
>>> On Thu, 22 Sep 2011 01:12:03 -0700, Drakim <[hidden email]
>>> >
>>> wrote:
>>>
>>>> This is actually not an issue but expected behavior. You can read  
>>>> the
>>>> details
>>>> here:
>>>> http://haxe.org/ref/properties http://haxe.org/ref/properties
>>>>
>>>> Due to how getters and setters work it's simply impossible to  
>>>> make them
>>>> work
>>>> if you are accessing the object dynamically, or with Reflect.
>>>>
>>>> --
>>>> View this message in context:
>>>> http://haxe.1354130.n2.nabble.com/Haxe-JS-ignores-getters-setters-when-using-Reflect-setField-tp6816036p6819315.html
>>>> Sent from the Haxe mailing list archive at Nabble.com.
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

singmajesty
In reply to this post by clemos
Hi again!

How would I use this code? I'm completely new to Haxe macros, and have  
never used one before. Would you mind providing an example?

I've overwritten Reflect with my own custom class, but by the sound of it,  
you're using a smarter/more efficient way of handling getters and setters


On Wed, 21 Sep 2011 06:52:21 -0700, clemos <[hidden email]> wrote:

> Hi Joshua
>
> I think this is the expected behaviour, since getters/setters are
> compile-time tricks. This is true on all platforms, afaik.
>
> As a workaround, I actually implemented a macro that adds metadata to
> all fields which have getter/setter:
> https://github.com/ciscoheat/erazor/blob/master/src/erazor/hscript/ReflectMacro.hx
> Then you can wrap your Reflect.getField / Reflect.setField calls in
> another method so that they call the appropriate methods instead of
> just setting/getting the field (here getProperty, for getting only):
> https://github.com/ciscoheat/erazor/blob/master/src/erazor/hscript/EnhancedReflect.hx
>
> Cheers,
> Clément
>
> On Wed, Sep 21, 2011 at 3:36 PM, Joshua Granick
> <[hidden email]> wrote:
>> Hi!
>>
>> I have a problem with how JS is generated, regarding getters, setters  
>> and
>> Reflect.setField.
>>
>>
>>
>> This code:
>>
>>
>>
>> logo.x = 10;
>>
>>
>>
>> ...using setters in jeash, translates to this code in Javascript:
>>
>>
>>
>> logo.jeashSetX (10);
>>
>>
>>
>> Which works. However, if you use Reflect.setField:
>>
>>
>>
>> Reflect.setField (logo, "x", 10);
>>
>>
>>
>> It creates this Javascript:
>>
>>
>>
>> logo["x"] = 10;
>>
>>
>>
>>
>> Any workaround?
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

Cauê W.
In reply to this post by jlm@justinfront.net
Hey Joshua!

Just a quick message, I've talked with Nicolas about getters and setters some time ago, and indeed since some platforms don't support native getters/setters (e.g. JavaScript for IE), it can't be the standard way to handle that in haxe.
Anyway, there can be numerous ways to overcome this. When I was implementing this kind of behavior for away3dlite, I've came up with using standardized getter/setter names for away3d lib (if the variable is 'x', the getter is get_x, and setter is set_x), and on the "tweening" (actually it was skinning) part, I cached the getter/setter lookups in a hash. This actually gave me a considerable (and even noticeable) speedup in relation to flash native getters/setters. So in a tweening context, you might go with this solution, which is quite lightweight but depends on a naming convention. It's ok if you want this behavior e.g. only on the nme internal library.
Keep in mind that looking up in metadata every frame will be a small performance hit, so maybe as an alternative you can use macros to convert this:

myTweening.tween(myObject, {x:20, y:10}, myTweeningFunc);

to this:

myTweening.tween(function(percentComplete) { myObject.x = myTweeningFunc(myObject.x, percentComplete, 20); myObject.y = myTweeningFunc(myObject.y, percentComplete, 10) })

so if myObject is strictly typed, it will call the correct getters/setters automatically, and will be a fast alternative (though verbose).

2011/9/22 [hidden email] <[hidden email]>
Just wondered... If you define tweens with a <T> would it help with the javascript target?

var t = new Tween<MovieClip>( ...

Because then your not reflecting on Dynamic but on a specific type?

Cheers ;j


On 22 Sep 2011, at 17:48, Joshua Granick wrote:

Yeah, I thought about methods I could use in my tweening library, but concluding that it was the wrong approach. Since I'm bridging compatibility with NME and Jeash, to publish applications for Canvas, it would be wrong of me to create a special solution for my own library, if there would be some way to universally solve the issue for all libraries.

As a result, for now, the (beta) HTML5 installer for NME uses its own Reflect class, which is aware of jeash getters or setters. It won't solve the issue for all getters or setters, but at least it solves access at a framework level, which is much better than Actuate alone.




On Thu, 22 Sep 2011 09:34:22 -0700, clemos <[hidden email]> wrote:

Hi Joshua,

I think it's difficult to rely on native getters and setters because
they have really different behaviour across platforms (not to mention
different JS implementations...).
The macro approach allows for more cross-platformness and is not
necessarily a performance loss, since you can sometimes do this
property lookup at compile time (if you know the type of your instance
then).
For a tweening library, you can do this lookup only once at the
beginning and store the setter method somewhere for faster access.
This may actually be faster than "native" (or runtime) getter/setters,
I guess.

Anyway, the last time I mentionned this issue (see recent mail
archive), Nicolas wrote he had ideas about how to solve it, so I guess
something will happen soon.

Cheers,
Clément

On Thu, Sep 22, 2011 at 5:54 PM, Joshua Granick
<[hidden email]> wrote:
Yeah, I realized last night that the compiler must be converting direct
variable references to the getter or setter at compile time, but otherwise
its unhandled.

It would be nice if Reflect.field and Reflect.setField had a lookup table,
or better still if the resulting code could use real Javascript getters and
setters. The problem, there, is that Internet Explorer only supports getters
and setters on DOM objects (and only a select few... not all), which means
that your objects would have to extend Image or some other type. It's a
hack, but it still might be worth it.

Maybe. I know not everyone is writing a tween library, which
(understandably) has to rely on Reflection to update properties. The only
way to do it without reflection would be to call Actuate.update to call your
own function... but then you're creating a function for every tween. Not
really cool.




On Thu, 22 Sep 2011 01:12:03 -0700, Drakim <[hidden email]>
wrote:

This is actually not an issue but expected behavior. You can read the
details
here:
http://haxe.org/ref/properties http://haxe.org/ref/properties

Due to how getters and setters work it's simply impossible to make them
work
if you are accessing the object dynamically, or with Reflect.

--
View this message in context:
http://haxe.1354130.n2.nabble.com/Haxe-JS-ignores-getters-setters-when-using-Reflect-setField-tp6816036p6819315.html
Sent from the Haxe mailing list archive at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

Nicolas Cannasse
In reply to this post by singmajesty
Le 22/09/2011 17:54, Joshua Granick a écrit :
> Yeah, I realized last night that the compiler must be converting direct
> variable references to the getter or setter at compile time, but
> otherwise its unhandled.
>
> It would be nice if Reflect.field and Reflect.setField had a lookup
> table, or better still if the resulting code could use real Javascript
> getters and setters.

Native JS getters/setters are only included in JS 1.6 which is not yet
widespread (no IE8 suport for instance).

I'm planning to add Reflect.get/setProperty that would allow both normal
field AND property access. It might be slower than
Reflect.field/setField for platforms that does not have native
properties since it will require additional lookups in the class extra
data (that will need to be generated as part of the output).

Watch for http://code.google.com/p/haxe/issues/detail?id=511 to see when
it will be updated (after 2.08 anyway).

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

clemos
In reply to this post by singmajesty
Hi Joshua,

Basically, you need to call ReflectMacro.addMeta() once in your code.
This macro will add "set" and "get" metadata on every field that has
getter and/or setter access.
Then you can just replace Reflect.field calls with EnhancedReflect.getProperty.
This method will check the "get" metadata on the field, and call the
appropriate method if present.
Implementing a similar setProperty method shouldn't be too complicated
but I didn't need it so I didn't implement it.

Hope it helps,
Clément

On Thu, Sep 22, 2011 at 10:06 PM, Joshua Granick
<[hidden email]> wrote:

> Hi again!
>
> How would I use this code? I'm completely new to Haxe macros, and have never
> used one before. Would you mind providing an example?
>
> I've overwritten Reflect with my own custom class, but by the sound of it,
> you're using a smarter/more efficient way of handling getters and setters
>
>
> On Wed, 21 Sep 2011 06:52:21 -0700, clemos <[hidden email]> wrote:
>
>> Hi Joshua
>>
>> I think this is the expected behaviour, since getters/setters are
>> compile-time tricks. This is true on all platforms, afaik.
>>
>> As a workaround, I actually implemented a macro that adds metadata to
>> all fields which have getter/setter:
>>
>> https://github.com/ciscoheat/erazor/blob/master/src/erazor/hscript/ReflectMacro.hx
>> Then you can wrap your Reflect.getField / Reflect.setField calls in
>> another method so that they call the appropriate methods instead of
>> just setting/getting the field (here getProperty, for getting only):
>>
>> https://github.com/ciscoheat/erazor/blob/master/src/erazor/hscript/EnhancedReflect.hx
>>
>> Cheers,
>> Clément
>>
>> On Wed, Sep 21, 2011 at 3:36 PM, Joshua Granick
>> <[hidden email]> wrote:
>>>
>>> Hi!
>>>
>>> I have a problem with how JS is generated, regarding getters, setters and
>>> Reflect.setField.
>>>
>>>
>>>
>>> This code:
>>>
>>>
>>>
>>> logo.x = 10;
>>>
>>>
>>>
>>> ...using setters in jeash, translates to this code in Javascript:
>>>
>>>
>>>
>>> logo.jeashSetX (10);
>>>
>>>
>>>
>>> Which works. However, if you use Reflect.setField:
>>>
>>>
>>>
>>> Reflect.setField (logo, "x", 10);
>>>
>>>
>>>
>>> It creates this Javascript:
>>>
>>>
>>>
>>> logo["x"] = 10;
>>>
>>>
>>>
>>>
>>> Any workaround?
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

Elsass Philippe
In reply to this post by singmajesty
Hello,

I've been mucking around haxe JS generator and I'm fixing a few things:
- compatibility with google closure "simple" compiler (done, outputs code 20% smaller) but still no luck with the "advanced" compiler,
- using Function.bind() instead of $closure() for haxe closures (done, safer with code optimizers),
- reflecting getters/setters, by automatically generating meta information about properties (meta generation done, now have to modify Reflect to use this info).

I'm also going to modify the code generation to emit much more compact (and probably faster) prototypes declaration. This should reduce the JS weight by another 10-20%.

Here's the current changes diff:

Cheers,
Philippe

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

Viktor Hesselbom-2
Wow, that is awesome! Having no experience with applying diff-files, how would I apply this?

I love when the JS target evolves :)

viktor hesselbom



2011/9/23 Elsass Philippe <[hidden email]>
Hello,

I've been mucking around haxe JS generator and I'm fixing a few things:
- compatibility with google closure "simple" compiler (done, outputs code 20% smaller) but still no luck with the "advanced" compiler,
- using Function.bind() instead of $closure() for haxe closures (done, safer with code optimizers),
- reflecting getters/setters, by automatically generating meta information about properties (meta generation done, now have to modify Reflect to use this info).

I'm also going to modify the code generation to emit much more compact (and probably faster) prototypes declaration. This should reduce the JS weight by another 10-20%.

Here's the current changes diff:

Cheers,
Philippe

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

jlm@justinfront.net
Viktor

Normally if you don't have access to an SVN you can send the author a patch or diff file it describes the differences.  If your on windows or on mac running scnplugin you should be able to do it from the file browser right click under subversion options. I think normally you can export a patch in a similar way... you look at the diff between your created file and repository file and then export as a patch.
I did a quick google on patches for you and found this link.


But not used patches on any recent projects so some details may have escaped me, but I suspect it may sounds and feels more complex to do that it is in reality.

Cheers

;j



On 23 Sep 2011, at 16:04, Viktor Hesselbom wrote:

Wow, that is awesome! Having no experience with applying diff-files, how would I apply this?

I love when the JS target evolves :)

viktor hesselbom



2011/9/23 Elsass Philippe <[hidden email]>
Hello,

I've been mucking around haxe JS generator and I'm fixing a few things:
- compatibility with google closure "simple" compiler (done, outputs code 20% smaller) but still no luck with the "advanced" compiler,
- using Function.bind() instead of $closure() for haxe closures (done, safer with code optimizers),
- reflecting getters/setters, by automatically generating meta information about properties (meta generation done, now have to modify Reflect to use this info).

I'm also going to modify the code generation to emit much more compact (and probably faster) prototypes declaration. This should reduce the JS weight by another 10-20%.

Here's the current changes diff:

Cheers,
Philippe

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

jlm@justinfront.net
Er this may be a better link...


but just google patch and svn.

On 23 Sep 2011, at 18:33, [hidden email] wrote:

Viktor

Normally if you don't have access to an SVN you can send the author a patch or diff file it describes the differences.  If your on windows or on mac running scnplugin you should be able to do it from the file browser right click under subversion options. I think normally you can export a patch in a similar way... you look at the diff between your created file and repository file and then export as a patch.
I did a quick google on patches for you and found this link.


But not used patches on any recent projects so some details may have escaped me, but I suspect it may sounds and feels more complex to do that it is in reality.

Cheers

;j



On 23 Sep 2011, at 16:04, Viktor Hesselbom wrote:

Wow, that is awesome! Having no experience with applying diff-files, how would I apply this?

I love when the JS target evolves :)

viktor hesselbom



2011/9/23 Elsass Philippe <[hidden email]>
Hello,

I've been mucking around haxe JS generator and I'm fixing a few things:
- compatibility with google closure "simple" compiler (done, outputs code 20% smaller) but still no luck with the "advanced" compiler,
- using Function.bind() instead of $closure() for haxe closures (done, safer with code optimizers),
- reflecting getters/setters, by automatically generating meta information about properties (meta generation done, now have to modify Reflect to use this info).

I'm also going to modify the code generation to emit much more compact (and probably faster) prototypes declaration. This should reduce the JS weight by another 10-20%.

Here's the current changes diff:

Cheers,
Philippe

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

singmajesty
In reply to this post by Elsass Philippe
Rock on!

And in ocaml, no less :)



On Fri, 23 Sep 2011 07:52:55 -0700, Elsass Philippe  
<[hidden email]> wrote:

> Hello,
>
> I've been mucking around haxe JS generator and I'm fixing a few things:
> - compatibility with google closure "simple" compiler (done, outputs code
> 20% smaller) but still no luck with the "advanced" compiler,
> - using Function.bind() instead of $closure() for haxe closures (done,  
> safer
> with code optimizers),
> - reflecting getters/setters, by automatically generating meta  
> information
> about properties (meta generation done, now have to modify Reflect to use
> this info).
>
> I'm also going to modify the code generation to emit much more compact  
> (and
> probably faster) prototypes declaration. This should reduce the JS  
> weight by
> another 10-20%.
>
> Here's the current changes diff:
> http://pastie.org/2579622
>
> Cheers,
> Philippe

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

Dion Whitehead Amago
In reply to this post by Elsass Philippe
That's awesome.

On Fri, Sep 23, 2011 at 9:52 AM, Elsass Philippe
<[hidden email]> wrote:

> Hello,
> I've been mucking around haxe JS generator and I'm fixing a few things:
> - compatibility with google closure "simple" compiler (done, outputs code
> 20% smaller) but still no luck with the "advanced" compiler,
> - using Function.bind() instead of $closure() for haxe closures (done, safer
> with code optimizers),
> - reflecting getters/setters, by automatically generating meta information
> about properties (meta generation done, now have to modify Reflect to use
> this info).
> I'm also going to modify the code generation to emit much more compact (and
> probably faster) prototypes declaration. This should reduce the JS weight by
> another 10-20%.
> Here's the current changes diff:
> http://pastie.org/2579622
> Cheers,
> Philippe
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe JS ignores getters/setters when using Reflect.setField

Nicolas Cannasse
In reply to this post by Elsass Philippe
Le 23/09/2011 16:52, Elsass Philippe a écrit :

> Hello,
>
> I've been mucking around haxe JS generator and I'm fixing a few things:
> - compatibility with google closure "simple" compiler (done, outputs
> code 20% smaller) but still no luck with the "advanced" compiler,
> - using Function.bind() instead of $closure() for haxe closures (done,
> safer with code optimizers),
> - reflecting getters/setters, by automatically generating meta
> information about properties (meta generation done, now have to modify
> Reflect to use this info).
>
> I'm also going to modify the code generation to emit much more compact
> (and probably faster) prototypes declaration. This should reduce the JS
> weight by another 10-20%.

Tell me when you're done so we can see how we merge that into haXe/SVN ;)

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org