Alex, javascript TypeArrays are fixed length at construction, so I really
don't think that can work in general case for drop-in substitution of
numeric Vector without some sort of wrapper class that supports swapping
things out.
I really think that dedicated 'fast' numeric collection types will likely
need their own cross-target classes.
It would work for a Vector that has a fixed = true constructor arg and then
never changes its 'fixed' status (and therefore never changes its length
also) and also only uses index access and assignments (no push, pop etc),
but it's a pretty restrictive scenario. I did look at this already.
It might also be possible to map default Vector numeric types to 'faster'
versions for the 3 types, as an opt-in to the default implementation's
approach. I do plan to work on/investigate this later this month, because I
am keen to see performance-oriented options here too. But I was thinking
they would likely be separate, dedicated classes.
On Thu, Jun 13, 2019 at 11:27 AM Alex Harui <aha...@adobe.com.invalid>
wrote:
> FWIW, I would expect any syntax changes to be a significant amount of work
> especially where the BURM does the semantic checks. New BURM patterns are
> probably required. Or maybe it is time to get the BURM out of the
> semantic-check business for JS (and maybe SWF) output and figure out how to
> do the semantic checks from the JS AST walk.
>
> Did you out finding a way to indicate that some Vector.<int> should be
> implemented as a TypedArray?
>
> -Alex
>
> On 6/12/19, 3:18 PM, "Josh Tynjala" <joshtynj...@apache.org> wrote:
>
> I plan to start out by supporting Array.<T> syntax, similar to
> Vector.<T>. Like you said, there are advantages to using the same syntax
> for all typed collections.
>
> Later, I'll see if I can figure out how to add T[] syntax as an
> alternative, since Harbs seems to like that better.
>
> - Josh
>
> On 2019/06/12 20:14:50, Greg Dove <greg.d...@gmail.com> wrote:
> > Hey Josh,
> >
> > Thanks for looking into that, I figured it could be a bit tricky!
> Good luck
> > with it.
> > I think you and Harbs were maybe leaning to towards Number[] and
> String[]
> > type declarations. I don't mind either way, but perhaps the Array.
> with
> > angle brackets approach that is used for Vectors could make it
> easier to
> > swap between typed Array and Vector if people consider refactoring
> (and
> > whatever IDE they're using won't support more automated changes).
> OTOH, the
> > first approach is definitely easier to type. You probably already
> thought
> > those things through though, I guess.
> >
> > If you end up with a remote branch for your work on this at some
> point and
> > want someone to help with testing or anything like that, I'm in,
> just let
> > me know.
> >
> >
> > On Thu, Jun 13, 2019 at 2:26 AM Josh Tynjala <joshtynj...@apache.org>
> wrote:
> >
> > > > I think your other proposal with Josh for the typed Arrays and
> their
> > > greater compile-time safety will be a better fit for many cases as
> well, so
> > > I hope that happens.
> > >
> > > I started working on typed arrays this week. It may be a while
> before I
> > > can merge, though. It's definitely more complex than private
> constructors
> > > and abstract classes.
> > >
> > > - Josh
> > >
> > > On 2019/06/12 04:21:18, Greg Dove <greg.d...@gmail.com> wrote:
> > > > Hi Harbs - just in reply to your specific questions:
> > > > As I mentioned elsewhere it is easy to have full speed index
> access and
> > > > also full speed pop() and unshift() methods
> > > > If you switch off the first 3 settings I outlined in the post
> titled
> > > > 'Language/Reflection improvements details' you will have that.
> Those
> > > > settings are switchable locally with doc directives as well. I
> will do a
> > > > full write-up this coming weekend for docs. Hopefully I can
> harvest a lot
> > > > of what I already wrote elsewhere for that.
> > > > BTW I switched TLF to use the legacy Vector-as-Array approach by
> > > default, I
> > > > am not sure what you want there, you could undo that if you
> prefer.
> > > >
> > > > Beyond the above mentioned approaches for (mainly index level)
> > > > optimization, I have a preference for two more approaches, but
> I'd rather
> > > > limit the overall number of options to be what people definitely
> need
> > > > instead of adding too many options (which could create
> confusion). I
> > > think
> > > > your other proposal with Josh for the typed Arrays and their
> greater
> > > > compile-time safety will be a better fit for many cases as well,
> so I
> > > hope
> > > > that happens. If I have time to help out in any way with that, I
> would be
> > > > happy to do so as well, because it sounds like something I would
> use a
> > > lot.
> > > > Anyhow, I do want to support more optimizations with this
> implementation.
> > > > Can you say what your main concerns would be for optimization?
> Is it
> > > mainly
> > > > for 'push' (and unshift) ? Those would be mine...
> > > >
> > > > I would personally like to see the following:
> > > >
> > > > 1. A global optimization setting that affects all instances in
> all code
> > > > including pre-built library code. This would avoid certain
> runtime checks
> > > > and would also result in a lighter implementation. This is
> something the
> > > > final application developer decides, not anything dictated by a
> library
> > > > developer (but a library developer could advertise their public
> swc as
> > > > being compatible/safe with this type of optimization). This
> approach
> > > could
> > > > include perhaps 2 levels: one to remove any code paths related
> to fixed
> > > > length Vectors (which I think you said you never used) for
> example. Then
> > > > another possibly removing all element level type-checking as
> another
> > > level.
> > > > Adding this should not be too difficult I think and would be
> determined
> > > via
> > > > a goog define (which might be driven by a compiler setting, I
> did not
> > > look
> > > > at how easy this is yet). The thing I like about this approach
> is that it
> > > > is not 'baked-in' to any instance and the application developer
> makes the
> > > > ultimate decision and owns the associated risk (as opposed to
> having it
> > > > imposed on them by a library developer, for example). I think
> the removal
> > > > of support for 'fixed' Vectors could probably be made to generate
> > > > (debug-only) errors if there is code that runs that sets fixed
> to true on
> > > > any Vector instance - to provide some reassurance of no side
> effects
> > > when
> > > > choosing this option.
> > > >
> > > > 2. Compilation scoped optimizations.
> > > > By 'compilation-scoped' I mean configurable in the same way as
> the
> > > > vector-index-check suppression: An over-arching config setting
> for the
> > > > current compilation that can be overridden locally with doc
> comment
> > > > directives. This affects code sites (or all current compilation
> scope if
> > > > set in the config) and not specific instances. I would hope this
> might be
> > > > the only other 'Vector' specific config option like this, simply
> to avoid
> > > > confusion with too many options.
> > > > So I personally think the important things here are the push and
> unshift
> > > > methods, because they're the ones that are also most often used
> in loops
> > > > when index level access or assignment is not being used (in the
> loop).
> > > But
> > > > I'm keen to hear more about what people want in case it's
> different to
> > > how
> > > > I think. And I will add support for what best represents the
> needs of the
> > > > community. While index level access is best for large loops
> (just as it
> > > is
> > > > for 'Array'), push could be preferred in small loops because it
> does not
> > > > require a 'get' for length to establish the upper bound of the
> loop or
> > > the
> > > > next acceptable index to set (for non-fixed Vectors). The
> optimization
> > > for
> > > > push in this case would be to bypass runtime typechecking and
> just do a
> > > > regular Array.push into the underlying Vector representation,
> which is
> > > > still actually an Array in terms of how javascript sees it.
> Adding this
> > > > option is easy also, but rather than just forging ahead with it,
> I am
> > > keen
> > > > to get input from others first.
> > > >
> > > > I consider that specific instance level optimizations (in
> general) are
> > > > 'dangerous' because even if the code is 'safe' when it is
> originally
> > > > written, subsequent changes to the overall codebase (possibly by
> > > different
> > > > developers) can mean that an instance ends up elsewhere in code
> where it
> > > > behaves differently from other instances of the same type.
> Code-site
> > > > optimizations could also create an unusual internal state for an
> > > instance,
> > > > but most often they should not, because the code site where the
> > > > optimization is used should be validated in terms of the
> optimization by
> > > > its original developer (e.g. no runtime type checking at a
> particular
> > > usage
> > > > site because it is never needed in the context of that code, for
> example)
> > > > and the behavior of the same instance elsewhere should be much
> less of a
> > > > risk.
> > > >
> > > > More feedback from you or anyone else is definitely welcome for
> what they
> > > > want to see for optimization options of the implementation. I'm
> sure I
> > > can
> > > > still find more ways to improve the implementation for speed as
> it is now
> > > > as well, I can think of a one thing I want to investigate
> further.
> > > > -Greg
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Jun 12, 2019 at 1:54 AM Harbs <harbs.li...@gmail.com>
> wrote:
> > > >
> > > > > Practical question for me is: How do we disable to Vector
> runtime
> > > > > checking? I was having trouble following the full discussion.
> My
> > > > > understanding was that there’s a compiler flag, but I’m not
> sure what
> > > it is.
> > > > >
> > > > > > On Jun 11, 2019, at 7:10 AM, Yishay Weiss <
> yishayj...@hotmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Language.js:868 [1] is
> > > > > >
> > > > > > if (elementType.indexOf('Vector.<') == 0) {
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: Yishay Weiss <yishayj...@hotmail.com>
> > > > > > Sent: Tuesday, June 11, 2019 2:07:36 PM
> > > > > > To: dev@royale.apache.org
> > > > > > Subject: Problem with Vectors
> > > > > >
> > > > > > Hi Greg,
> > > > > >
> > > > > > I just updated Royale and I’m seeing that in our class
> FontLoader
> > > > > >
> > > > > > private var _fonts:Vector.<Font> = new Vector.<Font>();
> > > > > >
> > > > > > gets transpiled to
> > > > > >
> > > > > > this.com_printui_text_engine_FontLoader__fonts =
> > > > > org.apache.royale.utils.Language.Vector();
> > > > > >
> > > > > > Notice how the type isn’t given in Vector’s constructor. This
> > > results in
> > > > > a runtime error [1]. Any ideas?
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > > TypeError: Cannot read property 'indexOf' of null
> > > > > > Watch
> > > > > > Call Stack
> > > > > >
> org.apache.royale.utils.Language.VectorSupport.vectorElementCoercion
> > > > > > Language.js:868
> > > > > > org.apache.royale.utils.Language.synthVector
> > > > > > Language.js:642
> > > > > > org.apache.royale.utils.Language.Vector
> > > > > > Language.js:685
> > > > > > com.printui.text.engine.FontLoader
> > > > > > FontLoader.js:24
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>
>
