Clunky API
Clunky API
- Subject: Clunky API
- From: Rob Rix <email@hidden>
- Date: Thu, 20 Sep 2001 08:42:15 -0400
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings,
In a framework I've been developing, I have a vector class. This class is
used for a variety of things throughout the framework, one of them being
OpenGL.
My vector class has the normal cartesian accessor methods: -x, -setX:, et
cetera. Problem is, using these feels sort of clunky, for a couple of
reasons:
1) when using OpenGL's glVertex3d (I may change to floats, it depends on
my final requirements), I have to use [vector x], [vector y], [vector z].
Typing that out is a bit of a pain. To rectify this, I've been considering
writing a wrapper function which takes a vector and just calling it
instead.
2) for one call of glVertex3D, three message calls are sent. There are a
couple of instances where I can cache these values to improve performance,
but not many.
Now, I'm not writing this for use in games or anything, so I don't need
ultra-super-duper-mega-performance or anything like that. But three
message calls for every drawn vertex, when there are potentially quite a
large number of vertices drawn, is quite a lot.
So, what I'm wondering is the following:
1) can anybody think of a more elegant solution to this than the standard
messaging? I've been considering reducing my vector class to a struct and
a bunch of functions, but this is _not_ a very nice solution for me, as it
removes all the object-oriented gains I get, and reduces its ability to
integrate with the rest of my framework.
2) would this be considered an acceptable case to use the @public
directive so that you could use vector.x, et cetera, and avoid both the
messaging and a wee bit of the clunkiness? It's not elegant, certainly,
but would it be generally considered apropos?
Thanks for any help in my conundrum,
- -- Rob
Random and unpredictable are not the same thing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see
http://www.gnupg.org
iD8DBQE7qeQqnZTWcucI1tgRAuqIAJ0dYSZqgnmaDLQ6Ab27/q0wtNbo6gCgsdmT
WRYmon5pHU5RlC2WHEKmdss=
=62Tj
-----END PGP SIGNATURE-----