Re: [Glsdk-devel] Geometry generation

[H. H. <hen...@gm...>]

Fine. You have made good points there and I listen to them. I have brought
up my view which you counter argumented with other points. We both have
brought up points from different angles and this is a good thing. My
intentions are not to be counter-productive.

I think we should let the author of the library to have the final word on
this.

On Sun, Aug 24, 2008 at 5:31 AM, Jason McKesson <ko...@gm...> wrote:

>  Henri Häkkinen wrote:
>
>
>
> On Sun, Aug 24, 2008 at 4:25 AM, Jason McKesson <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.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
>


-- 
Henri 'henux' Häkkinen