Hi Alex, it seems I do need to make one more post after all.
I do feel like I have shared all this information before, but I will make
'one more entry' in case I did not do that with clarity:
On Wed, Jun 5, 2019 at 6:36 PM Alex Harui <aha...@adobe.com.invalid> wrote:
> Your summary of my opinion is not correct.
>
> If Vector-as-array is what the current develop branch output is, I am
> unable to understand how that output is incorrect or poses any risks for
> anyone who knows they will not need runtime type-checking or runtime
> fixed-length checking. And thus, it should remain an option. For sure, it
> was good enough for at least two production apps.
>
> I said previously that I don't consider that single case to be a
validation for a more general case, it is just using index access and one
push, iirc. And it really offers no value for runtime safety in the swf
version because the runtime safety for the push call was already guarded by
the signature of the enclosing method. It has already been addressed in the
branch in ways we already discussed at length.
I'd guess that Harbs' experience might validate Vector-as-Array more,
because it sounds like he was using Vector (and therefore Vector-as-Array)
much more than that, iiuc, but Harbs also seemed willing to consider other
options.
While I personally don't think that example justifies it as a feature, I'm
not interested in using it as any justification to oppose it. Like I said,
I will add it back.
I consider that specific example (as it is currently in develop) 'safe' in
the swc *because* it abides by the following:
'Don't use any emulation classes in library code unless your emulation
class is Array, and if it is Array, don't expose the Vector type on any
public or protected api surface because it will be a misleading
representation of the type to the user of that api'
The Vector instance being substituted with Array is a private instance and
is never exposed via public or protected access, so it is 'safe'
If someone (anyone), at some point, released the same swc after adding
public function getMyBeadVector():Vector.IBead {
return _beads; //share the private instance
}
I consider it not to be 'safe'.
(I'm not using angle brackets above because they mess up some readers it
seems)
At that point it gives someone else a potential problem, because it is
really returning an Array, instead of a distinctive Vector type, and can
only be 'safe-ish' if the user of the swc (it might be another library or
application) knows its limitations or happens to be applying the same
optimization to their own code (and accepting whatever risks they do with
that). It may not be obvious to the user of the swc that the instance is an
Array because their IDE tells them it is a Vector, but it can behave
differently to how they expect a Vector to behave. They might end up adding
code to offset the unusual behaviour, or doing things which break things
later if a more conformant Vector is swapped in. Using Array here is just a
specific example of the more general emulation class like approach, so
similar concerns apply to using other emulation classes.
Anyway, we can set that specific example of IBead aside. Like I said it is
'safe' as it is.
For the other points, most of them have been discussed already. The sky's
the limit for what options we could provide. But providing lots of options
is not itself without cost.
I already mentioned I'd rather add things for Vector optimization based on
feedback for what people need than try to guess what those things are or
assume that what I think is what they want.
For the Vector case in general, I think of it in two different ways
1. People trying to port existing as3 codebases.
Usually the goal is to get things working first and then optimize/customize
as necessary. At least that is the approach I am familiar with.
The first part of that is what I have been focused on with Vector - code
that 'just works' as-is when ported. The second part could be achieved by
using Vector configuration/tuning options. Or it could be by refactoring
portions of the original code to reflect best practice for specific
targets, or it could be by substituting new options (Harbs' and Josh'
suggestions) which reflect improved cross-target features for compile-time
only safety.
2. People writing new as3 code from scratch for royale
If 'compile-time' safety is the main goal, then what Harbs and Josh
suggested is the thing I personally would use most instead of Vector here.
That is what the (proposed) feature represents as being more
fit-for-purpose than Vector which has limited compile-time type safety
anyway. That could probably even support 'opt-in' runtime-safety checks for
things like push and unshift etc (instead of 'opt-out' from Vector, for
example), or maybe it could leverage the complex-implicit-coercions feature
in the branch which is more general, and can also be switched off globally
or toggled locally.
if 'run-time' safety is the main goal, they can choose Vector, with or
without performance tweaks.
or they can simply use Array. And add some debug only runtime safety for
example, just like we already discussed for IBead.
For numeric typed array performance, we also need a way to aim for best
cross target results, we already discussed that in the thread too. Maybe
that could be via improvements to the Vector implementation, maybe via what
Josh suggested, maybe some specific new classes. That is part of next steps.
Adding more and more configuration options might sound like a good idea,
but it could also mean we are spending lots of time on things people don't
care about.
I added the most obvious one for Vector in the branch, but held back on
doing more 'optimization options' for now, as I mentioned previously. But,
again, as I said earlier, I am happy to improve it with more options for
tuning it if there is demonstrable need. There are some minimal things that
I believe really would not make sense though, such as returning something
that is a regular Array instead of something that is recognizable as a
Vector type from concat, or slice methods, for example.
"We do not need to reach a collaborative decision that is A or B. Why
should we think we know what our users really need? We provide
options/choices so the users can decide for themselves. And invite someone
else to come up with even a better solution or solutions."
Agreed. But it might be better to get feedback on what people want instead
of unleashing an endless menu for those options/choices. And I say that as
someone who 'likes' lots of options and freedom to do things myself.
However offering a vast array of options can be confusing to people who are
unfamiliar with them, so we should at least consider that too. Building
that menu more based on feedback after 1.0 release is one approach to
consider in order to offer the options most aligned with the needs of the
community. It might even be a good way to draw more people into getting
involved in Royale. But I don't have any magic solution for us figuring out
where the threshold is for any particular thing, and I know we still need
to present our 'best guess' range of options at 1.0. Yours includes
Vector-as-Array and the emulation class approach. I accept that. If the
above example makes my concerns more clear to you now, maybe you can
re-read the latter part of my last message and see if that 'middle-ground'
part also makes more sense in context.
The only other thing I'd like to be really clear about is that I have no
emotional attachment to the Vector implementation in the branch. After I
merge you or others are free to improve it or completely replace it. The
only thing that would concern me is if all the unit tests that drove its
development did not continue to pass after any changes. I will port these
tests to Josh's setup in RoyaleUnit as soon as I can. I am actually more
'attached' to the unit tests than to the implementation. Having these unit
tests should provide a useful roadmap for any new targets that will need
their own language emulation support to be developed in the future (after
the dependencies for running the unit tests themselves have been emulated
in that same target).
Anyway, I 'stopped' posting because I felt like I'd explained everything I
could in terms of what I felt was important. I broke that extremely short
'silence' here with only one goal: to communicate more clearly what it
seems I have not succeeded in doing before now.
I hope I did that and that you at least understand why I have a certain
view, irrespective of whether you share the same concerns I expressed or
not. Regardless, I don't think I can express anything about this more than
I already have.
I also have no certainty that others share my specific concerns. Perhaps I
am really missing something here and they are not even valid. So far I
don't think so, but if they are, I can only apologize for wasting
everybody's time.
And as I said, I will add the functionality for Array output back.
So this is the real 'last message' :)
(That's probably a relief to many people, but it is also a relief to me,
because like I said, I don't find this to be the most efficient way to
communicate, it is considerable effort. )
On Wed, Jun 5, 2019 at 6:36 PM Alex Harui <aha...@adobe.com.invalid> wrote:
> Your summary of my opinion is not correct.
>
> If Vector-as-array is what the current develop branch output is, I am
> unable to understand how that output is incorrect or poses any risks for
> anyone who knows they will not need runtime type-checking or runtime
> fixed-length checking. And thus, it should remain an option. For sure, it
> was good enough for at least two production apps.
>
> If you are specifically referring to the use of Vector in the Strand, it
> occurred to me that someone could add another option to inject a type-check
> before every push on the Vector-as-Array. I think that would allow us to
> continue to use Vector in the Strand at a cost much less than 2K. And
> allow many others to get type-checking on push as well. Or, as we
> discussed earlier, we can just stop using Vector in the Strand.
>
> If you are saying that the risk and harm to the community will come when
> someone tries to add a bead to the strand at runtime that was instantiated
> in a way that was not testable at development time, then I guess we will
> have to agree to disagree on how important that is. IMO, that runtime
> checking should be PAYG, and I would much rather that we spend time
> devising a scheme to allow folks to opt-in to runtime checking than tell
> folks that they must carry around extra code just-in-case someone else
> needs runtime checking. It could be something as brute force as specifying
> files in a compiler option where the compiler will replace "goog.DEBUG"
> with "true". Specific to the strand, yet another option could just be a
> bead that watches for beadAdded events and checks for IBead. Could be we
> find a way to replace Vector-as-Array code in libraries with the Vector
> implementation you've written.
>
> Or maybe, we should spend more time getting the SWF versions of the
> framework running well enough to have RoyaleUnit or some test automation
> run your app in the Flash/AIR runtimes so lots more things get checked
> (missing interface members, other type-checks, etc).
>
> Regardless, it is still great that you've created a runtime-checking
> implementation of Vector for those who need it.
>
> We do not need to reach a collaborative decision that is A or B. Why
> should we think we know what our users really need? We provide
> options/choices so the users can decide for themselves. And invite someone
> else to come up with even a better solution or solutions.
>
> My 2 cents,
> -Alex
>
> On 6/3/19, 11:04 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> Hi Alex, this will be my last message in this thread.
>
> "The whole point of giving choices is to avoid having to spend so many
> emails trying to reach a decision. "
> Alex, I really don't understand your stance. The focus of the recent
> discussion has been on the choices themselves... concerns about their
> potential risks, along with ideas for improvements and code quality.
> It sounds like you are saying that we can't talk about improving the
> choices we already had, because if they exist that is all that matters.
> As far as I understand, the point of these email discussions is to
> reach
> the best quality collaborative decisions.
> I don't enjoy the process myself. It's inefficient. But we have an
> obligation to be collaborative (I think?). Expressing something along
> the
> lines of 'just do it and move on' does not seem to be that.
> I don't care about any of these things in terms of how it affects me
> personally, I have only pursued the topic in relation to what I think
> will
> help Royale be successful.
>
> The only way I can interpret your replies thus far is:
> More options for optimization are always better, even if they might
> present
> possible risks that could harm the community. We deal with those risks
> by
> issuing warnings.
> Specifically, in this case, a library developer being able to dictate
> certain optimization(s) that should be used by (and any associated
> risks
> that should be accepted by) the application developer is not
> unacceptable.
>
> -Your approach to mitigation of the above risks will be for us to warn
> people not to do the specific things that could cause the problems in
> the
> first place (from your comment about tools, risks, and documentation).
> Something like:
> 'Don't use any emulation classes in library code unless your emulation
> class is Array, and if it is Array, don't expose the Vector type on any
> public or protected api surface because it will be a misleading
> representation of the type to the user of that api'
>
> Is that a fair summary?
>
> It should be not surprise to you that I personally think the above is
> confusing and avoidable, because I consider that there are (and will
> be)
> better options that achieve the same optimization results. But I
> understand
> that you don't, and I can accept that. So I will make one last attempt
> to
> find something that I think is middle ground...
>
> Vector-as-Array is just a special case of the emulationClass approach.
> The only middle ground I can think of with regard to reducing the risk
> is
> to have the 'emulationClass' approach is to actually re-map the type
> in the
> javascript output, so the swc typing actually represents the type it
> has
> been transformed to.
> This means if people don't follow the above instructions and the type
> is
> exposed on an api surface then it is not misrepresented to unsuspecting
> users via the swc that has the optimization. Does that make any sense?
> I have no idea at this point if this is easy to do or not. But it would
> address the main things that worry me about this (again, not for me,
> for
> royale in general). I only got to this idea out of frustration,
> although
> perhaps it could be considered obvious in retrospect.
> I'm not able to tackle this in the near term but I will be happy to
> pursue
> it at some point if you can agree it is a good compromise ( I hope it
> might
> be). As I said, I won't continue any more in this thread. If you like
> it
> please let me know, otherwise I officially give up.
>
> For now, I will try to find time to add the Vector-as-Array back in
> sometime later this week. I will do it inside the vectorEmulationClass
> code
> branches in the compiler as a special case of ' vectorEmulationClass '.
> Once I have that done and working I will merge.
>
>
> On Sat, Jun 1, 2019 at 8:26 AM Alex Harui <aha...@adobe.com.invalid>
> wrote:
>
> > Greg, you are still trying to use the language conformance
> argument. This
> > is not an issue of language conformance, it is an issue of
> optimization.
> > Code paths not needed should not be downloaded. Every app
> development tool
> > I've used that offers optimizations offers optimization levels and
> > documentation of risks.
> >
> > There is a disagreement on how to implement Vector in JS as well.
> The
> > whole point of giving choices is to avoid having to spend so many
> emails
> > trying to reach a decision. Just provide choices so we can move
> on. Every
> > argument you make below is an argument for giving choices.
> >
> > -Alex
> >
> > On 5/30/19, 9:03 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
> >
> > "And so we will stop using Vector and migrate to using a plain
> Array.
> > That
> > agreement proves that the proposed changes are not right." We
> will
> > effectively encourage others to do the same.
> >
> > It does not prove that at all, Alex. It depends on the criteria,
> and we
> > have no commonly accepted guiding principles for what is 'right'
> here.
> > At least one of us believes that it is more correct that (in the
> > absence of
> > other proposed options) it be an Array in the original code.
> > If you take a step back and look at it from a broader
> perspective, it
> > can
> > be equally true to say 'This agreement proves that the original
> > implementation was not right'.
> > Firstly, I don't think Vector type was providing any benefit in
> this
> > case
> > in the first place (but that alone is not a reason to change it,
> > awareness
> > that it 'costs more' would however be a valid reason if there
> are no
> > benefits to using it).
> > Secondly, the collaborative outcome resulting in the use of
> explicit
> > Array
> > and the goog.DEBUG check is better than the original
> Vector-as-Array
> > output
> > because it offers the runtime type safety that was missing
> because it
> > was
> > not behaving like a Vector - and it retains the advantage of
> > zero-weight in
> > release build. Making these changes *is* a form of optimization
> based
> > on
> > using options currently available, it just happens to be
> hand-coded
> > and not
> > compiler-generated.
> > I know it's at least a little bit useful in its new form,
> because prior
> > testing with the branch level Vector implementation flagged a
> > non-conforming IBead in the 2nd app I tested it with, something
> that
> > was
> > not found by the original 'Array' implementation.
> > SWF testing in parallel would have caught that too, but is not a
> > realistic
> > assumption to have that as part of the workflow for checking
> runtime
> > behavior anymore, so this 'Array with debug-only typecheck' in
> > javascript
> > is a good outcome.
> > In this case, going back to Vector-as-Array output without
> making the
> > other
> > change would be a step backwards.
> >
> > That is however just one specific case, and I needed to present
> what I
> > believe is a more balanced view of that... but I will not focus
> on it
> > in
> > any further discussion.
> > I do understand that your point is intended to be more general.
> > In general, and *by definition*, the cases where you want Vector
> to be
> > Array without adverse consequences are always cases where it can
> also
> > *be*
> > Array in the original as3 code. If the only justification for it
> being
> > a
> > Vector in as3 code is 'compile-time type safety', then the
> proposed
> > alternative from Harbs and Josh is a better option because it
> retains
> > the
> > benefits you seek and is a better quality cross-target
> representation
> > for
> > this specific sort of requirement (it will also provide more
> benefits:
> > most
> > Vector methods do not have compile-time type safety because most
> their
> > method signatures do not specify :T types, I hope the proposed
> > alternative
> > might address that).
> > For the performance-oriented numeric types, which is another
> thing
> > that has
> > been raised, maybe Josh can somehow include that with the typed
> Arrays
> > feature as he suggested, maybe not. If yes, then great, but if
> not, I
> > am
> > happy to explore other options for that.
> >
> > What I'd really like to hear are your thoughts about the
> concerns I
> > raised
> > for the:
> > "new whateverclasstheconfigordirectivespecified()"
> > approach to doing any of this.
> >
> > How do you propose to avoid risk to the community and
> potentially to
> > Royale's reputation with release of swcs that can have different
> > language-level variations in them (XML, Vector or anything that
> > represents
> > a core as3 'type')?
> > Do we have to warn people not to do that, and then hope that they
> > don't? A
> > user of that swc doesn't see the emulation class that the swc may
> > expose
> > without investigating at runtime, they normally only see the
> type it
> > represents, and unless they are warned, they have no reason to
> assume
> > it
> > won't do all the things it should. There could also be runtime
> conflict
> > implications when mixing swcs with different emulation
> decisions, and
> > that
> > could even add weight overall compared to using one. None of this
> > represents stuff that can't be figured out and addressed by
> developers
> > who
> > have to deal with it. But it seems to me to be something
> negative,
> > which
> > would be better to avoid.
> >
> > I think you are indicating the same desire to avoid this problem
> by
> > saying
> > that you want to specify things by 'the swc' you add (e.g. XML
> > replacement)... but that can be too late, because even if an
> alternate
> > emulation class itself is not bundled into a swc's code, all the
> calls
> > to
> > instantiate it are, which reflect its distinct package name and
> class
> > name.
> > I can envisage ways to achieve optimization and to avoid risks
> for the
> > general case, but only if the instantiation calls for these
> language
> > level
> > emulations can never vary throughout the entire codebase (all
> swcs
> > included), and the 'optimization' is therefore largely driven
> from the
> > application build, and not dictated at swc level. Maybe swc
> libraries
> > could
> > be advertised as being compatible with some well-known
> optimizations in
> > this case, it could even be a 'marketing' claim for the swc.
> > The most appealing optimization solution (to me) would be one
> that
> > takes
> > more advantage of GCC (which I consider will be 'safer', and
> also least
> > effort for the developer) when the application gets built,
> instead of
> > actually changing the content of individual methods (for
> example) in
> > 'lite'
> > versions of replacement classes. However, I can see that doing
> the
> > latter
> > (or both) should also be possible and should not be much
> different, I
> > think, from a regular monkey-patch approach, or from your desire
> for
> > swc
> > level replacement - but it only works if there is no variation
> in the
> > actual naming of the classes that are being 'patched' (whether
> its via
> > an
> > alternate XML-like swc as a direct substitute for the standard
> one, or
> > a
> > local monkey patch). Maybe I'm missing something that is obvious
> to
> > you...
> > please tell me if I am.
> >
> >
> > On Fri, May 31, 2019 at 6:37 AM Alex Harui
> <aha...@adobe.com.invalid>
> > wrote:
> >
> > > It is pretty simple to me. The proposed Vector implementation
> is
> > heavy
> > > enough that we all agree that we don't want to use it for just
> one
> > use case
> > > in the Strand. And so we will stop using Vector and migrate to
> > using a
> > > plain Array. That agreement proves that the proposed changes
> are not
> > > right. We will effectively encourage others to do the same.
> > >
> > > It would be much better if Royale had a way for developers to
> > specify that
> > > the one use of Vector in the Strand should be converted to
> plain
> > Array by
> > > the compiler and other uses could use the proposed Vector.
> That's
> > how
> > > optimization should be made available for all kinds of code in
> > Royale, not
> > > just for Vector.
> > >
> > > The current Vector output in the develop branch is low cost
> and fully
> > > functional for some uses cases. As long as that output is
> still
> > available
> > > as a compiler option then having other output fine.
> > >
> > > I still haven't found time to look at the actual proposed
> changes,
> > but I
> > > would strongly prefer that, instead of having to modify
> compiler
> > output
> > > each time someone proposes a different Vector implementation,
> that
> > the
> > > changes can all be done by which SWC you choose for your Vector
> > > implementation. There are other places in the compiler where
> you can
> > > choose the class to use for Binding or ClassFactory.
> Hopefully the
> > same
> > > approach is being used for Vector. Ideally, the compile would
> just
> > output
> > > "new whateverclasstheconfigordirectivespecified()" and then
> just
> > output the
> > > usual push/pop/index calls and so it could just be plain Array
> where
> > > specified or the proposed Vector and some other Vector someday.
> > >
> > > This is a case were "there is no one right way". And when we
> have
> > those
> > > situations, we must offer choices.
> > >
> > > -Alex
> > >
> > > On 5/30/19, 1:34 AM, "Carlos Rovira" <carlosrov...@apache.org>
> > wrote:
> > >
> > > Hi,
> > >
> > > @Alex Harui <aha...@adobe.com> I think you misunderstood
> me.
> > I'm not
> > > saying
> > > we should "remove choices". What I say is that we have
> finally a
> > more
> > > robust implementation and we can evolve to have more
> choices
> > from that
> > > point. I think continue from that safe point will give us
> many
> > > benefits. So
> > > I want those choices. What I don't want is to wait to make
> it
> > perfect
> > > to
> > > merge. As I said before perfection is enemy of the
> progress.
> > >
> > > An important point I can't agree with you: Why we don't use
> > Vector in
> > > our
> > > production App? Cause we can't. To do that we need: a) Greg
> > changes
> > > merged,
> > > b) make AMF understand Vectors (still to be done to make
> Vector
> > usable
> > > for
> > > us). Without both points Vectors are not an option for us.
> So I
> > think
> > > the
> > > premise of "we have 2 apps in production without Vectors"
> are not
> > > right. We
> > > don't have still Jewel DataGrid, or Swiz Global
> Dispatcher, and
> > that
> > > does
> > > not mean it's ok for us. Is just we still don't have it,
> but
> > making us
> > > to
> > > make our product without all of that is a serious issue
> that we
> > need to
> > > workaround in some way. But we can do that as something
> > "temporal",
> > > due to
> > > current Royale limitations. But our goal is to have all
> that,
> > > Vector-AMF
> > > included :)
> > >
> > > For this reason, I prefer to have Greg's Vector now, since
> it
> > makes our
> > > production App be one step closer to remove current
> workarounds
> > :)
> > > And I'm sure that not having a Vector solution like this,
> could
> > be a
> > > reason
> > > why some people still didn't try Royale to migrate to this
> date.
> > > So if you ask me or those people for a "priority path", we
> will
> > say
> > > "let's
> > > get Vector first, then evolve from that to have more
> choices".
> > > That's what I'm saying it's ok to merge now.
> > >
> > > I'm ok with having Vector as we all know it from AS3
> (since is
> > > that...AS3
> > > Vector, don't forget that, and is what people expect to
> have at
> > first
> > > sight, then we can give them more choices and they will
> > appreciate for
> > > sure), and have as well a new Typed Array too as other
> proposed
> > too.
> > > That
> > > will be for me options. But we should not wait to make all
> that
> > happen
> > > to
> > > merge current branch, right?, All that we'll be lots of
> time to
> > make it
> > > perfect from day 0.
> > >
> > > The key concept for me was what Harbs said in his response
> to
> > the end.
> > > If
> > > you don't use it the impact is 0, not 2-3k, since people
> don't
> > have
> > > Vector
> > > presence in their codes. So that's PAYG. For that reason
> it's ok
> > for
> > > me to
> > > merge and continue from that safe point, since we really
> only get
> > > positive
> > > things and nothing negative, and since we all agree in the
> same
> > terms,
> > > just
> > > we need more time to continue evolving it to get to that
> perfect
> > final
> > > point.
> > >
> > >
> > >
> > >
> > > El jue., 30 may. 2019 a las 7:56, Greg Dove (<
> > greg.d...@gmail.com>)
> > > escribió:
> > >
> > > > Harbs some quick comments inline...
> > > >
> > > > On Thu, May 30, 2019 at 4:27 PM Harbs <
> harbs.li...@gmail.com>
> > wrote:
> > > >
> > > > > The only niggle I have with my approach is that Vector
> in
> > Flash is
> > > more
> > > > > performant than array, while in JS, it’s going to be
> the
> > other way
> > > > around.
> > > > > So if someone has a performance-sensitive piece of
> code, how
> > > should they
> > > > > write it so it outputs as performant as possible on
> both
> > platforms?
> > > > >
> > > > > Vector in flash is only substantially faster for its 3
> > numeric
> > > types
> > > > which
> > > > are optimized. It is (slightly) slower than Array in
> other
> > cases - I
> > > think
> > > > it is normal that the extra type checking takes time
> even in
> > native
> > > code.
> > > > I remember seeing some data which said it was 30% slower
> for
> > some
> > > methods
> > > > with the non-primitive types, but that may be old.
> > > >
> > > > In terms of the emulation version, you can get
> javascript Array
> > > speed with
> > > > the index access and assignment, which should be a
> direct copy
> > of
> > > the same
> > > > parts of code that are heavily optimized in flash I
> think.
> > > >
> > > > I was running performance tests on the non-debug flash
> player
> > > alongside
> > > > javascript. I actually see the regular native javascript
> Array
> > > beating
> > > > flash numeric Vectors in Chrome on windows, for the same
> tasks.
> > > Perhaps the
> > > > pepper plugin is getting less cpu resource than the
> browser or
> > > something
> > > > like that, not sure. I had assumed TypedArrays would be
> > faster, but
> > > > recently you said you weren't sure because of js engine
> > smarts. I
> > > will
> > > > still check that.
> > > >
> > > >
> > > >
> > > > > I have not spent the time looking into the
> implementation,
> > but I
> > > think
> > > > > there might be some cross-communication. My
> understanding
> > from
> > > what Greg
> > > > > wrote is that if Vector is not used in an application,
> there
> > will
> > > be no
> > > > > extra code due to dead code removal. If that’s
> correct, I
> > think
> > > we’re in
> > > > > agreement that the implementation is fine. Do I
> understand
> > > correctly?
> > > > >
> > > >
> > > > That is correct.
> > > >
> > > >
> > > > >
> > > > > Harbs
> > > > >
> > > > > > On May 30, 2019, at 1:26 AM, Josh Tynjala <
> > > joshtynj...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > I definitely want the default choice to have as few
> > surprises as
> > > > > possible when it comes to how ActionScript behaves in
> Royale.
> > > We'll never
> > > > > have a perfect emulation, of course, but there are
> things
> > that I
> > > think
> > > > can
> > > > > still be improved. At the same time, I think it's
> perfectly
> > valid
> > > for
> > > > > someone to want to opt into a typed Array that doesn't
> have
> > the
> > > runtime
> > > > > overhead of Vector and isn't as heavy in file size.
> I'm wary
> > of the
> > > > > solution being a custom implementation of Vector with
> missing
> > > features,
> > > > > though. It will lead to confusion, even if it's opt-in.
> > > > > >
> > > > > > What Harbs suggested seems like a smart way to go.
> Rather
> > than
> > > having a
> > > > > separate Vector implementation that doesn't work as
> > developers are
> > > used
> > > > to,
> > > > > a new variation of Array that has compile-time type
> checks
> > but no
> > > runtime
> > > > > checks sounds like a more elegant solution. Like Vector
> > works in
> > > Royale
> > > > > today, it can compile down to a regular JS Array, but
> at
> > > compile-time,
> > > > we'd
> > > > > have some extra safety and could even possibly cast
> back and
> > forth
> > > with
> > > > > untyped Arrays (which we can't do with Vector).
> > > > > >
> > > > > > - Josh
> > > > > >
> > > > > > On 2019/05/29 18:07:31, Alex Harui
> > <aha...@adobe.com.INVALID>
> > > wrote:
> > > > > >> We must not eliminate choices.
> > > > > >>
> > > > > >> I still haven't had time to look at the branch.
> > > > > >>
> > > > > >> There must be away to avoid even a 1K cost to those
> who
> > don't
> > > need it.
> > > > > >>
> > > > > >> If there is such a way, then it is fine to merge.
> > Otherwise,
> > > everyone
> > > > > is going to pay 2K to use a Vector when we know at
> least two
> > apps
> > > are in
> > > > > production without needing that 2k.
> > > > > >>
> > > > > >> There are too many words being written and no
> technical
> > points
> > > being
> > > > > made. I will try to resummarize.
> > > > > >>
> > > > > >> 1) It does not matter how fast your network is.
> Every
> > other
> > > app will
> > > > > use more bandwidth and when the network gets busy or
> > connectivity
> > > gets
> > > > poor
> > > > > (something I see quite frequently where I live) either
> you
> > get
> > > your app
> > > > to
> > > > > run or you run out of time.
> > > > > >>
> > > > > >> 2) If you are not using some feature of our code,
> you
> > should
> > > not have
> > > > > to pay for it in download cost. That's PAYG. That
> would be
> > true
> > > for
> > > > > Vector, XML and even if we had to write a Date
> > implementation. It
> > > is not
> > > > > an issue of non-conforming. It is an issue of
> > optimization. If
> > > you
> > > > aren't
> > > > > going to use some feature of E4x you should have the
> option
> > of
> > > using code
> > > > > that doesn't have those code paths. Same for if we
> had to
> > do Date.
> > > > > >>
> > > > > >> We know that if you don't need runtime-type
> checking and
> > > fixed-length
> > > > > checking that a plain Array is just fine and 2K
> cheaper.
> > Let's
> > > give
> > > > folks
> > > > > the option to do that.
> > > > > >>
> > > > > >> I will repeat that I do not have any objection to
> having
> > a full
> > > Vector
> > > > > implementation with runtime type-checking and fixed
> length
> > > checking be
> > > > the
> > > > > default choice as long as folks can optimize back to
> using
> > the
> > > plain
> > > > Array
> > > > > code we use now.
> > > > > >>
> > > > > >> For the one Vector we currently have in all apps
> for the
> > > Strand, it
> > > > > might be time to change that to an array and check the
> type
> > (in
> > > > debug-only
> > > > > code) on addBead. Either that or we add compiler
> options so
> > that
> > > one
> > > > > Vector gets optimized to the current plain Array code.
> > > > > >>
> > > > > >> It is not a technical argument to classify Vector as
> > "Language"
> > > and
> > > > > therefore somehow an exception to being optimizable.
> > > > > >>
> > > > > >> My 2 cents,
> > > > > >> -Alex
> > > > > >>
> > > > > >>
> > > > > >> On 5/28/19, 2:59 AM, "Carlos Rovira" <
> > carlosrov...@apache.org>
> > > > wrote:
> > > > > >>
> > > > > >> Hi,
> > > > > >>
> > > > > >> I think that we all agree in most of the things,
> and
> > > although we're
> > > > > >> discussing some particularities on how to solve,
> my
> > opinion
> > > is that
> > > > > those
> > > > > >> particularities can be solved after merging
> Language
> > > improvements
> > > > > branch.
> > > > > >> We all agree we need this Vector (and other
> > improvements in
> > > this
> > > > > branch)?.
> > > > > >> So, after that merge folks wanting to improve,
> let's
> > say,
> > > > Vector(for
> > > > > >> example) even more with new choices can do that
> without
> > > problem and
> > > > > will
> > > > > >> make it even better.
> > > > > >>
> > > > > >> Are we ok with that?
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> El mar., 28 may. 2019 a las 11:07, Harbs (<
> > > harbs.li...@gmail.com>)
> > > > > escribió:
> > > > > >>
> > > > > >>>
> > > > > >>>> On May 28, 2019, at 11:12 AM, Greg Dove <
> > greg.d...@gmail.com>
> > > > wrote:
> > > > > >>>>
> > > > > >>>>> "I personally have never used length checking in
> > Vector. Nor
> > > was
> > > > > runtime
> > > > > >>>>> type checking on Vectors important to me. "
> > > > > >>>> length checking is automatic in flash. I don't
> know
> > that you
> > > 'use'
> > > > > it...
> > > > > >>> it
> > > > > >>>> is just there.
> > > > > >>>
> > > > > >>> True. What I meant is that I never used fixed
> length
> > Vectors.
> > > > > >>>
> > > > > >>>> In javascript I expect it would most often be
> switched
> > off in
> > > all
> > > > > release
> > > > > >>>> builds, but having it on by default provides
> another
> > check of
> > > > > something
> > > > > >>>> that could provide a vital clue to help people
> figuring
> > out
> > > problems
> > > > > in
> > > > > >>>> code.
> > > > > >>>> So far each 'stronger typing' feature added in
> the last
> > few
> > > months
> > > > has
> > > > > >>>> revealed potential issues or - most often - bad
> code
> > that was
> > > > working
> > > > > >>> when
> > > > > >>>> it should not
> > > > > >>>
> > > > > >>> Good points, and one that argues for the ability
> to have
> > these
> > > checks
> > > > > >>> while debugging and have the run-time code removed
> on
> > release.
> > > > > >>>
> > > > > >>>> One thing about the mxml stuff is that it gets
> > processed in a
> > > way
> > > > > that is
> > > > > >>>> untyped.
> > > > > >>>
> > > > > >>>
> > > > > >>> Agree. I do wish there was some way for MXML to be
> output
> > > “better”
> > > > > where
> > > > > >>> minified vars could “just work” and types could be
> better
> > > inferred
> > > > > from the
> > > > > >>> MXML files.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Carlos Rovira
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C5b7ab8201190466822d808d6e8b27112%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636952250440875188&sdata=5GD9W1AzFE837vinQ1oVWZr7%2FRRad1YqY9DpIkSVYIk%3D&reserved=0
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C5b7ab8201190466822d808d6e8b27112%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636952250440875188&sdata=5GD9W1AzFE837vinQ1oVWZr7%2FRRad1YqY9DpIkSVYIk%3D&reserved=0
> > >
> > >
> > >
> >
> >
> >
>
>
>
