STB layout changes with a proxy: is this a sound approach?

Andy/Blair,

The time has finally come for me to make STB changes to something that uses
an STB proxy.  It appears that I've solved the problem, but, it was easier
than I expected, and I'd very much appreciate your reading the following and
flagging anything that sounds like a possible problem in my approach.

A particular STB-proxied class needs to add a couple of instance variables.
Forgetting the class itself for the moment, my instinct is to bump the
version number on the proxy class, add accessor methods, etc., and write STB
converter methods for it, adding default or computed values for the instance
variables, or at least inserting nils to signal that they need to be
computed later.  Somewhere in there, it's necessary to tweak either a
factory method or the "real" class' #stbSaveOn: to save new stuff in the
modified proxy.  Then there's the problem of using the new aspects in the
proxy, whether inserted by the STB conversion methods or placed there
directly by a "modern" instance to fixup a working instance of the class.
The class itself changes too (of course), to use the new instance variables.

With that done, when an old STB file containing a (proxied) instance of the
class, the proxy itself is actually in-filed, and then sent #stbFixup:at: to
recreate the proxied object.  Prior to #stbFixup:at:, the binary filer
realizes the proxy class has changed STB version, and first converts the
proxy it read from the file.

Having done all of that, I'm able to read old instances of the class.  Since
instances of the "real" class are not directly serialized, they appear not
to require any special attention other than the changes I'd have made
without concern for STB versioning.  Am I missing something?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill

You wrote in message news:9aguih$2e2$[hidden email]...
>
> The time has finally come for me to make STB changes to something that
uses
> an STB proxy.  It appears that I've solved the problem, but, it was easier
> than I expected, and I'd very much appreciate your reading the following
and
> flagging anything that sounds like a possible problem in my approach.
> ...

A similar issue exists with Views, which are binary filed as STBViewProxy
objects. You may remember that prior to 4.0 upgrading these was a pain
because there was only a proxy version number and the particular View class
did not get involved in the upgrade. Therefore one had to modify a system
method (STBViewProxy>>stbConvertFrom:) to effect the conversion, and also
STBViewProxy>>stbConvertFrom: had to switch-on-type (aaarrrggh!).
STBViewProxy/View now employ a new approach where a version number is also
held in the proxy itself, with this being the stbVersion of the view class
that was saved. This is done from STBViewProxy>>stbFixup:at:, which sends a
#stbConvertProxy: message to the View class if a conversion is needed.
STBViewProxy delegates conversions of the proxy off to the View class if
that version does not match the View class' current stbVersion. Of course
STBViewProxy had to have a version instance variable added to support this,
so its own stbVersion had to be bumped and a one-off conversion written for
that.

I'm afraid I didn't really understand all of the rest of your posting, but I
think the simple pattern used by STBViewProxy/View is applicable to all STB
proxies.

Regards

Blair

Blair,

> STBViewProxy/View now employ a new approach where a version number is also
> held in the proxy itself, with this being the stbVersion of the view class
> that was saved. This is done from STBViewProxy>>stbFixup:at:, which sends
a
> #stbConvertProxy: message to the View class if a conversion is needed.
> STBViewProxy delegates conversions of the proxy off to the View class if
> that version does not match the View class' current stbVersion. Of course
> STBViewProxy had to have a version instance variable added to support
this,
> so its own stbVersion had to be bumped and a one-off conversion written
for
> that.
>
> I'm afraid I didn't really understand all of the rest of your posting, but
I
> think the simple pattern used by STBViewProxy/View is applicable to all
STB
> proxies.

The idea is to simply version the proxy instead of the object.  Every time
the "real" class changes layout, the proxy does too, and the normal STB
conversion mechanism seems to work as one would hope.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill


You wrote in message news:9ahmr5$53rdf$[hidden email]...
>
> The idea is to simply version the proxy instead of the object.  Every time
> the "real" class changes layout, the proxy does too, and the normal STB
> conversion mechanism seems to work as one would hope.

Yes that is fine as long as there is a one-to-one mapping between your proxy
classes and your actual classes. In the case of the View hierarchy that was
very much not the case, and hence it was not a sufficiently flexible
solution. If you should later find that your 1:1 becomes 1:M, and you want
to independently version the actual classes, then at that point you can bump
the proxy version for a last time and add a version instance variable  to
hold the actual class STB version.

Regards

Blair

Blair,

> Yes that is fine as long as there is a one-to-one mapping between your
proxy
> classes and your actual classes. In the case of the View hierarchy that
was
> very much not the case, and hence it was not a sufficiently flexible
> solution. If you should later find that your 1:1 becomes 1:M, and you want
> to independently version the actual classes, then at that point you can
bump
> the proxy version for a last time and add a version instance variable  to
> hold the actual class STB version.

Got it.  The 1:1 approach should be fine for this situation; but, the 1:M
solution is nice to keep in mind.

Thanks!!

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]