Aspect Weaver

In article <1107544079.088634.7750@g14g2000cwa.googlegroups.c om>,
phlip2005@gmail.com says...
> Nathan Mates wrote:
>
> > Debug and release builds of our game use exactly the same data
> > files. What we devlop with is what we ship. You do things differently
> > than us. If you find that "hard to believe," (your words), then the
> > problem lies on your end.
>
> Regardless of the format and encoding of such "data files", when they
> are inside your console, they started somewhere - possibly in a
> human-friendly encoding - outside your console.
>
> The point: Human friendly things are easy to change, so don't put
> details like the power of a gun into C++. Hence, use SOMETHING -
> possibly Lua tables, possibly text with just a little bit of < and >
> marks, for delimiters, possibly a File Format Du Jour - to edit those
> data tables.

XML is the worst of both worlds, IMO - neither human friendly nor
compact!

As an extension to HTML, it's fine.

- Gerry Quinn

Gerry Quinn wrote:

> XML is the worst of both worlds, IMO - neither human friendly nor
> compact!

If you use a tab or comma-delimited format, you will hit a problem when
someone asks to store a string with a tab or comma in it.

And you'l hit a problem when someone asks to add a field to only one record.
And another problem when you find a need to nest records.

To solve all these problems early, pick a widely-supported text format that
rigorously defines its escape, growth, and nesting mechanisms.

Then /don't/ use all of XPointer, schemas, XSLT, etc. inside your console.
Keep most of the XML outside the console, and trivially convert some into a
tight binary format before using it in the final game.

If you invent such a text format on the fly, your are back to the bad old
days of Unix RC files, where each application reads a slightly different
format, with different delimiters and escapes. And you lose all the
compatible tool support from multiple vendors.

If some other text database format had "won", I would recommend it. XML has
no special claim to elegance. I can't even find a stable pretty-printer for
it. But has anyone who disses XML by reflex some horror story to back them
up?

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

On Sat, 5 Feb 2005, Phlip wrote:

> Gerry Quinn wrote:
>
>> XML is the worst of both worlds, IMO - neither human friendly nor
>> compact!
>
> If you use a tab or comma-delimited format, you will hit a problem when
> someone asks to store a string with a tab or comma in it.
>
> And you'l hit a problem when someone asks to add a field to only one record.
> And another problem when you find a need to nest records.
>
> To solve all these problems early, pick a widely-supported text format that
> rigorously defines its escape, growth, and nesting mechanisms.
>

Widely-supported is a crock, all you need is supported by all the tools
that operate on your data - which in this context are going to be in-house
anyway. There are other clearly-defined formats that're more
human-readable, and having some kind of control over growth is also a good
thing (to put it another way, you'll get better validation and format
version control).

--
flippa@flippac.org

Performance anxiety leads to premature optimisation

Christer Ericson wrote:

> > > XML is bloat, personified. Ascii file formats do not belong on a
> > > console, PERIOD. Then again, (unlike Phlip), I've got actual
> > > experience in this area.
>
> I agree 100% with Nathan. XML is bloat personified and it
> does not belong in a game pipeline.

I am glad then that the two of you agree, and that you both
similarly miss the point entirely. Why am I not surprised?

> > Consider that the decision was made by your boss, without your
> > consultation. Would you slap this person?
>
> Stupid comments like that should really be beyond even you
> Tom, but no. I guess you like being the stereotypical american.
> You know, the one that can't tell sarcasm from seriousness,
> or, in this case, a figure of speach from a literal act.

Explain to me oh enlightened scandanavian friend of game
developers, what exactly would Nathan do if someone beyond his
control were to dictate that XML were to be used for some part of
the process? What would he do if someone in his control were to
suggest it? (So typical of "enlightened" folks to think that
"stupid merkins" don't understand sarcasm, especially when they
go on about this failure to understand sarcasm when they respond
to sarcasm itself as if it were straight-up serious and literal.
<sigh>)

Christer- you're in Sony R&D right? What's your affiliation with
the people developing Collada? If XML is so terrible, why don't
you show those people that it is that way? At least I've gone on
record saying that Collada doesn't actually solve the problem
that it's set out to solve, and that it comes with a bloated and
pretty much useless encrufted coating... I mean, if someone were
to be working on next-gen internal engine technology, and if that
person worked for the same company that published a nearly
useless "file format specification" designed intentionally for
"next generation content needs", then you'd think there'd be some
interaction, eh?

