[Ohrrpgce] SVN: james/5080 Fix broken slice mutators. slices.bas compiles again now

[Jay Tennant]

> From: James Paige <Bob at HamsterRepublic.com>
> Sent: Tuesday, February 28, 2012 11:13 AM
> 
> On Tue, Feb 28, 2012 at 09:04:21AM -0800, subversion at HamsterRepublic.com wrote:
> > james
> > 2012-02-28 09:04:21 -0800 (Tue, 28 Feb 2012)
> > 57
> > Fix broken slice mutators. slices.bas compiles again now
> > ---
> > U   wip/slices.bas
> 
> I have several thoughts about these accessors and mutators.
> 
> the OHR code is riddled with crazy naming schemes and inconsistent 
> style, but slices.bas is wone of the few files that is well organized 
> and consistently style, so it would be nice to keep it that way.
> 
> What I notice especially is that all the existing slice related 
> functions all take the Slice ptr as the first argument. I would like it 
> if these new slice mutator functions would do the same.

That sounds fine. I can change that.

> There are other style issues like spaces instead of tabs, or names in 
> the form of SomethingSomethingSlice() instead of 
> sliceSomethingSomething() but those are of much less importance to me 
> than the argument order.

I can use spaces instead of tabs. I'll change that as well. The naming
kind of interests me. I notice there's a SliceDraw as well as DrawSlice,
and some of the functions begin with Slice, and others do not (ie.
SliceLoadFromFile, SliceDebugRemember, SliceXAnchor, SliceCollidePoint,
etc.). In my personal experience, I find it easier to understand context
when dealing with objects in object-oriented programming than with
procedural programming because the functions are grouped with the
object's class (or instance, if prototype-based language). Since our
use is between multiple languages, I like prefixing an ID to the 
function name to relate it to the objects on which it operates. I'm sure
you can think of libraries that follow this practice.

I can use the SomethingSomethingSlice() naming convention instead if
it is preferred. I agree that consistency would be golden, so I'll work
towards that end. With the large number of functions present in the
engine, the prefixed ID does act as a kind of convenient namespace.

> I was also thinking about null ptr checking. Most of the other slice 
> functions do explicit null ptr checking. In the past, this was a really 
> big deal for me because null ptr bugs used to be INSANELY frustrating to 
> debug. However, now that we can run in gdb, and use valgrind (and now 
> that I know how to do both of those things) I guess I don't have to be 
> the same stickler for null ptr checking that I used to be...

Null ptr checking sounds good. You can modify the code any way you see
fit. I don't have feelings attached to this code. ;)