|Problems? Is your data what you think it is?|
Re: Re: Re: Yet Another Perl Object Model (Inside Out Objects)by BrowserUk (Pope)
|on Dec 15, 2002 at 03:52 UTC||Need Help??|
I probably should have waited for a few other to have responded to my question before replying, but it struck me that serialising objects from the outside is actually a rather strange requirement, and can only be done in perl because of the peculiar nature (relatively speaking) of the way OO is implemented in perl.
In most OO languages, if serialisation is required, it is done by requesting the object to serialise itself and return that to the caller. Which is what I added to my version of the Quote class like this.
and to its super class QuotePlus like this:
Of course, I haven't written the obverse fromString method yet, but I don't actually see the need for it. The toString method would be used mostly for debugging and perhaps for inclusion into error messages. I don't see me having a need to recreate instances of a class from their serialised form.
I also added what I would see as a class method rather than an instance method, to dump all instance data for a class. For this I did use Data::Dumper like this.
Barring this from being called as an instance method makes sense to me as what is returned is class specific rather than instance specific.
In terms of persistance, I'm torn between whether a class should know how to persist itself, of whether this should be done eternally, or by inheritance from a named class.
It seems attractive at first to see this as a responsibility of the class itself, but then the persistance mechanism becomes fixed and requires modification of you change your database for example.
I can see the merit in doing this from outside the class at the application level, in terms of "serialise & save" as this allows different applcations to use the same classes and different persistant storage.
However, I see a problem with this in that if I have two subclasses of a base class and I want to persist all instances of one. Dumping one of the subclasses (via a class dump method) and saving it is going to also save instances of the base class that were created via the second subclass (if your using the Inside Out method).
However, doing it one at a time through an instance method requires me to iterate over every instance I have created. Possibly safer, but painful none the less.
The third method I see, is to have every class inherit (either directly or indirectly) from a Persistance class and it would provide each instance with a Persist method and a virtual class method PersistAll that a class could override to cause it to persist all of its instances. This allows the Persistance class to be swapped out for a new one whenever you change your storage medium, database etc.
I note for the readers that I have done very little in way of OO in perl, and have never had to write this type of library classes in other OO languages, always having just made use of existing classes for these sort of things. I will say that I have always been disappointed in those I have used in Java, C++ and even my breif forays in SmallTalk many years ago.
Examine what is said, not who speaks.