Le 04/06/2012 18:21, clemos a �crit :
>> Le 04/06/2012 18:00, clemos a �crit :
>>
>>> PS:
>>> On a slightly un-related topic, reading this change:
>>>
http://code.google.com/p/haxe/source/detail?r=4769
>>> I was planning to file a issue about that,
>>> but I would rather expect the opposite, @:runtime becoming the default
>>> behaviour...
>>> inline members would always have their runtime counterpart (to go
>>> along well with Reflect by default, for instance)
>>> these could eventually be removed by --dead-code-elimination
>>> and kept using @:keep.
>>>
>>> What do you think ?
>>
>>
>> @:runtime require explicit support in the backend. For instance in genJS we
>> will replace all potential accesses to .iterator by $iterator() call that
>> will add a runtime type check for Array.
>>
>> I'm not sure we want to generalize such tricks.
>
> Mh I didn't read it was about extern methods, so I think I don't
> really get what @:runtime is about...
Yes, it's only to prevent printing an error saying that the method is
actually not present at runtime.
> Still, about "normal" inline methods,
> I just tested, and it appears that (in JS at least) inline methods are
> created just like normal methods.
> That's a good behaviour, but as these method are very likely to be
> unused, I'd expect them to be removed when using DCE.
>
> Do you want me to file a report for that ?
Oh I thought it was done already, it's now fixed in r4776
Best,
Nicolas