From: Jason M. <ko...@gm...> - 2008-08-24 02:30:53
|
Henri Häkkinen wrote: > > > On Sun, Aug 24, 2008 at 4:25 AM, Jason McKesson <ko...@gm... > <mailto:ko...@gm...>> wrote: > > Henri Häkkinen wrote: >> There are good ideas, but how about this: >> >> The GLSshape is not opaque pointer, but a public structure like this: >> >> typedef struct GLSshape_s { >> GLuint vertex_buffer; >> GLuint vertex_arrays; >> // etc. >> } GLSshape; >> >> In this way, the caller could setup the structure himself and >> pass it on DrawShape. > If a user needs to create one of those structs in order to render > with buffer objects and vertex array objects that he has already > created, then our tutorials will have failed miserably. We are > talking about an object that is basically a wrapper around a > vertex array object, after all. It's a "bind" and "glDrawElements" > call away from being drawn. The hard work is in the creation of > the various buffers, VAO bindings, and so forth. > > > Again; I clearly did not say that a user must or need to setup struct > on his own, but pointed out the possibility and the benefits of it. Yes, and we have argued that the benefits do not outweigh the costs. I'm not sure what you're getting at here. > >> >> Or if we decide to handle GLSshape as opaque, we could also >> declare it like this: >> >> typedef struct GLShape_s *GLSshape; >> >> In this way we can get minimal type checking if the user tries to >> push something weird. >> >> Also, I like Branan's idea of multiple entry-points. I would >> prefer their names to be shorter (glsCreateSphere instead of >> glsCreateShapeSphere). > I can see a need for multiple entrypoints, but the longer names > should stay. > > The convention should be: > > gls - Create (because it is creating an object) - Shape (the > object being created) - etc (for the various different ways of > creating a shape). > > It would be weird to call glsDestroy/Shape/ on something returned > by glsCreate/Sphere/. > > > IMO, it would not be that weird; glsCreateShape return GLSshape > object. Shorter names are more convenient, IMO. The purpose for having a naming convention is to create a consistency of naming among all named things. If that means a name gets "too long," so be it; having inconsistent naming is far worse in the long run than having to type 5 more characters. I've used many APIs that have inconsistent naming (hello, Win32), and it's /never/ a good thing, no matter what the original reason for it was. > Either way, I am just trying to be constructive by giving ideas which > you seem to smash first-handedly just because of your own personal > conventions of doing things. Just because your ideas are being shot down, or even argued against, does not make the criticism non-constructive. This is going to be a long project. People are going to have opinions and disagree. People are going to argue for their points of view, and they're going to make arguments against other people's points of view. Attacking someone for doing so is not conducive to a productive atmosphere. |