Re: Hooks

I once misremembered something Gilad Bracha said about static state in Newspeak:

It may seem like you need static state, somewhere to start things off, but you don't. You start off by creating an object, and you keep your state in that object and in objects it references. In Newspeak, those objects are modules.

I mentally replaced "static" with "private" and it still made sense.

Data hiding helps protect clients against changes, but clients aren't the only concern when maintaining and debugging code. So you really have to insulate yourself against clients but open yourself for higher powers.

Once I made that leap, writing maintainable (at least for me) code became a lot easier.

MSN
From: [email protected] [mailto:[email protected]] On Behalf Of Richard Fabian
Sent: Tuesday, June 08, 2010 12:33 PM
To: [email protected]
Subject: [Sweng-Gamedev] Hooks

I work at a real games company doing real games coding. I've been doing it long enough now to know that my real barrier to getting stuff done is never about finding the perfect abstraction, it's about knowing how to get at the transition from one state to another for some variable inside a class that hides it's implementation.
After all the architects have gone home, and the engine has been in use for a a couple of games, you get in that situation where adding stuff doesn't involve coding any more. It's more like detective work. Most of the time. The reason it's most of the time is probably because all the good coders that could be doing cool new coding are spending their time figuring out how to unlock the mysteries of coder X who left the company two years ago, and had a really clever way of encapsulating his data.

Now, I'm not saying this is because of OO, but from each of my experiences where I can't figure out how an object's state got how it got, it's been because someone decided that the object should encapsulate its state and hide it from the rest of the world. Thoroughly.

This used to be a mantra of mine. Hide the data, the internal state of an object is it's problem.

But, the last few years have taught me that really, what I always needed was to have a way of hooking into all variables and catching them changing state. We accidentally had this "variable registry" for globals, but until the last few months I hadn't really given it too much thought from an entity point of view. Someone pointed me at aspect oriented, and though I thought it was nuts, it did make me think that it would be nice to have a generic publish and subscribe mechanism built into all our objects.

Going back to data oriented stuff: transforms do provide (as do SOs and POs) a solid way to hook into the state changes in a system. They automatically let you subscribe to all state changes quite easily. Whatever your implementation, as long as you write out your code as data transforms, you'll always have an opportunity to catch modifications to state.

OO C++ might be nicer to look at than data oriented C++ (if it's done right) but it seems that as it so seldom is done right, can't we just move to a paradigm that newbies will be able to understand enough to not cause us massive grief later on when we pick up the pieces?

--
fabs();
Just because the world is full of people that think just like you, doesn't mean the other ones can't be right.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com