I recently implemented weak event listeners in OpenFL's JS target using WeakRef.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakRef I think that's good evidence that we can implement it similarly in Royale. -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Thu, Feb 20, 2025 at 9:06 PM Greg Dove <greg.d...@gmail.com> wrote: > Thanks Josh, that's all helpful to know. > > iirc I think we are also currently blocked from updating our closure > compiler version because of some local subclasses or overrides where the > base classes or implementation was changed inside in a more recent GCC > version, but it's been some time since I tried to look into that, so I > might be wrong. > > In terms of events, I'd be happy to look at that in several months time if > we can wait, I will likely not find time before that. > > Lots of things changed in js since the start, and it seems that if we > really wanted to we could support weak event listeners now, for example. > > more modern outputs from our compiler are another future option, which > might make debugging in the js version of the code much easier. > > -Greg > > > > On Fri, Feb 21, 2025 at 12:20 PM Josh Tynjala <joshtynj...@bowlerhat.dev> > wrote: > > > Hi team, > > > > Today, I noticed that the GitHub repo for Google's Closure Library is now > > archived/read-only, and the README contains the following message. > > > > Closure Library has been archived. We no longer see it as meeting the > needs > > > of modern JavaScript development, and we recommend that users look for > > > alternative solutions. > > > > > > Please see https://github.com/google/closure-library/issues/1214 for > > more > > > details. > > > > > > This applies to Closure Library only. We also use the related Closure > > Compiler in Royale. Google addresses Closure Compiler specifically in the > > issue mentioned above: > > > > We still believe that Closure Compiler is the best advanced optimizer in > > > terms of minified size, as long as it can assume that all input code > > meets > > > its strict requirements. While these requirements are sometimes > difficult > > > to guarantee for hand-written JavaScript, it's still very relevant as a > > > compilation target for languages such as Java (via J2cl) or C++ (via > > > emscripten), which can enforce the compiler's requirements more > > > effectively. For users hand-writing JavaScript, we see TypeScript as a > > > better authoring language, even if Closure Compiler continues to be > used > > > for optimization. > > > > > > All this said, Closure Compiler and Library have a number of > intersection > > > points where they interdepend on one another. We are committed to > > retaining > > > the core functionality in Closure Compiler, while dropping its > dependency > > > on Closure Library. This includes Closure dependency management ( > > > goog.module, goog.require, etc), reflection (goog.reflect.object, > > > goog.reflect.objectProperty), defines (goog.define), and a few others. > > > > > > So even if we decide to eventually drop Closure Library, we can continue > to > > use Closure Compiler to create optimized release builds. > > > > It also appears that we can continue to use the goog.provide/goog.require > > module system with Closure Compiler. The parts of Closure Library that > > include the module system appear to have been migrated (or are in the > > process of being migrated) to Closure Compiler here: > > > > https://github.com/google/closure-compiler/tree/master/lib > > > > In the royale-asjs codebase, you can search for "import goog." to > discover > > which other parts of Closure Library that we currently use in Royale. > > Ideally, that usage should probably start trending downward. > > > > We use the goog.html package for HTML sanitation. I see that Google > > specifically recommends the following library as a replacement: > > > > https://github.com/google/safevalues > > > > Our biggest use is probably of the goog.events package. I think that we > can > > reduce some of it relatively easily (like the goog.events.EventType > > constants). Calls to goog.events.listen() may be easy to replace too. > > > > However, the trickiest part is our EventDispatcher class that extends > > goog.events.EventTarget. Extending goog.events.EventTarget instead of > > writing a custom implementation was probably mostly for convenience. If > we > > want to replace it with our own custom implementation, we'll definitely > > want a good set of automated tests to ensure no regressions. Starling > > Framework, an AS3 library with its own EventDispatcher implementation, > has > > a good set of tests that we might consider adopting, if we choose to > > migrate away from goog.events.EventTarget. > > > > Anyway, I just wanted to spread awareness of the state of Closure > Library, > > since we currently depend on it. It was officially deprecated in November > > 2023, and archived and made read-only in August 2024. > > > > -- > > Josh Tynjala > > Bowler Hat LLC <https://bowlerhat.dev> > > >
