ObjectMap has a forceEnumerable option in the constructor, so it can automatically switch from WeakMap to Map if necessary (i.e. to use ObjectMap.forEach).
On 11/13/2021 7:37 PM, Greg Dove wrote: > Fair enough. :) I prefer to do something different, but I take your point. > > IMO WeakMap is not that useful in js (which also applies to > ObjectMap), compared to how a Dictionary with weak keys was useful > in flash. It still has some usefulness, but not to the same degree, because > if there is any iteration over keys ( often the case with Dictionary > instances in legacy code) then WeakMap is not an option, so a lot of the > time it has been necessary to use Map with strong keys even in the case of > weak keys in the original Dictionary code. > When I am porting, I try to keep as much of the original code as possible > the same. Dictionary is an example of one minor pain point where things do > need to change in all the usage sites (unless it is a string-keys only, and > you switch it to use a plain object, something which would have been > equally possible in the original flash/flex code). I do hope to avoid the > need to change the code in future support (the compiler will expand the [] > access to get/set calls and delete operator to delete call), and also to > get iteration over weak keys working, but it will very likely be slower > than ObjectMap or using native Map. > > > > > > > On Sun, Nov 14, 2021 at 1:52 PM Edward Stangler > wrote: > >> ObjectMap hides the whole WeakMap vs. Map vs. Object / any stuff, so it >> just seems convenient, while still trying to be performant and reducing >> strong references. >> >> Worked well for XMLNotifier. >> >> >> >> On 11/13/2021 6:12 PM, Greg Dove wrote: >>> Using ObjectMap could be an option if you want both SWF and JS code to >> run, >>> but is not really warranted IMO if the main goal is to migrate away from >>> SWF, because the api is the same as Map, and is indirect use of the Map >> - >>> so why add the extra overhead? Also if you can avoid switching the >> original >>> code to the new api in some cases, when all that is needed (for string >>> keys) is an object hash, so that's why I think that's a bit easier. After >>> porting 8 or 9 codebases now, this is simply the approach I have settled >> on >>> in these cases. >>> >>> What I hope to do is get something similar to work, but for it to use the >>> original dynamic access that works for flash.utils.Dictionary for both >>> targets instead of switching both implementations to use the approach >> that >>> Map uses (get/set/delete methods). That's not possible simply using >>> javascript Proxy, but it will be possible using some compiler smarts and >>> internal use of WeakRef in js implementation in the case of weak keys. >>> Something for later... >>> >>> >>> >>> >>> >>> On Sun, Nov 14, 2021 at 12:57 PM Edward Stangler >>> wrote: >>> >>>> Why not use org.apache.royale.utils.ObjectMap? >>>> >>>> >>>> >>>> On 11/13/2021 3:24 PM, Greg Dove wrote: >>>>> Sure, if you want, Andrew. This is the way I do it currently, and in >> some >>>>> cases this has been done within the current framework code (e.g. in >> Crux >>>>> code there is some use of Map to replace Dictionary in js, iirc) >>>>> >>>>> I do expect to come up with an approach that works much closer to the >>>>> original flash Dictionary using a combination of compiler support, >>>> similar >>>>> to thej [RoyaleArrayLike] support and framework code (which would use >> the >>>>> relatively recent WeakRef support in js). >>>>> I also believe it will be possible to match flash event listener apis >>>> with >>>>> support for weak listeners (also using WeakRef - and I would add event >>>>> priority support at the same time). >>>>> But both of these updates would be opt-in and would only be for quite >>>>> modern browsers, but would allow for more unchanged code when porting >>>>> legacy apps. At the moment these are just ideas/vague plans, I need to >>>> find >>>>> the time for that. >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Nov 14, 2021 at 10:07 AM Andrew Wetmore wrote: >>>>> >>>>>> Greg, can I throw that into documentation as a workaround? >>>>>> >>>>>> On Sat., Nov. 13, 2021, 4:45 p.m. Greg Dove, wrote: >>>>>> >>>>>>> Hi Hugo, >>>>>>> >>>>>>> I might change this in the near future. But for now, here is the >>>> general >>>>>>> 'rule of thumb' that I use: >>>>>>> >>>>>>> If the instance only has string keys (or int/uint/Number/Boolean keys >>>>>>> should be ok too) then use a plain Object. All code can pretty much >>>> then >>>>>>> remain unchanged. >>>>>>> >>>>>>> If it is using object instances (any complex object like functions or >>>>>> class >>>>>>> instances, or generic object instances) as keys, then >>>>>>> >>>>>>> a) use native js Map if the original constructor argument does not >> have >>>>>>> weakKeys=true, or if it has weakKeys= true and there is any form of >>>>>>> iteration over keys (you cannot iterate over keys in a WeakMap in >>>>>>> javascript) >>>>>>> >>>>>>> b) otherwise use WeakMap. >>>>>>> >>>>>>> Both (a) and (b) require you to change code for get/set ([] >>>>>>> access/assignment in as3) or delete operator, and also code related >> to >>>>>>> iteration (use map.forEach in js). >>>>>>> see docs for those: >>>>>>> >>>>>>> >> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map >> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap >>>>>>> >>>>>>> On Sun, Nov 14, 2021 at 9:34 AM Hugo Ferreira < >> hferreira...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I see that there is no Dictionary on Royale, probably because there >> is >>>>>> a >>>>>>>> better method. >>>>>>>> What the approach in Royale for a Dictionary ? >>>>>>>> >>
