On 3/13/16 5:30 PM, Brian Barnes wrote:
“Perfect is the enemy of the good.”
This is true, but...
I’m asking for a specific, useful function, not the perfect solution to my
problem.
The problem is that the function you're asking for can be really really
bad in some situations. So if we introduce it without actually defining
its behavior we run the very real risk of people using it in ways that
work in some current browsers and thus constraining the future
development of those browsers _and_ breaking other current browsers.
Note that I'm quite interested in helping solve the actual problem
you're having. I just don't think this is the right solution for it.
Some of the suggestions Steve Fink made are much better, in my opinion.
The problems start when the best practice is different for different engines
and people optimize their code based on only one engine.
That’s not our problem
It's _my_ problem as an engine developer.
and that’s not a solvable problem.
It's not a solvable problem in the abstract, sure. But it's a problem
that we can make worse or better (e.g. by not explicitly introducing
APIs that make the problem worse, or by introducing ones that make it
smaller).
Now _I_ will claim that the perfect is the enemy of the good. ;)
Every engine will try to get ahead by some manner, and something like
compiling, or GC, which isn’t spec nor should it be, will always be evolving.
Yes! And we don't want to prevent that.
A System.gc() will in no way constrain further development.
I disagree most vehemently.
It’s not a guarantee to do anything but “free up objects that are no longer
reachable and compact the heap.”
Except _you_ want to use it as a guarantee of "no more GC pauses after
this point". That's the use case it's being proposed for!
The contract is not “make my code run faster.” It’s not “don’t do it again in
a little bit.” It’s not any of those things.
People will 100% surely assume that's the contract. Especially if it
happens to be true in one particular case they use it in, in the one
browser they test in.
And then they will create things that depend on that behavior, and it
will in fact become a de-facto contract. I've seen this play out
several times now.
I think you’re trying to force the API to be a problem solver
No, I think the right approach for API design is to figure out what
problems you're trying to solve and then create APIs that ideally solve
those and don't introduce new problems.
This is as opposed to coming up with an API and then trying to argue
that it solves some specific problems therefore is the right API to
have. There may be better solutions for those problems!
Small contract: Free up objects that are no longer reachable and compact the
heap, the objects being objects that aren’t attached by outside APIs (DOM,
webgl, web audio, etc.)”
That's not a useful contact, because no one actually cares in practice
about whether this has happened or not. The real use cases mentioned so
far are all about GC pauses, not internal details like whether things
have been freed up or whatnot (which aren't even observable!).
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
