It looks to me like something broke.
The compiler is interpreting XML internals as if they are XML objects. For
example, in XML.child():
list.targetObject = this;
list.targetProperty = propertyName;
becomes :
list.setChild('targetObject', this);
Hi,
I just got the confirmation that the new flex-typedefs git repo is now
available. Now I'd start moving the externs to that repo (while keeping the
commit history).
Chris
I moved some classes out of Core into a new project named Language that
doesn't have any framework stuff in it (so that pure AS projects don't see
classes that they don't need). I added Language as a new dependency to the
config for XML, but I don't think this change would affect the generated
code
I think it’s supposed to compile it correctly when -compiler.strict-xml=true is
set.
It looks like it’s set in the build.xml file in XMLJS, but the output does not
look like it.
Something also changed recently with how ant works. It used to work that I
could build both the swcs and generated s
The following code (from Base64):
private static const _encodeChars:Vector. =
InitEncoreChar();
private static function InitEncoreChar():Vector.
{
var encodeChars:Vector. = new Vector.(64,
true);
On 7/17/16, 11:48 AM, "Harbs" wrote:
>The following code (from Base64):
> private static const _encodeChars:Vector. =
> InitEncoreChar();
> private static function InitEncoreChar():Vector.
> {
> }
>
>Trying to run this code in javascr
This is probably related to the change that fixed the assignment to an XML
variable.
-Alex
On 7/17/16, 11:18 AM, "Harbs" wrote:
>I think it’s supposed to compile it correctly when
>-compiler.strict-xml=true is set.
>
>It looks like it’s set in the build.xml file in XMLJS, but the output
>does
Well, one simple fix might be to move all functions before variables. This
should work because functions are not evaluated until they are run.
I think there is a bigger issue which I’m running into in other classes: I’m
getting all kinds of errors which I think are due to the order of classes be
Maybe I'm missing something, but why are you worried about it being called
more than once?
What scenario requires an instance initializer instead of code in the
constructor?
-Alex
On 7/17/16, 9:59 PM, "Harbs" wrote:
>Well, one simple fix might be to move all functions before variables.
>This s
A number of reasons:
1. performance
2. If the code does calculations which might change later on
3. If it needs to always reference the same object, you don’t want it
reassigned.
For instance initialization, you need to setup your prototype only once, or bad
things could happen — and the bas cla
On 7/17/16, 10:51 PM, "Harbs" wrote:
>A number of reasons:
>1. performance
>2. If the code does calculations which might change later on
>3. If it needs to always reference the same object, you don’t want it
>reassigned.
But who would call it more than once?
>
>For instance initialization, yo
Well, I guess the question is where the init functions would be called.
My idea was that the “instance init function call would be added to the
constructor as the first thing that happens (with the exception of calling init
on the super-class first).
The class initializers is more of a question
On 7/17/16, 11:02 PM, "Harbs" wrote:
>Well, I guess the question is where the init functions would be called.
>
>My idea was that the “instance init function call would be added to the
>constructor as the first thing that happens (with the exception of
>calling init on the super-class first).
This still does not address the issue where a class is relying on another class
in a static variable.
MyClassA.myB:MyClassB = MyClassB.getInstance();
If MyClassA is loaded before MyClassB, this code will fail.
If however, both classes are first loaded and only then, the initializers are
called
I’m also not sure how the prototype is being setup.
It could be you’ve already solved my concerns there, but it looks like a lot of
the prototype is being setup outside the constructor.
On Jul 18, 2016, at 9:10 AM, Alex Harui wrote:
>
>
> On 7/17/16, 11:02 PM, "Harbs" wrote:
>
>> Well, I g
On 7/17/16, 11:25 PM, "Harbs" wrote:
>I’m also not sure how the prototype is being setup.
>
>It could be you’ve already solved my concerns there, but it looks like a
>lot of the prototype is being setup outside the constructor.
Scalar prototype initializers are set on the prototype property:
To be clear:
I’m currently struggling with goog.inherits(MySubClass, MySuperClass); For some
reason (which I’m not totally clear on) MySubClass is being loaded first, and
MySuperClass is not yet defined when this code is called.
If goog.inherits was mored to an initializer which is lazy-evaluat
A simple test case might help us understand the issue better.
-Alex
On 7/17/16, 11:35 PM, "Harbs" wrote:
>To be clear:
>
>I’m currently struggling with goog.inherits(MySubClass, MySuperClass);
>For some reason (which I’m not totally clear on) MySubClass is being
>loaded first, and MySuperClass
The issue should be clear.
If MySuperClass.js has not yet been loaded when MySubClass.js is loaded,
goog.inherits(MySubClass, MySuperClass); which is in MySubClass.js will cause
an error.
This code is being added to the JS file right after the constructor is being
defined, but it’s not wrapped
19 matches
Mail list logo
