On 7/17/16, 11:45 PM, "Harbs" wrote:
>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.
Harbs, if our code normally had problems loading subclasses bef
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
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
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
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:
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
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
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).
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, 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
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
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
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
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
14 matches
Mail list logo