-tom!

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

"Phlip" <phlip_cpp@yahoo.com> wrote:

>Casey Hawthorne wrote:
>
>> Aspect weaving is for cross-cutting concerns.
>>
>> Better for:
>> - logging
>> - cacheing
>> - concurrency
>> - security

- debugging is another biggie!

>>
>> Making the above cross-cutting concerns more modifiable for business
>> applications!
>>
>> The code with AOP is supposed to be less complex and less intertwined!
>>
>> In games, usually one doesn't worry about modifiability/flexibility,
>> so much!
>
>Part of helping me learn the "Object Oriented" paradigm was, of course, the
>verbiage. But another part was learning that each object has [an equivalent
>of] a single pointer to a table of slots, one for each named method.
>Overriding a class created objects with a pointer to a different table, with
>some same and some different pointers to methods in the table.
>
>So what's the mechanism inside AOP?

Google:

kiczales-aosd-2003.ppt

AOSD_1up.pdf

--
Regards,
Casey

In article <lmja015tp9dl91npodikquaslob7390fvc@4ax.com>,
plunket@gmail.com says...
> Christer Ericson wrote:
> > I agree 100% with Nathan. XML is bloat personified and it
> > does not belong in a game pipeline.
>
> I am glad then that the two of you agree, and that you both
> similarly miss the point entirely.

While I can't speak for Nathan, I don't think either one
of us have missed a point here.


> Why am I not surprised?

I dunno, because you're asleep at the wheel again?


