My memory was Mootools itself depended on bind, so it was significantly
more that broke, thus my conclusion. Someone (probably me!) should check
what it was that actually broke, exactly. :)
Many things in MooTools Core depends on itself.
I agree there are use cases for distinguishing method invocations from
property accesses (remote method calls are one of them -- you'd want to
distinguish between doing an HTTP GET vs POST). But the new API hasn't
changed the balance for or against an invoke trap. Recall that one of the
I'm not sure I understand the benefit of making it easy to develop APIs where
foo.bar() is not roughly equivalent to (x = foo.bar).apply(foo). Am I
misunderstanding something?
Right. Keeping that invariant is important.
I’d like to avoid (the cognitive and performance cost of) having to
Le 25/10/2012 12:42, Axel Rauschmayer a écrit :
I'm not sure I understand the benefit of making it easy to develop
APIs where foo.bar() is not roughly equivalent to (x =
foo.bar).apply(foo). Am I misunderstanding something?
Right. Keeping that invariant is important.
I’d like to avoid (the
Sorry, slightly off-topic: Does Firefox already have @iter.items (etc.)? Or is
there something similar one could use to iterate over [key, value] pairs for
objects, via for-of?
Thanks!
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog:
On Thu, Oct 25, 2012 at 1:24 PM, Axel Rauschmayer a...@rauschma.de wrote:
Sorry, slightly off-topic: Does Firefox already have @iter.items (etc.)? Or
is there something similar one could use to iterate over [key, value] pairs
for objects, via for-of?
You can use Iterator, e.g.:
for ([key,
On Thu, Oct 25, 2012 at 6:24 AM, Axel Rauschmayer a...@rauschma.de wrote:
Sorry, slightly off-topic: Does Firefox already have @iter.items (etc.)? Or
is there something similar one could use to iterate over [key, value] pairs
for objects, via for-of?
Unfortunately Iterator does do that, but I
On Thu, Oct 25, 2012 at 11:50 AM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Thu, Oct 25, 2012 at 6:24 AM, Axel Rauschmayer a...@rauschma.de wrote:
Sorry, slightly off-topic: Does Firefox already have @iter.items (etc.)? Or
is there something similar one could use to iterate over [key,
this
(x = sink.bar).apply(sink)
to me is like using apply to undefined ... that is not the equivalent of an
invoke where the context should be explicit ( e.g. obj.method() ) so is
not, in my opinion, a good __noSuchMethod__ case.
sink.bar is a getter , if not there, is undefined (unless chained
It'd be really nice if JS had a way to explicitly delete an object.
Occasionally, in complex programs, you can find yourself with a
situation where a certain type of object is leaking. However, even if
you track down what the object is, and find the exact point in your
program where you ought to
how about
`someObject = null;`
rather than delete someObject;
?
free'ing' an object is like dealing with GC ... I think you would rather
stay away from it and track references, and free them, as much as you can :)
On Thu, Oct 25, 2012 at 4:16 PM, Isaac Schlueter i...@izs.me wrote:
It'd be
On Thu, Oct 25, 2012 at 4:16 PM, Isaac Schlueter i...@izs.me wrote:
It'd be really nice if JS had a way to explicitly delete an object.
I guess you mean ... a way to set all the refs to a object to undefined.
What do you folks think about a free operator (or something like it)
that would
I sort of have a fundamental problem with the solution. Eg: If it were
actually unused, it'd be GC'd. Since it isn't GC'd, something must be holding
a reference to it. So if you force it to be gone, or clear all the properties,
or whatever, seems to me that then you'd just start throwing
On Fri, Oct 26, 2012 at 1:35 AM, Shawn Steele
shawn.ste...@microsoft.com wrote:
I sort of have a fundamental problem with the solution. Eg: If it were
actually unused, it'd be GC'd. Since it isn't GC'd, something must be
holding a reference to it. So if you force it to be gone, or clear
On Thu, Oct 25, 2012 at 7:16 PM, Isaac Schlueter i...@izs.me wrote:
It'd be really nice if JS had a way to explicitly delete an object.
Occasionally, in complex programs, you can find yourself with a
situation where a certain type of object is leaking. However, even if
you track down what
I do think that including this as a debugging tool is where the most value is.
Whether through an engine-provided API (like V8's gc()/--expose-gc) or through
something more standardized, like the existing `debugger` statement, is the
real question.
On Oct 25, 2012, at 21:04, Alex Russell
On Thu, Oct 25, 2012 at 9:04 PM, Alex Russell slightly...@google.comwrote:
This use-case is usually what weak refs get pressed into service for. But
I think that answering your question, why is my RSS continually
increasing? is something for a tool (debugger, profiler, etc.) to help
answer.
if you are holding it already plus you don't know what happens after that
assertFree(obj) call I am not sure about the value of this assertion.
On Thu, Oct 25, 2012 at 6:04 PM, Alex Russell slightly...@google.comwrote:
This use-case is usually what weak refs get pressed into service for. But
I
On the contrary, TypeError: Cannot read property 'prop' of undefined, with
a stack trace, is WAY easier to track down than The RSS on my server
gradually rises, until the operating system kills it, which happens about
every 4 hours.
I'm not so sure. Now you know where you're using it that
On Thu, Oct 25, 2012 at 10:14 PM, Shawn Steele
shawn.ste...@microsoft.com wrote:
On the contrary, TypeError: Cannot read property 'prop' of undefined, with
a stack trace, is WAY easier to track down than The RSS on my server
gradually rises, until the operating system kills it, which happens
On Oct 25, 2012, at 23:13, Andrew Paprocki and...@ishiboo.com wrote:
On Thu, Oct 25, 2012 at 10:14 PM, Shawn Steele
shawn.ste...@microsoft.com wrote:
On the contrary, TypeError: Cannot read property 'prop' of undefined,
with a stack trace, is WAY easier to track down than The RSS on my
On Oct 25, 2012 8:42 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
The new thing this proposal brings to the table is the ability to mark,
from within your code, exactly what object you're worried about the
leakiness of. You also get very understandable error messages for
determining
Any proposal that destroys this invariant:
function() {
var x = obj();
// other statements not involving x
x // still defined
}
destroys local reasoning and would almost certainly do more harm than good.
In programs with leaks, the leak is often inside of library code, and
breaking the
On Oct 25, 2012, at 9:38 PM, Yehuda Katz wyc...@gmail.com wrote:
Any proposal that destroys this invariant:
function() {
var x = obj();
// other statements not involving x
x // still defined
}
destroys local reasoning and would almost certainly do more harm than good.
Agreed. This
24 matches
Mail list logo
