New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename PVector, PImage, etc? #174
Comments
i think it is a good idea @evhan55
others could do:
|
I think a problem with |
I'm interested in the fallout from the plugin/settings/instance/PVector discussion, but I am ok with name clashes in the JS namespace. I think at some point in JS name clashes are the name of the game, and I prefer clarity for beginners. I'm interested in the ES6 discussion to help think about how PVector, PImage, PFont, etc, exist in the framework, too. |
we should only think about the instance mode. the global mode would anyway be clashing with dozens of other possible frameworks/libraries names... color, line, point, etc are all common words. in instance mode we only have one global variable, p5, so clashes are impossible. beginners would not use any other frameworks or libraries, i guess, and if they do, they would/should learn the instance mode. PVector can be supported and distributed as a standalone library, to be used without p5. actually the P, would make it easier to remember and to distinguish from others. (sorry for the long post!) |
I see the arguments. Something still doesn't sit right with me to think of a collection of standalone classes meant for use with p5 that have the For example, is there a game library out there, and what is their vector class like? Here is one that imports vectors from another external library called Box2D: In that case there is a whole physics engine library being used, not single classes, hmm. |
Hi all, I've been following this discussion closely but haven't weighed in as I'm still forming an opinion. I did look at a few other JS graphics libraries. two.js
three.js
paper.js
so paper.js is saying Point, two.js says Two.Vector, three.js says THREE.Vector, but both of those two are intended to be namespaced under two or THREE in all cases. this is just three examples of course... |
These are so great to look at! Thank you Lauren! |
Great references, look forward to hearing more of your thoughts! |
I was thinking the same thing about PVector being cleaner as just Vector. But there is one clash that is problematic if this is extended to all classes: "Image" is a native javascript class that might be sketchy to overwrite? I'm comfortable with the |
Ah, I can see |
Probably I'm totally out of scope but why the 5 in the name? You surely already thought and discussed about p.js or P.js but did not like it for some reason. I like these ideas to simplify names, and was thinking why using the 5 when we could further simplify the look of things like |
I'm not sure if you are asking why is the 5 there, or why should the 5 be kept. In the http://wiki.processing.org/w/FAQ it explains its origin:
|
@taseenb we chose p5 for a number of reasons, some main ones being a reference to earlier proce55ing and also it being unique enough in this domain to google. @shiffman so would it be var renderer = new THREE.WebGLRenderer();
renderer.setSize(window.innerWidth, window.innerHeight);
var scene = new THREE.scene();
var cube = new THREE.Mesh();
scene.add(cube); so assuming you're speaking global, it would look like var v;
var setup() {
createCanvas(200, 200);
v = new Vector(3,7);
} and for instance mode would it look like: var s = function(sketch) {
var g;
var v;
sketch.setup = function() {
g = sketch.createCanvas(200, 200);
v = new sketch.p5.Vector(3, 7);
};
sketch.draw = function() {
};
}; or were you thinking the p5.Vector() case was for instance mode and it would be just @brysonian this is a good point about |
@lmccart I like the way you have outlined possibilities for I didn't realize the |
Couldn't we always just leave it |
ah, ok this sounds better to me. it felt weird to have the |
Agree! I think it might be nice if it could be I should also point out that Processing PVector is many years old and a product of a different time and set of constraints. The use of so many static methods, for example, is not typically what you see in more current vector implementations. For example, in Processing we say:
Whereas if you look at other vector implementations you might typically see
Ooops, I think I am changing the subject too much and this should probably be its own thread. I guess the point I'm making is that if there were better ways to do vectors here in p5 we shouldn't feel tied to the PVector methodology. |
yes, like the new. so classes that would change: PVector >> p5.Vector()
PImage >> p5.Image()
PGraphics >> p5.Graphics() // not currently implemented
PFont >> p5.Font() // not currently implemented
PShape >> p5.Shape() // not currently implemented
PShader >> p5.Shader() // not currently implemented is this correct? currently, creating each of these differs. I think p5.Vector is the only one created with does this have @evhan55 approval? :) |
Related to I'm starting to feel that this is less an issue here and in fact |
I'm liking the namespacing of things under p5. Would this also hold for global mode? I think it could but want to make sure we would not be exporting these names to the global scope in that mode? (If we are exporting these to the global namespace in global mode, then I am extremely wary of overwriting an existing javascript built in like Image). +1 to using One specific comment on To one of @evhan55's earlier questions about whether to think about PImage as a plugin or not. I think PImage should stay in the core and not be a plugin. PImage and the main drawing surface (the PGraphics equivalent) could share a lot of functionality (seeing as they are both canvas backed drawing surfaces) and could at some point allow them to be interchangeable in terms of a rendering target, allowing drawing to PImages and filtering/etc on the main canvas (which I think could be kinda cool and provide easy offscreen drawing/compositing). |
What are your thoughts on PVector (or Vector) not being completely standalone anymore? Given your comment here: https://github.com/lmccart/p5.js/issues/163#issuecomment-39126282 |
@lmccart What would this all look like in global mode? |
It would be nice to unify all the object creation if that makes sense, so they are all |
@evhan55 I think the proposal is, in both global and instance mode creating a vector would look like are you suggesting removing I think @shiffman made the point that these were designed to shield the beginner from having to understand OOP from day one. it also looks a little weird to create an object without storing a pointer, in the case where you are creating a canvas and not calling it directly after that. function setup() {
new Canvas(600,400);
} |
I would want to argue for global mode to be truly global and to put the objects on the window. I don't see the point of having a global mode at all, then, if namespacing has to be used sometimes. For creation of these objects and factories, I don't feel as strongly as to which have convenience methods and which don't. But it'd be nice if there were a clean story re: objects that come with p5. What are the objects available? I can see it being confusing if there are two things:
The distinction there isn't very strong to me, and is confusing, and not a very clean design, I think. |
Re: Yes exactly, I agree that the confusion is possible, and I would want to revisit these functions/creators from the Processing API and make sure whatever we bring over is clean and consistent with whatever constructors we add on top. |
@evhan55 ok, I'd be alright with maybe Image needs to be something else then. I don't know what. |
ok, here is the proposal @evhan55 and I put forth: PElement >> Element()
PVector >> Vector()
PImage >> Image()
PGraphics >> Graphics() // not currently implemented
PFont >> Font() // not currently implemented
PShape >> Shape() // not currently implemented
PShader >> Shader() // not currently implemented we will keep the constructors for these as are, in both global and instance. typically, create is used to create an empty version of something, load is used to create something from a file: var img;
function setup() {
createCanvas(100, 100);
img = loadImage("cat.jpg");
} var s = function(sketch) {
var img;
sketch.setup = function() {
sketch.createCanvas(200, 200);
img = sketch.loadImage("cat.jpg");
};
};
var myp5 = new p5(s); now for vector, there are two options. option 1: vector is treated as a special plugin. functionally, it works the same, this is mostly a philosophical distinction, with small syntax and organizational effects. our thinking is, while image, element, etc seem pretty crucial to the core experience, vector is a data type. why is it the only data type, should there be more, where do we stop adding to the core? if we treat this as a plugin, it's distinguishes it as slightly separate, and leaves room for more data type classes like this. by special we mean, rather than this being hosted and maintained separately, Vector would be documented and ship with the core p5 library, and have unit tests included, too. however, rather than going in initialization would remain the same: var v;
function setup() {
createCanvas(100, 100);
v = new Vector(0, 0);
} var s = function(sketch) {
var v;
sketch.setup = function() {
sketch.createCanvas(200, 200);
v = new sketch.Vector(0, 0);
};
};
var myp5 = new p5(s); option 2: vector is part of core. functionally, it works the same, but placed in @shiffman we are curious what you think regarding the options. essentially, it comes down to making a conceptual decision rather than a lot of change code-wise. |
|
Just to clarify, with the non I think I prefer |
@shiffman I believe, as a plugin attached to the instance, it should have access, but that is a hunch. If you prefer the plugin route, we will try it! |
Great, one note I'll make is that I definitely prefer |
hi @shiffman concerning the instance reference within PVector (or Vector), you'll need to pass it as an argument if you use just a comment. since John Resig is interested in p5, i feel right if i take inspiration from his experience (jquery has a lot of success with beginners and people learning how to program). jquery uses many aliases and different syntax options to do the same thing: i don't know if this is a good practice in general, but that works very well and allows an expressive use of that library and javascript. with time, people discover that those syntax variations can have a meaning and sometimes be used to achieve different things. syntax flexibility allows jquery to adapt to the user's style or to a particular situation, more than the opposite. a classic of the jquery syntax:
you can probably have more than one way to create a vector, like:
|
Just to clarify, in one comment you said: And in another comment you said: Is there a typo or did I misread either comment? |
I think he's just saying the preference is to have |
The proposal is for p5 to have some core classes like Image, Shader, etc. Then, p5 will also have plugins that are added onto p5 and only accessed via ' If plugins want to support their own convenience methods, that is out of our design and totally possible. Flexibility is good, yes! For the core p5 we want to start with a clean API first, and think about overloading a bit after things have solidified, for the sake of clarity and beginners. What does @lmccart think? |
Oh, I see! |
@evhan55 yes! |
@evhan55 sure, sorry if i created confusion! but it seemed to me that the problem was also how to get the instance, or that's already solved? with |
This is, interestingly, exactly the same approach as Processing. For example, core classes are created with
Libraries (similar I think to the "plug-in" idea) are done with
PVector is the one exception since it doesn't really need access to the PApplet instance:
It sounds like the most recent p5 proposal is the same. The one difference is that with p5, due to angleMode,
. . . ? Or would it be:
unless the user decided that angleMode mattered and therefore says. . .
. . ? Am I understanding all the scenarios correctly? |
@shiffman I think we would like it to be
but it seems like because it needs access it would need to be a variation like
for including a library like Capture for example, it makes sense to me to include the |
I agree. I think the alternative (which I am also ok with) is just to say that Vector doesn't know about angleMode and it's your job to call We could also allow either, but if you make a vector this way |
ok, so sounds like there are three options:
my vote would be for option 1. @evhan55 and I discussed last week and felt @shiffman you use vector more than us so we would defer to whichever preference you had, sounds from above like you are voting for option 1 as well, but let us know if you'd prefer to go with 3 and have it be radians only. |
I think Option 1 makes the most sense! I am not sure if this is a terrible idea or not, but I might allow all three but have all the examples and documentation use 1. In other words, vectors will work without a reference to a p5 sketch instance and just default to radians. and |
ok, I have implemented options 1 and 3, but not 2, because calling var @shiffman I started to take a stab at modifying pvector to account for angleMode if it has a pointer to the p5 instance, but I started feeling shaky about which way things get converted. I tried one here: I can keep going with this, or if you'd prefer to do it, you could follow the pattern in the example I did (first check for reference to p5 instance with |
Looks like what you did is right and I'm happy to take a crack at finishing it up. Will submit a pull request soon! |
closed with commit 998d20e |
@shiffman @lmccart
I am very excited about thinking of
PVector
as a pseudo-plugin for p5, given that it is a completely independent object type.A potentially divisive question, but just wanted to throw it out there:
I would be happier calling them
Vector
andImage
rather thanPVector
andPImage
, is it possible/acceptable to think about a Processing compatibility layer that knows to acceptPVector
etc. for people who are coming from Processing, but that is not what is taught "out of the box" with `p5'?PVector
andPImage
feel heavy and confusing (the P is capitalized but not in p5, so the link isn't very strong there for me).Vector
andImage
feel better to me.And do we want to think about
PVector
/Vector
andPImage
/Image
as plugins, or no?Currently, they are not being included in a very clean way, and I think it's worth thinking about as we continue.
The text was updated successfully, but these errors were encountered: