Re: [PHP4BETA] Re: SESS: objects containing objects *final statement*(?) please read!
| From: | Kim Shrier | Date: | Fri, 25 Feb 2000 19:23:02 +0000 |
| Subject: | Re: [PHP4BETA] Re: SESS: objects containing objects *final statement*(?) please read! | ||
| References: | 1 2 3 4 | Groups: | php.version4 |
| Request: | Send a blank email to php-version4+get-10987@lists.php.net to get a copy of this message | ||
Kristian Köhntopp wrote:
>
> "Stig S. Bakken" wrote:
> > Now, when it comes to waking up unserialized objects again, calling the
> > constructor is definitely not what we want.
>
> In Nextstep and Objective-C things were like this (for a reason):
>
> The initializer (the initializing half of a constructor)
> was always called "init" (and not like the class). That way,
> you could have a derived class which had any class as a parent
> class without coding the parent classes name multiple times.
> This is unlike PHP and C++, where
>
> class B extends A {
> function B() {
> A::A(); // call parent constructor
> }
> }
>
> the parent class name is included multiple times, leading to
> a classic update anomaly.
>
I actually split out the initialize function into a separate method so that
I can have different initializers for different occasions, very similar to
the way Nextstep Objective-C classes defined multiple init methods. I name
most of them init () or initWithSomeParameter (someParameter) in the same
way that Next did.
However, what I really find irritating is having to use the class name
of the parent class in order to invoke the parent's implementation of a
method. Is it too late to add a $super variable to PHP4 so that I could
write the following kind of code:
class A {
var x;
function init () {
$this->x = "some value";
}
}
class B extends A {
var y;
function init () {
$super->init ();
$this->y = "some other value";
}
}
> Then there were optional "freeze" and "wakeup" member
> functions which, if present, were called before serialization
> and after unserialization. These functions had the opportunity
> to make the object ready for serialization or reinitialize it
> after serialization. They also were able to return "false" to
> exempt them from serialization as a whole.
>
> Kristian
>
I found that the Next serialization conventions were able to handle every
situation where I needed to freeze-dry an object. I think it would be a
good idea to pattern after their example.
> --
> Kristian Köhntopp, NetUSE Kommunikationstechnologie GmbH
> Siemenswall, D-24107 Kiel, Germany, +49 431 386 436 00
> Using PHP3? See our web development library at
> http://phplib.netuse.de/ (We have moved! Update your
> bookmarks!)
Kim
--
Kim Shrier - principal, Shrier and Deihl - mailto:kim@tinker.com
Remote Unix Network Admin, Security, Internet Software Development
Tinker Internet Services - Superior FreeBSD-based Web Hosting
http://www.tinker.com/