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

[Rusty B. <ho...@sb...>]

(sorry I'm so far behind here!)

One thing I wanted to say about an earlier message of yours (a few
weeks ago?), I think your idea of having the class have a
getSerializableClassName() (or whatever) & having the serializer call
that, instead of having the class call setSerializableClass() in its
serialize(), is good.

At first I was resistant because it's one more thing for
Serializables to implement (a 50% increase in the API, appalling!!),
but if the base class version is something like

    return ClassLoader::getTypeIDName(typeid(*this));

then "in theory" it would almost never need to be overridden by
subclasses.  And doing it your way means that Serializable subclasses
who don't have any additional members to serialize don't even need to
implement serialize(); their superclass will do the right thing.  I
have classes whose entire serialize() is:

    Foo::serialize(ser);
    ser.setSerializableClass("Bar");

and your change makes that unnecessary.  (good!)

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

Hmmm... well... (but you *can* still subclass Serializable?  I
haven't read your later messages yet, but it sounds like this is no
longer necessary?)

The main thing which makes me unsure that this is a feature is, if
you have a Serializable class, you know exactly where to look for the
serialize() and deserialize() code, because the API tells you.  (And
doxygen etc. will document this for you.)  It sounds like with the
template version, you still need methods which have the same
semantics as serialize() & deserialize(), but now they can be called
something else, and you have to look at the template instantiation to
find out what their real names are?

> 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,
> low-maintenance and i honestly can't think of any conceivable libfun
> improvements which might make QUB any better. (Maybe you know some for
> loubetomy?)
>=20
> libfun-side: rather than continue a Qt-to-STL port let's take the code =
i've
> got already. It's got a few minor bugs at the moment but they're
> easy-fixers (i'm saving them for last ;). It can do essentially everyth=
ing
> fun/qub's can, plus a few new tricks. Also, it's a more refined model (=
in
> some places, anyway), e.g. in it's separation of nodes and data formats=
,
> it's
> stream-centric i/o API, and flexibility (e.g., no concrete
> LoadableClass/Serializable requirements).

This all sounds fine to me.  The specific bits which I have questions
about are:

- it sounds like the qub tree is being abandoned, but there are still
  things I want out of it:
  - libfunUnit (the map & related stuff) - should I move that into
    the libfun tree?  (I don't have a problem converting that to the
    new s11n API.)  I have other little things which use it, but they
    have to set their LD_LIBRARY_PATH to a built qub tree, which
    isn't so good.
  - loubetomy - it was sooo close to being something people could
    play with!  If qub's install target is never coming back, I
    should move this out too.  (sniff)  (I think it's preferable to
    keep qub & loubetomy together, if people can install them!)

- I haven't looked at the stuff you've checked in yet, but is there
  still a binary format, or is it all convert-to-string during
  serialization?  (I'm not sure, but I *think* the elimination of the
  string conversion business is the reason the binary format was so
  much faster.)  It would be nice if we can keep that performance
  gain; my recollection is that it made the difference between large
  objects being usable & not usable.  (But the problem might just
  have been that my text parser was bogus :)

- Is the old serialization text format still supported?  (As long as
  there's a way for me to convert from the old format, I'm happy; I
  just have a lot of old serialized objects I'd still like to be able
  to use.)

> Unrelated: i've got some code for handling Fudge operations (dF, bags o=
f
> dFs, a pretty nifgy WoundsChart class, some simple combat operations...=
),
> which i think would be suitable for libfun. If that sounds okay let me =
know
> and i'll throw it in lib/fudge (namespace fun? fudge? fun::fudge?).

namespace fun is fine with me!  (the libfunUnit stuff is in the fun
namespace too.)

You know, I wish I would have called the project "libfun" instead of
"libfunutil", because if qub is going into comatose-mode, I'm going
to want to move libfunUnit in there too.

(ha ha, we could request a new project, move the source over, and
have them kill libfunutil...)

--Rusty