Kenneth Lim

@davepagurek > How would we want a renderer to provide functionality specific to it? e.g. how WebGL has orbitControl() The `p5.Renderer` abstract class will define the basic drawing functions that...

Most of what I'm thinking of in terms of defining a renderer is done in the proof of concept `dev-2.0` branch. The renderer will be similar to [this](https://github.com/processing/p5.js/blob/dev-2.0/src/core/p5.Renderer2D.js) where it...

For truly private things I would prefer to use native private methods as you linked. It is pretty well supported so we may not even need to transpile it to...

I think it would be good to be able to generalize an implementation for push/pop as well but it may bring a lot of complexity into core that the 2D...

@davepagurek I think having a pattern where things can potentially be reused is not a bad plan. I'm not entirely sure about the design pattern of an object oriented mixin,...

In terms of instance states, it probably should be firewalled early, the mixin should be as pure as possible and the wrapper will be responsible for normalizing inputs to it....

Although thinking about this a bit more, another note is that for base class implementation, we probably should not have too complex stuff in there if the likely hood of...

`BaseRenderer3D` sounds like a very good idea here so essentially the renderer implementations will be a tree and additional renderers can possibly extend existing renderers to use their implementation instead...

@nickmcintyre Just want to note that I am thinking about pruning many of the things you listed as well (particularly those that thinly wrap JS functions and p5.Table). I wouldn't...

@GregStanton @ksen0 Is putting together something to collect community comments about p5.Table and other pruning related things above more generally and outside of GitHub to collect more diverse data. We...