Re: Static Initializers

Thanks, I will definitely come back to this as a reference when I look at that. On Wed, Nov 6, 2019 at 1:38 PM Alex Harui wrote: > I noticed and wondered if it was dialect. __ > > Just to try to dump related information into this thread so it is all here > if you do get back to it: > > In a

Re: Static Initializers

I noticed and wondered if it was dialect. __ Just to try to dump related information into this thread so it is all here if you do get back to it: In a Royale class's JS file, we used to set up the Object.definePropertles like this: public class A { private var _foo:int = 0; public

Re: Static Initializers

I don't know where I got 'overally' from. I think I started that one with generally and got halfway through changing it. :) On Wed, Nov 6, 2019 at 1:07 PM Greg Dove wrote: > Yeah, that's pretty much what I meant. And the issue you expressed is a > more detailed analysis of what I was

Re: Static Initializers

Yeah, that's pretty much what I meant. And the issue you expressed is a more detailed analysis of what I was anticipating as the main issue with this approach. The split out of private statics was not something that I thought about, but overally it could still be a viable option - at least worth a

Re: Static Initializers

I won't be doing any more work in this area unless the lack of minification of private statics becomes a major issue for a user. Or if there is a bug in the just-committed implementation. I think I now understand what you are proposing. That's really good thinking, however, I'm not sure it

Re: Static Initializers

Suggestions for better terminology and acronyms are welcome, although I don't think I agree on what is "optimized compiler output". All I was trying to say is that I think we over-use the term 'PAYG' for things outside its specific and unique (for Royale) meaning. As far as I can see, this topic

Jenkins build is back to normal : royale-asjs_jsonly #149

See

Re: Static Initializers

Suggestions for better terminology and acronyms are welcome, although I don't think I agree on what is "optimized compiler output". You are correct that private statics won't be minified as well as they used to, but switching to getters solved a lot of other problems so I'm pushing these

Re: Static Initializers

Side comment: I actually prefer to limit the way I think of 'PAYG' as enabling options for the user to compose incremental pieces of functionality together, instead of using it to describe 'anything' that represents optimized compiler output. For me, PAYG is something that users actively 'do'.

Re: [royale-asjs] branch develop updated: Still figuring out the sass stuff... refactor setup for VSlider into Jewel. TBC via Carlos...

Ops, sorry, I saw you already did it :) thanks! El mar., 5 nov. 2019 a las 20:08, Carlos Rovira () escribió: > Hi Greg, > thanks for adding this. I'll try to see SASS things on week end. > Can you add example(s) to Slider page in Tour de Jewel? > thanks! > > El mar., 5 nov. 2019 a las 6:21,

Re: [royale-asjs] branch develop updated: Still figuring out the sass stuff... refactor setup for VSlider into Jewel. TBC via Carlos...

Hi Greg, thanks for adding this. I'll try to see SASS things on week end. Can you add example(s) to Slider page in Tour de Jewel? thanks! El mar., 5 nov. 2019 a las 6:21, escribió: > This is an automated email from the ASF dual-hosted git repository. > > gregdove pushed a commit to branch

Re: Static Initializers

Makes sense to me. > On Nov 5, 2019, at 7:41 PM, Alex Harui wrote: > > FWIW, here is the pattern that appears to work in JSFiddle for a "static var > foo": > > o.get__foo = function() { > var value = > Object.defineProperty(o, 'foo', {value : value, writable: true}); > return value; >

Re: Static Initializers

FWIW, here is the pattern that appears to work in JSFiddle for a "static var foo": o.get__foo = function() { var value = Object.defineProperty(o, 'foo', {value : value, writable: true}); return value; } o.set__foo = function(value) { Object.defineProperty(o, 'foo', {value : value,

Re: Static Initializers

Good point on PAYG. If we use #2 with one-time lazy evaluation, I think that’s the best of both worlds. Thanks, Harbs > On Nov 5, 2019, at 6:44 PM, Alex Harui wrote: > > Yeah, in my local branch I'm playing with various ways to not run the > initializer more than once. We can tweak the

Re: Static Initializers

Yeah, in my local branch I'm playing with various ways to not run the initializer more than once. We can tweak the pattern later. It involves re-defining the property, but isn't quite the patterns offered below. IMO, #2 is more PAYG than #1. In #1, all initializers run regardless of

Build failed in Jenkins: royale-asjs_jsonly #148

See Changes: -- [...truncated 1.15 MB...] [java] Nov 05, 2019 12:24:28 PM com.google.javascript.jscomp.LoggerErrorManager println [java]