If we ever get access to GC primitives, I would like to make sure that it is minimally specified. An example of this is that in the JVM standard, `java.lang.System.gc()`'s behavior is completely implementation-defined. Matter of fact, IIRC the standard explicitly mentions that doing nothing is conforming.
On Fri, May 13, 2016, 14:18 /#!/JoePea <[email protected]> wrote: > > my stuff, you'll see it's pretty free from GC, but that's because I pull > a lot of tricks, which make for messy and hard to understand code. > > Exactly, which is why standards around GC might help; to prevent the > messy brittle code that developers making graphically intense apps > will end up writing. I've no idea what/how standards on GC would be > like, but it just seems like they're needed. Some standardized GC > would work automatically like now, but would also let devs take > control when needed (without "tricks"). > > On Fri, May 13, 2016 at 11:05 AM, Brian Barnes <[email protected]> wrote: > > It much easier to solve then that, just make a,b,c globals in the class > > constructor (again, let's consider than objects, not primitives.) If you > > look at my stuff, you'll see it's pretty free from GC, but that's > because I > > pull a lot of tricks, which make for messy and hard to understand code. > > > > The point is to find a way to do this without convoluted stuff that ends > up > > making brittle or spaghetti code -- and is subject to sudden changes if > > someday an engine decides to do GC in a different way, being clever could > > suddenly turn against you. > > > > [>] Brian > > > > On 5/13/2016 1:45 PM, Isiah Meadows wrote: > >> > >> I think the original problem that caused this discussion with GC could > >> be solved with just a weak map: > >> > >> ``` > >> // Original > >> class thing { > >> doSomething(x, y) { > >> let a = x + y; > >> let b = ay; > >> let c = bx; > >> return (c); > >> } > >> } > >> > >> // With a weak map > >> const wm = new WeakMap() > >> > >> class thing { > >> doSomething(x, y) { > >> let data = wm.get(this) > >> if (data === undefined) { > >> wm.set(this, data = { > >> a: x + y, > >> b: ay, > >> c: bx, > >> }) > >> } > >> return data.c; > >> } > >> } > >> ``` > >> > >> > >> On Fri, May 13, 2016, 13:14 Brian Barnes <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >>> On May 13, 2016, at 12:13 PM, /#!/JoePea <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > >>> > Or "Cython in Javascript". I think your needs can be satisfied by > >>> C/C++ addons in Node.js or WebAssembly in browser > >>> > >>> But we want to stay in JavaScript because we like the language. > >>> Plus, writing a framework in JavaScript has the obvious advantage > >>> that a beginner web programmer can just start using it > >>> easily (HTML/JAvaScript is like the gateway drug of programming > >>> nowadays so there's certain advantages to writing a library in JS > >>> as opposed to in C or compiling to WebAssembly). > >> > >> > >> I don’t think there being an alternate is any reason to not improve > >> something. I’m realistic here, I know there are concerns which are > >> 1,000,000x more important than me, games or other time sensitive > >> applications, and backwards compatibility and language complications > >> and sometimes philosophy. Just a few things here and there, though, > >> not necessarily any of the ideas I’ve come up with, can solve or > >> mitigate this problem. > >> > >> I never thought I’d see modules or classes! Everything is on the > >> right path. Just being able to deal with the GC (and maybe types if > >> I’m lucky) is the only big hurdle to the kind of thing myself and > >> others are doing. > >> > >> [>] Brian > >> _______________________________________________ > >> es-discuss mailing list > >> [email protected] <mailto:[email protected]> > >> https://mail.mozilla.org/listinfo/es-discuss > >> > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
