>Done for that method - any other methods need the same treatment?
UIComponent::initialize() is probably the best example. Its overwritten and
mangled quite successfully by the compiler.
Mike
Hi,
> That brings up a very interesting point. I am not sure how much work this is
> but it would be extremely helpful to developers looking at the source code to
> have methods with compiler-based mixins (or whatever you want to call them) be
> indicated as such in framework code comments, so we
>so we don't have do this sort of "mystery meat" guesswork whilst debugging.
Totally agree.
>I know you can find what code the compiler outputs by using the
>"keep-generated-actionscript" and doing a diff with the uncompiled code, but
>that's just such a pain to look up something which should t
That brings up a very interesting point. I am not sure how much work this is,
but it would be extremely helpful to developers looking at the source code to
have methods with compiler-based mixins (or whatever you want to call them) be
indicated as such in framework code comments, so we don't have d
aha! thanks a lot!
On Sat, Jan 4, 2014 at 7:18 PM, Michael A. Labriola <
labri...@digitalprimates.net> wrote:
> >Anyone have a clue where skinParts is getting populated from? Its not
> overridden in a derived class, so really not sure how/whats populating it?
>
> It's compiler magic. The compil
>Anyone have a clue where skinParts is getting populated from? Its not
>overridden in a derived class, so really not sure how/whats populating it?
It's compiler magic. The compiler creates a static variable called _skinParts
on each class with the skin parts for the class in it. It then override
In SkinnableComponent, there is this:
protected function findSkinParts():void
{
if (skinParts)
and then there is this:
protected function get skinParts():Object
{
return null;
}
Anyone have a clue where skinParts is getting populated from? Its not
overrid
