"Super" hoisting

/#!/JoePea joe at trusktr.io
Fri May 13 18:17:50 UTC 2016


> 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
>>
>


More information about the es-discuss mailing list