[GitHub] [royale-asjs] greg-dove edited a comment on issue #384: Cannot find Vector. methods

[GitBox <gi...@apache.org>]

greg-dove edited a comment on issue #384: Cannot find Vector.<T> methods
URL: https://github.com/apache/royale-asjs/issues/384#issuecomment-489404552
 
 
   > IMO, a single Vector implementation is not PAYG. 
   
   There is no reason it need not be. It just needs to be able to be tuned/scalable in terms of trade-off between type safety and performance. IMO a single implementation that supports performance tuning is more logical than introducing inconsistency and incompatibility to achieve performance tuning, *especially* for a core language feature. When I check if the Vector.<IBead> that was created in the framework is the same type as the Vector.<IBead> that I created locally in my project, they *better* be the same actual type, otherwise I no longer have faith that this 'actionscript' is really actionscript - because it is not behaving according to spec.
   I think framework component sets can and should be PAYG in terms of the way you think about multiple alternate implementations.
   But this is *Language* - it is a core part of actionscript and is specified.
   In that sense Vector is not different to Array or Number or String, imo. 
   Either the js target behaviour meets the specification or it does not.
   I'm not sure about your point with e4x. We have a reference implementation that is defined for actionscript - I presume that has also been the goal to match as a standard (fyi OT: I do have a minor XML fix coming too I think, still working on it)
   Languages like Haxe which have multiple (8+) targets have to do this stuff well - almost *everything* in the standard library for Haxe is unit tested so that each target conforms  - and it makes it much easier to introduce new targets, and consistency across targets is assured because they conform to the language spec. Of course, Haxe (as a custom language, for example) has the luxury of defining certain things as explicitly 'unspecifed' behaviours, such as default initializer values...  in royale we do not, because we have a core language specification already (and a reference implementation in flash player to compare against, that serves to fill in any gaps in the spec). We are obviously adding to that specification (Josh's language additions), but I don't expect the plan is to remove things from it...
   
   In terms of the hypothetical example : If I only needed one four element Vector, I would really be asking myself why do I need that? - especially if I knew it was not something with native support on the target platform.
   Certainly if it was the only Vector I was using and absolutely necessary then I must *really* want it to be exceptionally Vector-like, otherwise I would use an Array! In that case I would be happy to pay the price.
   On javascript you won't be saying to yourself: I am going to choose Vector because it's more performant than Array. But type safety is one of the primary premises for why you would choose the Vector type, so it seems like that is the starting point. 
   
   My goal is certainly to have this as a default implementation, but to be able to tune it down (or switch certain things off with compilation flags or local doc directives). In other words: support opt-in performance tuning ('pay' less), but keep some low level consistency that allows aspects of the typing checks etc to still work properly. 
   
   Anyway, if you get a chance please give the branch a try, and let me know what you think after trying it.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services