Permission to nuke TDataType?

Hi,

There is currently a 'brl.data' module in there that implements a 'data type' system.

It was really an early hack at a form of reflection, and has never been properly documented/finished and has more or less been superceded by reflection anyway.

Is anyone actually using this module?

Is it OK to remove it from the next bmx release?

Not me. Squash it.

O/T is there a new stable release on the way? Seems to be loads of changes going on atm.

I'm fine with it. Just going to have to create my own module for saving pixmaps and images (tilemap engine and animations deserialize and serialize methods use them).

permission granted

Fine by me to nuke it and nuke it hard :)

Destroy it.

ditch it .... :)

It's the only way to be sure.

Game over, man. Game over...

Dare I ask, what are TDataTypes?

I don't use them

Its a trick. Get an axe.

(I think we're established that nobody wants it) :)

No problem here.

Oh yeah, dump the TDataType.

Ooo. So is a new release coming?

That would be correct. TData is an object you inherit from that implements DataType, DataType returns an object that allows you to read/write objects of that type from/to streams.

Given that the reflection module makes this entirely unneeded, there's not much point to keeping it around now. Idea was, if I recall correctly, to allow some manner of serialization, but I could be wrong, considering the module is entirely undocumented.

So if I have this right, TDataType is the equivalent of Reflection's TTypeId, or maybe TDataId.

Would TDataType be replaced by TTypeId?

In the archives it only appears to be used directly in Noel's Simple Parse.

Kill it :D

Well, I have been using it. Sure you can remove it, but I hope there will be something better to replace it. There should be some kind of unified serialization that is compatible with the standard TStreams...

Yes nuke it! ... but can I push on the red button?

There isn't really any good way that I can think of to handle a 'unified serialization that is compatible with the standard TStream', but the write-it-yourself option is always good in this case. Either that, or I think Brucey may have written a bit of serialization code that you could look at for reference.

As for something better to replace the module itself, you got brl.reflection, so you're pretty well off as-is considering you have access to every field, data type, method, etc.

burn it! burn it with fire! :)

Have you looked at the brl.data module? The way it worked was you extended TDataType to register a data type, and then wrote the code for writing and reading object data. Then you could use stream.WriteObject obj to write any objects to any stream (wrapped in a TDataStream). It's OK to have to write your own serialization code, but I think there should be a unified way to call it, so one can write more generic code.

In space no one can hear you use TDataType.

The nice thing about what TDataType provides is a raw format, which can be saved into any stream, and at any time and order. But removing it from the system isn't a killer to the people using it already.. they just have to steal the code before it dies :D

i have never used the TDataType.... (maybe i missed something?)
so no problem here...

The thing with the movies is that the mythos developed so far before all the sequels to the movies. So basicly you already knew before all the sequels about the aliens being in essence a weapon, the ecosystem of their home world and so forth.

For me I think Alien 3 and AvP2 were both pretty realistic, even if as movies not too good. Aliens 4 and AvP1 were totally goofy.

Nuke it!