Interface question

[Charles D Hixson]

Reiner Pope wrote:
> Charles D Hixson wrote:
>> David Medlock wrote:
>>> Charles D Hixson wrote:
>>>> xs0 wrote:
>>>>
>>>>> ...
>  I don't understand quite what the difficulty is. If I understand you, 
> you are deserializing objects, but you don't know what type they are. 
> After you have deserialized them, you presumably want to do something 
> with them. Am I right?
> 
> So, presuming you want to do something with them, you can probably 
> expect that all the objects can do such a thing. So we declare an 
> interface:
> 
> interface ObjectIveDeserialized
> {
>     void doTheThingIWantThemToDo();
> }
> 
> Then, presuming that you will know all of the formats they can be in at 
> compile-time (you must, else how could you write a parser for them?) 
> then you just declare another interface:
> 
> interface FileParser
> {
>     ObjectIveDeserialized 
> tryToDeserializeThisAndReturnNullIfIFail(Stream input);
> }
> 
> Then you just have a list of all FileParsers and try each of them until 
> one works.
> 
> Maybe I'm completely misunderstanding you, but this doesn't seem to bad 
> in D. How would you do it in a dynamic language like Python, Smalltalk, 
> Ruby?
> 
> Cheers,
> 
> Reiner
No, you can't know that all of the objects will be able to do 
what you want.  You can EXPECT* that they'll be able to...but 
you won't be able to know.  E.g. "In English you can verb any 
noun in the languge." works, but it's not true.  You can only 
very ALMOST any noun in the language.  So you've got to be 
able to check.  And it's got to be a run-time check.

More basically, I can't know ahead of time the class of the 
object that I'll be deserializing.  I can have an expectation, 
but even that expectation is a run-time kind of thing.  (Files 
have been known to get desynchronized, so I've got to be able 
to detect that what I got wasn't what I expected to get, and 
recover gracefully.)

As for just HOW I'll use it...I haven't written that part yet, 
It involves requiring that each class implement two methods: 
__getstate__ and __setstate__ to specify how it should be 
saved and restored.  Once it's restored, the language 
maintains a dict (think associated array) containing all the 
methods that it implements, so it's easy to check which of 
several alternatives can be used...if any.  In D even the 
deserialization would require 20-50 times as much code per 
class.  Similarly for the original serialization...because the 
Python language has included in it's library classes Pickle 
and bsddb.  (As a first step I'm going to implement a 
Persistent class.  I have the model of the shelve class to 
help me over any tricky spots, even though I intend to use a 
different database and a different basic approach.  And, if I 
somehow couldn't, I could use the shelve class itself as a 
fallback Persistent class...though that would necessitate a 
redesign of the structure that I've been putting together. 
(Design first, code next...reiterate until done.  If you don't 
design first, you won't know where you're going.  If you don't 
code once you've got a chunk of the design complete, you won't 
know that your design is workable.  So you've got to iterate.)

* expecting that something is true means that you know it's 
usually true, but you also know that it sometimes isn't.  If 
you can't computer even an approximate mean value, then you 
can't expect.  If you can derive a standard deviation of zero, 
then you don't need to settle for expecting.