groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OC <...@ocs.cz>
Subject Re: dynamically attached object/added ivar
Date Fri, 12 Feb 2016 20:26:24 GMT
Jochen,

On 12. 2. 2016, at 20:37, Jochen Theodorou <blackdrag@gmx.org> wrote:

> hi, long time no see ;)

No complaints for a log time :D

>> have we in Groovy an API which would serve as a reliable replacement of “dynamically
attached objects” or “dynamically added ivars” of other APIs? I mean a way to reasonably
implement something like "x_attach" and "x_attached" here:
>> 
>> def foo=... // any object of any class, typically some Map, but not necessarily
>> def tag=... // any object of any class, possibly even a class itself
>> 
>> foo.x_attach(tag)
>> def bar=foo // just to emphasize the attachment is object's, not variable's property
>> 
>> ... throughout the code, "foo" and "bar" can be used normally, all APIs and libraries
etc. work with it the very same way they would without "x_attach" ...
>> 
>> assert bar.x_attached().is(tag) // but later, I can get the attached object
>> 
>> When the object foo/bar gets garbage-collected, it's attachment loses an active link
and (presumed it is not referenced from another place) gets garbage-collected too. Due to
this demand, it is rather inconvenient to simulate the attachments by a static map indexed
e.g., by System.identityHashCode(foo), for -- far as I know at least -- there is no convenient
API to determine when a generic object (whose finalize I cannot override) goes poof (and thus
its attachment should be removed from the map).
> 
> what you can do easily in Groovy is something like
> 
> def foo = [:]
> def tag = something here
> foo.x = tag

Alas, this does not help, two reasons:

(a) foo is _typically_ a Map, but _not necessarily_
(b) foo/bar cannot be used normally in subsequent code, for

foo.each { k, v -> ... }

would crash/yield wrong results due to the [x, tag] entry being listed by a code which is
not written to cope with that (and ignore it appropriately).

> tag = something else
> assert bar != tag
> assert foo.x == tag // fails now
> 
> From what I understand you want the last condition to be true as well.

Uh, I am afraid I did not explain well :/

There's absolutely no problem with the last condition, it's quite all right. The problem with
this approach is that the map itself would behave differently (by containing a different set
of objects) when x_attached anything.

> If yes, then it gets difficult, if no, well then foo can be any Map or Expando, the usage
in the case of Expando is just like above, only the init is different of course. And of course
this is still without the memory requirement. Though you could use a map which uses WeakReference
for the values. Apache Commons ReferenceMap comes here to my mind though.

Hmmm, those weak refs might actually help -- thanks a big lot for pointing that out! Coming
from ObjC background, I tend to forget those (actually today's ObjC supports the thing, but
its comparatively new feature in there).

All the best,
OC


Mime
View raw message