undefined | Better HN

0 pointsloup-vaillant8y ago0 comments

Most VR games make sense with 2 displays (Headset + screen), and 2 sound systems (binaural for the headset + stereo for the audience). You'd likely know that from the outset, though.

0 comments

jstimpfle8y ago

Yes - and for each of these examples, there would likely be still a single "object instance" managing these devices (e.g. "Display" module). Or two entirely different modules ("Headset" module + "Screen" module), again each having only a single "instance".

The concept of instancing is inappropriate to most situations. The things that we have more than one ("dynamically many") instances from are typically dead data, but then again these are typically managed in a single pool. (That's "tables", again).

loup-vaillantOP8y ago

> The concept of instancing is inappropriate to most situations.

At the application level, maybe. At the library level, this can easily kill reuse. See Lex/Yacc. They used to assume a program would only have one parser. Then some naive developer tried to parse both JSON and Lua tables in the same program. Oops.

Another example: standard libraries (including home grown ones). They instantiate everywhere: arrays, hash tables, file descriptors…

jstimpfle8y ago

Sure, there are exceptions. The other side goes the same way: If it's not a static resource, don't make it a global...

> arrays, hash tables, file descriptors

Most arrays / hashtables in my own use are actually static resources as well...

File descriptors, same thing. They are (or correspond to) a process-wide resource managed by the OS. Most maintainable way is to manage them in a global pool.

1 more reply

j / k navigate · click thread line to collapse

0 comments

jstimpfle8y ago

loup-vaillantOP8y ago

> The concept of instancing is inappropriate to most situations.

Another example: standard libraries (including home grown ones). They instantiate everywhere: arrays, hash tables, file descriptors…

jstimpfle8y ago

Sure, there are exceptions. The other side goes the same way: If it's not a static resource, don't make it a global...

> arrays, hash tables, file descriptors

Most arrays / hashtables in my own use are actually static resources as well...

File descriptors, same thing. They are (or correspond to) a process-wide resource managed by the OS. Most maintainable way is to manage them in a global pool.

1 more reply

j / k navigate · click thread line to collapse