I did think of the variable issues. Using instance variables does not generally
strike me as problematic. (unless there’s a lot of them)
I did find some interesting articles on inlining vs function calling. Here’s
one.[1]
Too many super calls might be bad because “call” can be expensive.
Yes.
You're welcome to try different approaches to sharing code in the base
classes. Often, though, loops over children need to be inlined not only
for performance reasons (to cut out one function call in the inner loop),
but also for information sharing reasons (local variables accumulating
values
Here’s a dilema I ran into this morning:
The OneFlexibleLayout beads have some code which look like this:
if (!contentView.element.style["align-items"])
contentView.element.style["align-items"] = "center”;
What that does, is check if “align-items” is already set and sets it to center
if
and consolidate the various
discussions on this. I still have that intention, just not the time
available right now. Please do not hesitate if you want to kick this off in
the wiki yourself.
On Tue, Jul 25, 2017 at 9:44 AM, Josh Tynjala <joshtynj...@gmail.com> wrote:
> Okay, so PAYG c
Okay, so PAYG can't have One True Definition. How you implement PAYG
depends on context.
I wonder if some kind of PAYG pattern cookbook would be helpful? I was
thinking that our situations with PAYG remind me of software design
patterns. Design patterns aren't really defined with an exact
cted = true;
> }
>
> But if this is framework code convention let's live it as is. I just didn't
> notice that is look like that.
>
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context:
> http://ap
/FlexJS-PAYG-and-dataGroups-tp63496p63511.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
gt;
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context:
> http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63509.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63509.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
ld have that code?
>
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context:
> http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63502.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
piotrzarzyck...@gmail.com
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63502.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
;harbs.li...@gmail.com>
Sent: Sunday, July 23, 2017 1:11:14 PM
To: dev
Subject: [FlexJS] PAYG and dataGroups
I just ran into a bug in my app as follows:
ListView has the following function:
protected function rollOverIndexChangeHandler(event:Event):void
{
if (lastRollOve
I just ran into a bug in my app as follows:
ListView has the following function:
protected function rollOverIndexChangeHandler(event:Event):void
{
if (lastRollOverIndex != -1)
{
var ir:ISelectableItemRenderer =
dataGroup.getItemRendererForIndex(lastRollOverIndex)
Hi All,
You guys have really interesting conversation related to PAYG. [1] Let's
continue it all here!
[1]
http://apache-flex-development.247.n4.nabble.com/Re-git-commit-flex-asjs-refs-heads-develop-Add-FileUploaderWithResponseData-td63051.html
Thanks,
Piotr
-
Apache Flex PMC
Hi,
I promised some feedback on Greg's PAYG page. After thinking about it
some more, I'm proposing my take on it below. I know past discussion
tried to break off component set definitions from PAYG, but I think PAYG
is always going to be subjective enough that the goals of the various
component
>> blocks, or similar, so having the possibility, as described, to exclude
>> development-only code (extra type checking, null checks etc) would
>> definitely also be helpful PAYG-wise from within the framework.
>>
>> The general issue here I think is that using this approach
In application development I would normally do this type of thing inside
CONFIG::dev
blocks, or similar, so having the possibility, as described, to exclude
development-only code (extra type checking, null checks etc) would
definitely also be helpful PAYG-wise from within the framework
similar, so having the possibility, as described, to exclude
> development-only code (extra type checking, null checks etc) would
> definitely also be helpful PAYG-wise from within the framework.
>
> The general issue here I think is that using this approach for the
> framework requ
ayBuffer.
>>
>> I would like to add a typecheck to the bytes argument in the BinaryData
>> constructor to throw an error if something other than an ArrayBuffer is
>> provided. We cannot use strict typing to catch this in the compiler,
>> because the argument is differ
.com>> wrote:
>>
>>> I just wasted over an hour because I was initializing a BinaryData with a
>>> string instead of an ArrayBuffer.
>>>
>>> I would like to add a typecheck to the bytes argument in the BinaryData
>>> constructor to throw an error if so
argument is different for SWF and JS. Is this a violation of
>PAYG? It’s sort-of just in case code, but not really because it’s
>protecting against errors.
>
>Thoughts? Other solutions?
>Harbs
to catch this in the compiler, because
the argument is different for SWF and JS. Is this a violation of PAYG? It’s
sort-of just in case code, but not really because it’s protecting against
errors.
Thoughts? Other solutions?
Harbs
tion guide, populating it with content from discussions
that have already begun, and then adding more in the future in exactly the
way ( PAYG-ish ) that you describe.
"I'm just not sure we are ready to start paving roads and putting up street
signs."
If by this you mean end-user docum
eason IMO to have some documentation and censuses around concepts
like PAYG. Bus factor is a concern here. [1]
> My managers would much rather that I help one or two customers migrate their
> code than
> write documents so 100 folks can migrate on their own because we still
> have eno
Hi,
Thanks for that Greg and good to see it started some conversation around this.
Thanks,
Justin
To me it's a bit difficult to digest in its current format. I would prefer to
see a list of design patterns with descriptions of concrete problems and
proposed solutions. This doc could be PAYG in itself. You come across a
problem, solve it with PAYG, add an item in the doc, if the idea isn't
Great start.
I just made some additions and changes. Hopefully I helped make it clearer and
not the other way around… ;-)
I just want to say, that while PAYG is hard both from a framework development
perspective and from an application development perspective, I firmly believe
that strict
half notes. There is more to harvest from
> >list discussions I think, some topics have progressed further than when I
> >started trying to capture ideas, so please correct any mistakes in the
> >definitions or add topics and questions that need 'resolution'/guidance.
> >
> >I person
currently half content, half notes. There is more to harvest from
>list discussions I think, some topics have progressed further than when I
>started trying to capture ideas, so please correct any mistakes in the
>definitions or add topics and questions that need 'resolution'/guidance.
>
in the
definitions or add topics and questions that need 'resolution'/guidance.
I personally would like to see some concrete guidance in the 'How does PAYG
get implemented' section. There were definitely the beginnings of some
healthy discussions around some of the options for beads for example
30 matches
Mail list logo
