Aspect Weaver

Mr Gibbs,

Those were very good posts and I appreciate reading them. I could have
sworn Phlip was arguing the case for XML but apparently, according to
the doctrine of reverend Phlip, this seems not to be the case.

I am confused. I am going to have a lie down.

T

Phlip wrote:

> > furthermore, to my knowledge only Mr. Mates is a professional
> > game developer working for a game company (I am not), although I
> > believe that Mr. Quinn and maybe Mr. Plunket have their own
> > independent games developed and published. all three have derided
> > your position on xml.
> > think, man.
>
> Uh, Tom wrote lots of the XML stuff I referenced...
>
> (Sorry Tom!)

Heh, no actually I just wrote the bit that turns XML into C data
structures. The parser was already there and the XML was already
in the pipeline, I just needed a better solution than "derive
from the XML parser every time you add a new data type." So I
wrote a derived class that loaded any arbitrary C structure by
matching names to fields.

Still, though, writing the parsers for easier formats could be
done in an order of magnitude less code, they'd be faster, and
they wouldn't use dynamic memory...

(FWIW, I've never had an indy game make it out into the wild, but
I've been paid to work on games that end up in stores for a lot
of years.)

-tom!

--
There's really no reason to send a copy of your
followup to my email address, so please don't.

Mark A. Gibbs wrote:

> i'm curious as to where the tdd doctrine stands on including crap-ass
> 3rd party libraries in the codebase.

If I may,

TDD doctrine, as I understand it, says that you assume that the
code you're integrating works as advertised. I believe that
Michael Feathers wrote a book called "Working with Legacy Code",
in which the definition of "Legacy Code" becomes "code that is
not under comprehensive unit tests". In that definition, third
party libraries are "legacy," and you just start out assuming
they work.

Now, we all know that many third party libraries have bugs. So,
in part of working with this legacy code, once we discover those
bugs, we write tests to expose them. Perhaps we write some
workaround code also, and we set up the tests for those bugs to
"expect failure," so that at some point in the future we get a
notification if/when those bugs are fixed, so we can take out our
workaround(s).

In short, my feeling is that pragmatism underlies much of the
agile movement. Do TDD in your work, but don't expect that the
whole world does TDD. Instead, expect that the rest of the world
is working to put out software that does what it's expected to
do, and don't worry about "maybe" until something actually
happens.

> are you required to rigourously test the 3rd party tool output as
> well? otherwise, how sure can you be that it was a.) tested
> properly to begin with and b.) tested in situations that match
> your own.

In testing your own code, you're testing the entirety of this
third party library that you care about. By definition, you
don't care about bugs in modules of this library that your code
doesn't use. Nor do you care about awkward boundary conditions
that your application never approaches.

As long as your application does The Right Thing, don't worry
that there might be other bugs in the third party code. Again-
through the tests that you've written for your own code you are
implicitly testing all of that third party library that is
interesting to test.

> the more angles i approach the idea of including xml in my games,
> the less attractive it becomes.

I only care about the angle that is '<' and '>' being all over
the damn place. Oh yeah, and the fact that XML doesn't
really help you with the actual parsing of the data, it just
gives you a hideous format to deceive, inveigle, and obfuscate...


-tom!

--
There's really no reason to send a copy of your
followup to my email address, so please don't.

Tom Plunket wrote:

> In short, my feeling is that pragmatism underlies much of the
> agile movement. Do TDD in your work, but don't expect that the
> whole world does TDD. Instead, expect that the rest of the world
> is working to put out software that does what it's expected to
> do, and don't worry about "maybe" until something actually
> happens.

Systems like TDD change the balance of the "build or buy" question in favor
of "build", for some narrow modules. That is why Philippa C. can advocate
rolling her own text data format. She uses Haskell to build a proof system
around it, as she goes. That is why I can use TDD to build a recursive
descent parser in a couple hours, or a Lint system for MS's RC format in a
couple days.

So, TDD is yet another reason why XML sucks.

However, MS replaced RC with RESX. Guess what that uses...

> I only care about the angle that is '<' and '>' being all over
> the damn place. Oh yeah, and the fact that XML doesn't
> really help you with the actual parsing of the data, it just
> gives you a hideous format to deceive, inveigle, and obfuscate...

Try YAML.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

On Mon, 7 Mar 2005, Phlip wrote:

> Systems like TDD change the balance of the "build or buy" question in favor
> of "build", for some narrow modules. That is why Philippa C. can advocate
> rolling her own text data format. She uses Haskell to build a proof system
> around it, as she goes.

Actually in this case I usually don't bother - though I guess half an hour
with QuickCheck would be enough to figure out a check that ensures
deserialise.serialise = id. I say I guess because I haven't actually used
QuickCheck before, but I know that it takes test specifications that
aren't much more complicated than what I just wrote.

--
flippa@flippac.org

Performance anxiety leads to premature optimisation

Philippa Cowderoy wrote:

> Phlip wrote:
>
> > Systems like TDD change the balance of the "build or buy" question
in favor
> > of "build", for some narrow modules. That is why Philippa C. can
advocate
> > rolling her own text data format. She uses Haskell to build a proof
system
> > around it, as she goes.
>
> Actually in this case I usually don't bother - though I guess half an
hour
> with QuickCheck would be enough to figure out a check that ensures
> deserialise.serialise = id. I say I guess because I haven't actually
used
> QuickCheck before, but I know that it takes test specifications that
> aren't much more complicated than what I just wrote.

I was trying to be generous. I was trying to imply that TDD wasn't the
only validation system that can change the balance of the "buy or
build" question.

Okay. Only TDD or Haskell can change the balance...

--
Phlip