On Sun, Sep 27, 2015 at 9:57 AM, Filip Pizlo wrote:
> Hi Mark,
>
> It seems that most of the benefit for fail-faster behavior for VM errors
> is security.
>
> To what extent do you think the security problem could be addressed by VMs
> simply randomizing the point at which
A naive question: don't you get working weakref by using a WeakMap and
getting and setting using the same key? A naive point of view suggests
that. What am I not seeing here?
Herby
Isiah Meadows wrote:
I'm resurrecting this [1] because I have found a use case where I needed
a weak reference.
Hi Mark,
It seems that most of the benefit for fail-faster behavior for VM errors is
security.
To what extent do you think the security problem could be addressed by VMs
simply randomizing the point at which stack overflow or OOM happens? I think
this would be more desirable, since it
[-whatwg, +es-discuss]
Reposting to es-discuss, as Anne's more general question is best seen as a
JS issue rather than a browser specific one
On Sun, Sep 27, 2015 at 8:30 AM, Mark S. Miller wrote:
> On Sat, Sep 26, 2015 at 7:34 AM, Anne van Kesteren
>
`WeakMap` holds the *key* weakly, not the value - it holds the value
strongly. If you have the key such that you can use it to get at the value,
you'll always have the value.
`WeakRef` is a container around a weakly held *value*, which I don't
believe is possible to fully polyfill, even with
On Thu, Sep 24, 2015 at 8:14 AM, Mark S. Miller wrote:
> I like #4. Normally in a situation like this I would still argue for #1.
> #4 is a complicated special case that breaks the normal pattern of operator
> precedence elsewhere in the language. The need for ** is not great
Android has an older onLowMemory() callback and a newer onTrimMemory()
callback:
-
http://developer.android.com/reference/android/content/ComponentCallbacks.html#onLowMemory
()
-
http://developer.android.com/reference/android/content/ComponentCallbacks2.html#onTrimMemory(int
)
iOS has something
7 matches
Mail list logo