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

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

aharui edited a comment on issue #384: Cannot find Vector.<T> methods
URL: https://github.com/apache/royale-asjs/issues/384#issuecomment-489510597
 
 
   I won't have time to try the branch for several days.
   
   IMO, Vector is a special thing.  The compiler even seems to handle it specially.  It can do lots of different things like enforce a fixed-length, or ensure that all items are a particular type, or handle missing values differently (I might be forgetting some features).  Not everybody uses a Vector for all of those features for every instance.  Sometimes you just want to type-check something on entry.
   
   Also, Vector on JS is not free.  Array, String, Number are free.  They are implemented in the runtime.
   
   IMO, when code is optimized for something with so many possible use cases there should not be any guarantee that the optimized code is the same in every instance.  I might agree that for a particular use case, the optimized code should be the same for each instance with that use case.  I'd have to think about that some more.
   
   Next, IMO, it would be best if Royale didn't require folks having to make optimal choices since there are times when you don't have that choice.  For example, if you are forced to use some 3rd-party library where they are misusing Vector.  Or you just grabbed some code from a forum or blog post and want to try it.  IOW, as an application developer, it is fine to say to everyone on the team "we are not going to use any 4 item Vectors in our code", but we should not require that of our users as framework developers.  Royale should give people choices.
   
   Or maybe, you've inherited this Flex app to migrate and it has that one 4-item Vector and it is passed all over the place in the app.  We want to minimize code rewrites for migrating folks if possible.
   
   Also, there are people who will only need the Vector features in development mode and not in production.  They run enough tests in dev mode so they know in production that no code is going to insert a 5th item so they don't need to run the check in production.
   
   And lastly, while it isn't a 4 item Vector, in Royale's HelloWorld and many other examples, there is only the one Vector.<IBead> that is for the strand.  Currently, I believe that having that one Vector implemented as an Array is optimal. You are correct that it didn't catch someone adding a non-IBead, but I am probably not as picky about such things as some folks are.  It works.  Harbs and Carlos went into production with that one Vector implemented as an Array.  And if we had the committer-power to keep the SWF version in sync, the fact that a bead wasn't an IBead would have been caught elsewhere.  We could even add a debug-only test to addBead to test for IBead if we want. 
   
   So the challenge is:  Can you create a single Vector implementation that scales?  I can't say it isn't possible, so if that's what you want to try, definitely go for it.  One of the evaluation criteria is simple:  Compare the bin/js-release size of HelloWorld against the Array implementation in the dev branch.  If you can get it down to, say, a 50- or 100-byte difference for a Vector that isn't fixed length and will never be sparse, then great.  But otherwise, we should offer an option to use Array for those who don't need the features.  If you can create options for some Vector checks to go away in production, even better.
   
   Maybe your Vector implementation will have bead-like plugins where people can add "type-checks" and "length-checks" and "sparse-checks".  Don't know.  That's one reason why I didn't think we should create one single Vector implementation.  Folks might have different reasons for using different implementations.
   
   And that's why I brought up e4x.  If you look at the implementation/[spec](https://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/Ecma-357.pdf), the compiler parses e4x expressions and generates essentially undocumented calls (IOW, API calls that are "public" but not e4x expressions).  The XML swc implements those undocumented calls.  So an e4x expression like:
   
   `delete xml[0]`
   
   generates something like:
   
   `xml.deleteByIndex(0)`
   
   The Royale XML implementation implements deleteByIndex and bunch of other APIs.  So I was just offering an idea where if the compiler took:
   
   `vector.push("foo")`
   
   and similarly, you defined "undocumented" APIs for a Vector implementation, such as saying that "push" results in:
   
   `vector.append("foo")`
   
    then other Vector implementations could be swapped in.  Just an idea, no obligation to try it.
   
   In sum, because you are comparing against an Array-based implementation that has zero download cost for some use cases, it will be hard to compare well against it, but I'm interested to see what you come up with.

----------------------------------------------------------------
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