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%7C7b5824f745304f9e222308d6e57cfac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948722282899722&sdata=T5XYilhl3fSjVqu60ZolwQWXIczCR5w73axIKMd%2BDS0%3D&reserved=0
> > > >>
> > > >>
> > > >>
> > >
> > >
> >
>
>
> --
> Carlos Rovira
>
>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7b5824f745304f9e222308d6e57cfac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948722282899722&sdata=T5XYilhl3fSjVqu60ZolwQWXIczCR5w73axIKMd%2BDS0%3D&reserved=0
>
>
>
