FAQ

On Tuesday, March 5, 2013 5:21:29 PM UTC-6, Jens Alfke wrote:

On Mar 5, 2013, at 3:13 PM, Steve McCoy <mcc...@gmail.com <javascript:>>
wrote:

Anyhow, I don't care if Go ever gets them, but there are other fun things
that can be done with weak references that don't have anything to do with
caches.


They’re also useful for uniquing objects, of which Java’s String.intern is
a simple example. Unique objects have nice characteristics, such as being
able to compare them using pointer equality, and avoiding any need for
coordinating state changes among multiple objects representing the same
thing. (For example, I like this pattern for objects representing database
rows/records.)
Test on pointer equality are exactly why I don't like weak refs
What if it gets collected and something of the exact same type gets
allocated exactly where it used to live?
To detect that you would need two kinds of references defined for each
object of that type, a pointer and some unique key.

These objects are generally managed with a central map that will return an
existing object or generate a new one if it doesn’t exist yet. Without weak
references, this map grows monotonically as no uniqued object will ever get
collected. (Unless you resort to workaround like a retain/release API, i.e.
building ref-counting on top of a GC system, which seems perverse.)
I use a map[X] structs this way now, but with a TTL value in the struct for
forgetting and eventual normal gc collection.
Probably not the best if you get a large number of entries in the map but I
don't so it works for me.
Not that you couldn't use some other data structures to back this style.

—Jens
>

For real small memory embedded systems you usually preallocate everything
since you operate in somewhat controlled way and the system doesn't have
enough resources to really multitask anyways.
For modern smartphone-esque systems I would just treat them like a desktop
PC from the early 2000s which fits the current go model.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2021 Grokbase