[fU] 1) Serializable is almost dead, 2) libfun direction proposal

[stephan b. <st...@wa...>]

Yo,

After much squinting at template definitions and fighting with their synt=
ax,=20
i've accomplished the second (of several) Holy Grails which i've been aim=
ing=20
for regarding s11n: subclassing Serializable is no longer strictly requir=
ed.=20
The a logically-similar is required, but the funcs may be named different=
ly.=20
This is accomplished by clients specializing a 12-line template class whi=
ch=20
"adapts" the local Serializable-like interface to s11n's core interface. =
For=20
example, for some serializable QObject subclass it would proxy=20
QObject::className() to implClass() (e.g., getSerializableClass() ) and=20
custom-interface de/serialize()-like methods, which will get indirectly=20
called during calls to de/serialize().


You may wonder what the hell i've been doing with all this s11n code when=
=20
we've got a perfectly good one in libfun, and i probably owe an explanati=
on=20
for that. Here goes...

As i've said before, i have really, REALLY wanted a non-3rd-party s11n li=
b=20
(for a long time, too). Aside from the Qt dependency there was always jus=
t=20
the lingering challenge of implementing one without the need for any exte=
rnal=20
libs. As i began to poke around SerialTree and friends, with the hopes of=
=20
finding a good place to start porting to STL, i realized a few important=20
things:

a) parts of it are way over my head, particularly in terms of how to port=
 them=20
away from Qt (a great example is the bin format parser).

b) the more i thought about changing the library the more i got scared ab=
out=20
breaking 3+ years of code in qub.

c) there /were/ fundamental aspects of the model which i wanted to refine=
,=20
mainly in the interest of taking it to the next level of project-portabil=
ity,=20
but i knew i couldn't introduce that level of change without also realizi=
ng=20
the disaster boded in (b).


So, the past 3 weeks or so have seen me doing nothing but hacking on this=
=20
damned library. It's an obsession, partly because it's truly the first co=
de=20
i've ever written which i consider to be useful to more than a small hand=
ful=20
of people ;).

So, here's what i'm going to propose:
(i feel guilty about proposing this, but here goes...)

QUB-side: let's leave libfun as-is in that tree. It's rock-solid,=20
low-maintenance and i honestly can't think of any conceivable libfun=20
improvements which might make QUB any better. (Maybe you know some for=20
loubetomy?)

libfun-side: rather than continue a Qt-to-STL port let's take the code i'=
ve=20
got already. It's got a few minor bugs at the moment but they're easy-fix=
ers=20
(i'm saving them for last ;). It can do essentially everything fun/qub's =
can,=20
plus a few new tricks. Also, it's a more refined model (in some places,=20
anyway), e.g. in it's separation of nodes and data formats, it's=20
stream-centric i/o API, and flexibility (e.g., no concrete=20
LoadableClass/Serializable requirements).

(i'm talking here only about the s11n-related code - the rest should also=
 be=20
ported to STL or equivalent.)

To be honest, i could go on for a long time about it (i haven't been this=
=20
excited about my own code in a long, long time!). i've already written so=
me=20
30 printed pages of docs (exclusive of API docs), if that gives any=20
indication of the drive it's given me.

i anxiously await your opinions...


Unrelated: i've got some code for handling Fudge operations (dF, bags of =
dFs,=20
a pretty nifgy WoundsChart class, some simple combat operations...), whic=
h i=20
think would be suitable for libfun. If that sounds okay let me know and i=
'll=20
throw it in lib/fudge (namespace fun? fudge? fun::fudge?). i'm planning o=
n=20
using Fudge mechanics as the core for a space-sim environment i'm working=
 on=20
(which i would eventually like to put a gcom-based front end on).
(Speaking of gcom: might it not make half a gram of sense to move that in=
to=20
libfun, or at least develop the next generation (ui-neutral) in libfun?)
And speaking of qub: gutting the build tree and replacing it with toc is =
first=20
on my list, as soon as my obsession with s11n dies down enough that i can=
=20
think of something else :/.


--=20
----- st...@wa...
http://qub.sourceforge.net  http://libfunutil.sourceforge.net        =20
http://toc.sourceforge.net  http://countermoves.sourceforge.net
http://stephan.rootonfire.org  et al.