"Super" hoisting

Isiah Meadows isiahmeadows at gmail.com
Sat May 14 00:30:55 UTC 2016


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 <joe at trusktr.io> 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 <ggadwa at charter.net> 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 <ggadwa at charter.net
> >> <mailto:ggadwa at charter.net>> wrote:
> >>
> >>>     On May 13, 2016, at 12:13 PM, /#!/JoePea <joe at trusktr.io
> >>>     <mailto:joe at trusktr.io>> 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
> >>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> >>     https://mail.mozilla.org/listinfo/es-discuss
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160514/bf4bc355/attachment.html>


More information about the es-discuss mailing list