> > > Consider that the decision was made by your boss, without your
> > > consultation. Would you slap this person?
> > [...]
> (So typical of "enlightened" folks to think that
> "stupid merkins" don't understand sarcasm, especially when they
> go on about this failure to understand sarcasm when they respond
> to sarcasm itself as if it were straight-up serious and literal.

Sorry to have to break it to you Tom, but your witless
"would you slap this person" comment is not sarcasm by
any definition. Go back to sleep.


> Christer- you're in Sony R&D right?

Whatever gave you that idea? No, product development.
"God of War" specifically:

http://www.gamespot.com/features/6116286/p-12.html
http://ps2.ign.com/articles/567/567466p2.html


> What's your affiliation with the people developing Collada?

Absolutely none. Zero. Zilch. I'm more affiliated with
the XBOX 2 hardware team than I am the Collada people
(well, not really).


> If XML is so terrible, why don't
> you show those people that it is that way?

Not my job. As for the (lack of) usefulness of XML, I already
said my piece in the "xml in games pros and cons" thread on
sweng back in November last year. They can look if up there
if they're interested.


--
Christer Ericson
http://realtimecollisiondetection.net/

In article <0U2Nd.26477$by5.15576@newssvr19.news.prodigy.com> ,
phlip_cpp@yahoo.com says...
> [...]
> If you invent [your own format rather than use XML] you lose
> all the compatible tool support from multiple vendors.

Ah, the mythical tools that make XML all worth it. Exactly
which tools are these and exactly what are they used for?

--
Christer Ericson
http://realtimecollisiondetection.net/

On Sun, 6 Feb 2005, Christer Ericson wrote:

> In article <0U2Nd.26477$by5.15576@newssvr19.news.prodigy.com> ,
> phlip_cpp@yahoo.com says...
>> [...]
>> If you invent [your own format rather than use XML] you lose
>> all the compatible tool support from multiple vendors.
>
> Ah, the mythical tools that make XML all worth it. Exactly
> which tools are these and exactly what are they used for?
>

I guess if you don't have access to a decent parsing and pretty-printing
library it's just about understandable.

--
flippa@flippac.org

Performance anxiety leads to premature optimisation

Philippa Cowderoy wrote:

> Widely-supported is a crock, all you need is supported by all the tools
> that operate on your data - which in this context are going to be in-house
> anyway.

Before anyone starts screeching at the following lecture, I posted a _real_
reason why XML sucks down below.

XML doesn't suck because you lose flexibility when you submit to "vendor
lockin".

For example, one day I might just feel like taking the XML that relates a
Maya geometry to its skin of textures, and formatting that data in a web
page.

Don't ask why. I'm the test engineer. I have ways of dealing with people who
ask /why/ I do what I do.

With XML, I can use XSLT to generate XHTML.

Big whoopdeedoo. With the Text File Du Jour, I can use Perl to generate
HTML, too. So what?

XSLT gives me the choice of GNU's xsltproc or MS's MSXSL.

When I pick tools, these desisions are hard to reverse, so I err on the side
of generics and widespread support.

If I don't like xsltproc's bugs (see below), I can switch to another XSL
solution very easily.

If the source ain't in XML, I still have options - just not as many.

> There are other clearly-defined formats that're more
> human-readable, and having some kind of control over growth is also a good
> thing (to put it another way, you'll get better validation and format
> version control).

Because nobody can think of a real, internal reason why the XML format
itself sucks, here's one:

<x>a<y/>b</x>

What node is b in?

b is a member of the contents of <x>. However, the XML recommendation does
little to help tools support y's relation to b.

Then, many tools just give up, and pretend they only see <x>ab<y/></x>.

Folks attempting to discuss why XML sucks should have known about this
technical problem in the recommendations and the tools.

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

On Sun, 6 Feb 2005, Phlip wrote:

> Philippa Cowderoy wrote:
>
>> Widely-supported is a crock, all you need is supported by all the tools
>> that operate on your data - which in this context are going to be in-house
>> anyway.
>
> Before anyone starts screeching at the following lecture, I posted a _real_
> reason why XML sucks down below.
>
> XML doesn't suck because you lose flexibility when you submit to "vendor
> lockin".
>

When I'm the vendor in question, I'm quite comfortable taking the risk.

> For example, one day I might just feel like taking the XML that relates a
> Maya geometry to its skin of textures, and formatting that data in a web
> page.
>
> Don't ask why. I'm the test engineer. I have ways of dealing with people who
> ask /why/ I do what I do.
>
> With XML, I can use XSLT to generate XHTML.
>
> Big whoopdeedoo. With the Text File Du Jour, I can use Perl to generate
> HTML, too. So what?
>
> XSLT gives me the choice of GNU's xsltproc or MS's MSXSL.
>

Who says you have to stick to Perl to generate your HTML? It's
nowhere near as hot at structured text processing as people seem
to think, regexes or no. Granted, in the generic case I don't have the
option of using XSLT.

> When I pick tools, these desisions are hard to reverse, so I err on the side
> of generics and widespread support.
>

Right. This is why I tend to define my formats in terms of things like
BNF. This gives the further advantage that I know it's easy to write a
parser for it, and fairly trivial to translate the spec into a parser for
most parser generators and parsing libraries. Pretty-printers can be
specified with similar ease. Throw in a specification for the datatype
sitting in-between and the basic operations on it and hey, we're done.

Boom. No vendor lock-in, no need for heavyweight tools.

> If I don't like xsltproc's bugs (see below), I can switch to another XSL
> solution very easily.
>
> If the source ain't in XML, I still have options - just not as many.
>

You do, however, have the possibility of working with a format that's
simply-defined enough that a competant programmer really can duplicate the
processing in a day if not less.

I'm finding this part of the discussion particularly amusing because at
the core, XSLT is just a particularly horrific functional language. I'm
genuinely more comfortable with the more generic tools I have at my
disposal.

>> There are other clearly-defined formats that're more
>> human-readable, and having some kind of control over growth is also a good
>> thing (to put it another way, you'll get better validation and format
>> version control).
>
> Because nobody can think of a real, internal reason why the XML format
> itself sucks, here's one:
>
> <x>a<y/>b</x>
>
> What node is b in?
>
> b is a member of the contents of <x>. However, the XML recommendation does
> little to help tools support y's relation to b.
>

I would've put that as a sequence, roughly equivalent to x [Text "a", y,
Text "b"] (where x and y are data constructors, as is Text). Certainly I'd
be very upset about a tool that ignored sequence within a file, it'd make
constructing many structures a laborious and painful task (kiss human
readability goodbye).

> Then, many tools just give up, and pretend they only see <x>ab<y/></x>.
>
> Folks attempting to discuss why XML sucks should have known about this
> technical problem in the recommendations and the tools.
>

Not necessarily, because there're enough other reasons XML sucks to not
have had to get this far. This doesn't exactly impress me any further,
however.

--
flippa@flippac.org

A problem that's all in your head is still a problem.
Brain damage is but one form of mind damage.