You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by "ocs.cz" <oc...@ocs.cz> on 2016/02/12 12:20:35 UTC

dynamically attached object/added ivar

Hello there,

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).

Thanks for any advice,
OC



Re: dynamically attached object/added ivar

Posted by OC <oc...@ocs.cz>.
Jochen,

On 12. 2. 2016, at 20:37, Jochen Theodorou <bl...@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


Re: dynamically attached object/added ivar

Posted by Jochen Theodorou <bl...@gmx.org>.

On 12.02.2016 12:20, ocs.cz wrote:
> Hello there,

hi, long time no see ;)

> 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
def bar = foo

assert bar == tag
assert foo.x == bar

  BUT:

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. 
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.

bye Jochen

Re: dynamically attached object/added ivar

Posted by OC <oc...@ocs.cz>.
Aseem,

> Where have you seen such behavior before?

E.g., in Objective C; see its standard objc_setAssociatedObject API -- a pretty handy thing, this one.

> Expando may be something to look at.

Far as I understand the thing, hardly; but I am far from an expert and can be missing worlds. Could you perhaps outline how those two methods x_attach and x_attached would look like?

Thanks a big lot,
OC

> 
> On 12-Feb-2016 4:50 pm, "ocs.cz" <oc...@ocs.cz> wrote:
> Hello there,
> 
> 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).
> 
> Thanks for any advice,
> OC
> 
> 


Re: dynamically attached object/added ivar

Posted by Aseem Bansal <as...@gmail.com>.
Where have you seen such behavior before? Expando may be something to look
at.
On 12-Feb-2016 4:50 pm, "ocs.cz" <oc...@ocs.cz> wrote:

> Hello there,
>
> 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).
>
> Thanks for any advice,
> OC
>
>
>