Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #5244 > unrolled thread
| Started by | "Leonardo Azpurua" <leonardo@exmvps.org> |
|---|---|
| First post | 2012-03-27 12:31 -0430 |
| Last post | 2012-04-12 07:45 -0400 |
| Articles | 16 on this page of 96 — 10 participants |
Back to article view | Back to comp.lang.php
out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-27 12:31 -0430
Re: out of sheer curiosity... "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-03-27 19:06 +0200
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-27 13:04 -0430
Re: out of sheer curiosity... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-28 21:12 +0200
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-28 20:23 -0430
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-29 10:00 +0200
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-29 05:23 -0430
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 11:46 +0100
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-29 14:02 +0200
Re: out of sheer curiosity... Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-29 14:33 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 14:37 +0100
Re: out of sheer curiosity... Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-29 15:59 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 17:58 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-29 09:39 -0400
Re: out of sheer curiosity... Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-29 16:21 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 18:09 +0100
Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-03-29 22:07 +0100
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-29 23:43 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-30 04:52 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-29 16:11 -0400
Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-03-29 22:01 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-29 19:29 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-08 22:50 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-08 17:15 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-09 00:39 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-04-09 00:59 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-08 20:28 -0400
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-08 20:24 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-09 11:29 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 08:27 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 15:20 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 12:03 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 20:04 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 14:37 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 22:50 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 20:17 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 10:05 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 13:28 +0200
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 18:54 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 20:10 +0200
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 20:23 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:17 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:11 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:30 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:43 -0400
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:08 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-11 10:40 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 07:58 -0400
Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-04-10 16:04 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:10 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 18:18 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-04-10 18:20 +0100
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 19:31 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:20 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:57 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:50 -0400
Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-04-10 17:41 +0100
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 17:25 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:16 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 13:44 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 08:04 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 17:37 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:19 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 18:44 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:23 -0400
Re: out of sheer curiosity... Scott Johnson <noonehome@chalupasworld.com> - 2012-04-09 11:50 -0700
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 23:03 +0200
Re: out of sheer curiosity... Scott Johnson <noonehome@chalupasworld.com> - 2012-04-09 15:27 -0700
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 20:25 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 12:48 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 08:06 -0400
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-10 07:52 -0430
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:20 -0400
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-10 12:03 -0430
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:28 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 00:13 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:53 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 22:17 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-11 16:30 -0400
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 20:22 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 12:43 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 08:11 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 18:15 +0200
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 19:09 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 20:17 +0200
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 20:25 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:21 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:34 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 01:00 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:54 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 22:10 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-11 16:31 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 22:40 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-12 00:02 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-12 12:00 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-12 07:45 -0400
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-10 12:43 +0200 |
| Message-ID | <jm12sj$9ap$1@news.albasani.net> |
| In reply to | #5394 |
Jerry Stuckle schrieb: > Objects NEVER persist between different HTTP requests. By definition, > HTTP is a transactional environment and at the end of the request any > objects are destroyed. True. But since we do need objects to persist, we invent things like sessions and serialization so our scripts can *pretend* they persist and will never know the difference. > Objects by definition have state and behavior. Only the state can > persist between transactions; behavior never can - which is why objects > need to be reconstructed. Behaviour is "the methods". And they surely persist since the source files are not destroyed after each request. All instances of a class share the same methods, after all. > Both __construct() and __clone() are types of constructors. __wakeup() > is not (unless you consider sleep() to be a destructor - see above). Why do you keep insisting that I must consider __sleep() to be a destructor if I consider __wakeup() to be a constructor? Consider: 1) __sleep() is called before the corresponding __wakeup() -- by your logic this would mean the destructor is called before the constructor 2) __sleep() is called on a different object than the corresponding __wakeup() -- so it cannot be the destructor corresponding to __wakeup() 3) __sleep() does not destroy anything. On the contrary, it helps to preserve something. It is therefore not a destructor. Greetings, Thomas -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison! (Coluche)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 08:11 -0400 |
| Message-ID | <jm181r$pqn$1@dont-email.me> |
| In reply to | #5400 |
On 4/10/2012 6:43 AM, Thomas Mlynarczyk wrote: > Jerry Stuckle schrieb: > >> Objects NEVER persist between different HTTP requests. By definition, >> HTTP is a transactional environment and at the end of the request any >> objects are destroyed. > > True. But since we do need objects to persist, we invent things like > sessions and serialization so our scripts can *pretend* they persist and > will never know the difference. > >> Objects by definition have state and behavior. Only the state can >> persist between transactions; behavior never can - which is why >> objects need to be reconstructed. > > Behaviour is "the methods". And they surely persist since the source > files are not destroyed after each request. All instances of a class > share the same methods, after all. > No, you cannot use those methods to act on the data while it is serialized, i.e. on disk or in a database. Only the state is present. To use those methods, you need to create a new object using that state data. It is a huge difference which true OO languages handle just fine. Only PHP seems to have a problem with it. >> Both __construct() and __clone() are types of constructors. __wakeup() >> is not (unless you consider sleep() to be a destructor - see above). > > Why do you keep insisting that I must consider __sleep() to be a > destructor if I consider __wakeup() to be a constructor? > > Consider: > > 1) __sleep() is called before the corresponding __wakeup() -- by your > logic this would mean the destructor is called before the constructor > > 2) __sleep() is called on a different object than the corresponding > __wakeup() -- so it cannot be the destructor corresponding to __wakeup() > > 3) __sleep() does not destroy anything. On the contrary, it helps to > preserve something. It is therefore not a destructor. > > Greetings, > Thomas > If you are considering __wakeup() to be a constructor, then __sleep(), being exactly the opposite, would be a destructor. (why do you think they are called "sleep" and "wakeup" if the designers didn't consider them to be opposites?). And what you're saying is that the destructor (__sleep()) is called after a constructor (__construct(), __clone() or __wakeup()). -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-10 18:15 +0200 |
| Message-ID | <jm1mbg$iho$1@news.albasani.net> |
| In reply to | #5408 |
Jerry Stuckle schrieb: > If you are considering __wakeup() to be a constructor, then __sleep(), > being exactly the opposite, would be a destructor. (why do you think > they are called "sleep" and "wakeup" if the designers didn't consider > them to be opposites?). They are opposites with respect to the process of serialization and may be thought of as "to-do-before" and "to-do-after". And __sleep() is not the exact opposite of __wakeup() -- the object is still awake after __sleep() has been called and will continue to "work". You can have a class defining both methods and still have only one of the two methods called during the life time of the instance: $foo = new Foo; echo serialize( $foo ); // end of script // __sleep() is called, but never __wakeup() $string = '<manually created serialized representation of object>'; $foo = unserialize( $string ); // end of script // __wakeup() is called, but never __sleep() > And what you're saying is that the destructor (__sleep()) is called > after a constructor (__construct(), __clone() or __wakeup()). I said the exact opposite: __sleep() is called *before* the corresponding __wakeup(). And look what the PHP manual has to say (emphasis mine): <http://de2.php.net/manual/en/language.oop5.magic.php#object.wakeup>: "Conversely, unserialize() checks for the presence of a function with the magic name __wakeup(). If present, this function can *reconstruct* any resources that the object may have." (So __wakeup() is meant to "reconstruct" something, thus clearly acting as a constructor.) <http://de2.php.net/manual/en/class.serializable.php> "Classes that implement this interface no longer support __sleep() and __wakeup(). The method serialize is called whenever an instance needs to be serialized. This does not invoke __destruct() or has any other side effect unless programmed inside the method. When the data is unserialized the class is known and the appropriate unserialize() method is called as a *constructor* instead of calling __construct()." (Clearly, unserialize() replaces __wakeup(), and if unserialize() acts as a constructor, then so does __wakeup() which it replaces.) Greetings, Thomas -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison! (Coluche)
[toc] | [prev] | [next] | [standalone]
| From | "M. Strobel" <sorry_no_mail_here@nowhere.dee> |
|---|---|
| Date | 2012-04-10 19:09 +0200 |
| Message-ID | <9uj7psF94nU1@mid.uni-berlin.de> |
| In reply to | #5421 |
Am 10.04.2012 18:15, schrieb Thomas Mlynarczyk: > Jerry Stuckle schrieb: > >> If you are considering __wakeup() to be a constructor, then __sleep(), being >> exactly the opposite, would be a destructor. (why do you think they are called >> "sleep" and "wakeup" if the designers didn't consider them to be opposites?). > > They are opposites with respect to the process of serialization and may be thought of > as "to-do-before" and "to-do-after". And __sleep() is not the exact opposite of > __wakeup() -- the object is still awake after __sleep() has been called and will > continue to "work". Good point, the object is still awake, that's why you get a destruct call at the end of script. > And look what the PHP manual has to say (emphasis mine): > > <http://de2.php.net/manual/en/language.oop5.magic.php#object.wakeup>: > "Conversely, unserialize() checks for the presence of a function with the magic name > __wakeup(). If present, this function can *reconstruct* any resources that the object > may have." > > (So __wakeup() is meant to "reconstruct" something, thus clearly acting as a > constructor.) > > <http://de2.php.net/manual/en/class.serializable.php> > "Classes that implement this interface no longer support __sleep() and __wakeup(). > The method serialize is called whenever an instance needs to be serialized. This does > not invoke __destruct() or has any other side effect unless programmed inside the > method. When the data is unserialized the class is known and the appropriate > unserialize() method is called as a *constructor* instead of calling __construct()." > And note the Note: It is not possible for __sleep() to return names of private properties in parent classes. (...) Instead you may use the Serializable interface. But it is more work. /Str.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-10 20:17 +0200 |
| Message-ID | <jm1tfd$3vf$1@news.albasani.net> |
| In reply to | #5430 |
M. Strobel schrieb: > It is not possible for __sleep() to return names of private properties in parent > classes. (...) Instead you may use the Serializable interface. I wish I could use __sleep() without having to return an array of properties at all so I could just sing a lullaby to my object and let serialize() serialize /all/ properties without having to specify them all. Greetings, Thomas -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison! (Coluche)
[toc] | [prev] | [next] | [standalone]
| From | "M. Strobel" <sorry_no_mail_here@nowhere.dee> |
|---|---|
| Date | 2012-04-10 20:25 +0200 |
| Message-ID | <9ujc9nFae4U2@mid.uni-berlin.de> |
| In reply to | #5436 |
Am 10.04.2012 20:17, schrieb Thomas Mlynarczyk: > M. Strobel schrieb: > >> It is not possible for __sleep() to return names of private properties in parent >> classes. (...) Instead you may use the Serializable interface. > > I wish I could use __sleep() without having to return an array of properties at all > so I could just sing a lullaby to my object and let serialize() serialize /all/ > properties without having to specify them all. Omit _sleep(), and sing. /Str.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-10 23:21 +0200 |
| Message-ID | <jm289p$rte$2@news.albasani.net> |
| In reply to | #5438 |
M. Strobel schrieb:
>> I wish I could use __sleep() without having to return an array of properties at all
>> so I could just sing a lullaby to my object and let serialize() serialize /all/
>> properties without having to specify them all.
>
> Omit _sleep(), and sing.
// SCNR
while ( !asleep() ) { $sheep++; }
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 17:34 -0400 |
| Message-ID | <jm291u$b2h$1@dont-email.me> |
| In reply to | #5421 |
On 4/10/2012 12:15 PM, Thomas Mlynarczyk wrote: > Jerry Stuckle schrieb: > >> If you are considering __wakeup() to be a constructor, then __sleep(), >> being exactly the opposite, would be a destructor. (why do you think >> they are called "sleep" and "wakeup" if the designers didn't consider >> them to be opposites?). > > They are opposites with respect to the process of serialization and may > be thought of as "to-do-before" and "to-do-after". And __sleep() is not > the exact opposite of __wakeup() -- the object is still awake after > __sleep() has been called and will continue to "work". You can have a > class defining both methods and still have only one of the two methods > called during the life time of the instance: > > $foo = new Foo; > echo serialize( $foo ); > // end of script > // __sleep() is called, but never __wakeup() > > $string = '<manually created serialized representation of object>'; > $foo = unserialize( $string ); > // end of script > // __wakeup() is called, but never __sleep() > >> And what you're saying is that the destructor (__sleep()) is called >> after a constructor (__construct(), __clone() or __wakeup()). > > I said the exact opposite: __sleep() is called *before* the > corresponding __wakeup(). > I know you did. And I said __sleep() is called after the constructor. It can also be called after __wakeup(), i.e. if an unserialized object is serialized again. > And look what the PHP manual has to say (emphasis mine): > > <http://de2.php.net/manual/en/language.oop5.magic.php#object.wakeup>: > "Conversely, unserialize() checks for the presence of a function with > the magic name __wakeup(). If present, this function can *reconstruct* > any resources that the object may have." > > (So __wakeup() is meant to "reconstruct" something, thus clearly acting > as a constructor.) > OK, now - one of the members of the object is a reference to a database connection object. How are you going to set that in your __wakeup() call? Yes, I know what the PHP manual says. But it's also pretty obvious that those who wrote the manual are the same ones who created the language. Thanks, I'll go with recognized OO experts when discussing how OO works - not the PHP folks. > <http://de2.php.net/manual/en/class.serializable.php> > "Classes that implement this interface no longer support __sleep() and > __wakeup(). The method serialize is called whenever an instance needs to > be serialized. This does not invoke __destruct() or has any other side > effect unless programmed inside the method. When the data is > unserialized the class is known and the appropriate unserialize() method > is called as a *constructor* instead of calling __construct()." > > (Clearly, unserialize() replaces __wakeup(), and if unserialize() acts > as a constructor, then so does __wakeup() which it replaces.) > > Greetings, > Thomas > My statement stands for a database object with the unserialize() method. If either followed the OO rules for constructing an object, this would not be a problem. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-11 01:00 +0200 |
| Message-ID | <jm2e2o$8u9$1@news.albasani.net> |
| In reply to | #5447 |
Jerry Stuckle schrieb: [__sleep()] > It can also be called after __wakeup(), i.e. if an unserialized object > is serialized again. Yes, but that would start a new "sleep cycle". You have to go to sleep *before* you can wake up again. > OK, now - one of the members of the object is a reference to a database > connection object. How are you going to set that in your __wakeup() call? I would put all the objects referencing the database object along with the database object in a container object and serialize that. After unserializing, the objects will again reference the same database object. No need for __wakeup() here. Greetings, Thomas -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison! (Coluche)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 19:54 -0400 |
| Message-ID | <jm2h80$q43$3@dont-email.me> |
| In reply to | #5450 |
On 4/10/2012 7:00 PM, Thomas Mlynarczyk wrote: > Jerry Stuckle schrieb: > > [__sleep()] >> It can also be called after __wakeup(), i.e. if an unserialized object >> is serialized again. > > Yes, but that would start a new "sleep cycle". You have to go to sleep > *before* you can wake up again. > >> OK, now - one of the members of the object is a reference to a >> database connection object. How are you going to set that in your >> __wakeup() call? > > I would put all the objects referencing the database object along with > the database object in a container object and serialize that. After > unserializing, the objects will again reference the same database > object. No need for __wakeup() here. > > Greetings, > Thomas > No, because the database objects themselves will rely on external resources which are not serialized. You have the same problem as before. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-11 22:10 +0200 |
| Message-ID | <jm4of6$gbp$1@news.albasani.net> |
| In reply to | #5454 |
Jerry Stuckle schrieb:
> No, because the database objects themselves will rely on external
> resources which are not serialized. You have the same problem as before.
The external resource would be the actual database connection here.
Which the database object can easily re-acquire in its __wakeup()
method, like
class MyDatabase
{
public function __wakeup()
{
$this->pdo = new PDO( ... );
}
}
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-11 16:31 -0400 |
| Message-ID | <jm4po2$okk$2@dont-email.me> |
| In reply to | #5461 |
On 4/11/2012 4:10 PM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> No, because the database objects themselves will rely on external
>> resources which are not serialized. You have the same problem as before.
>
> The external resource would be the actual database connection here.
> Which the database object can easily re-acquire in its __wakeup()
> method, like
>
> class MyDatabase
> {
> public function __wakeup()
> {
> $this->pdo = new PDO( ... );
> }
> }
>
> Greetings,
> Thomas
>
Which connection? Which database? Specifying the data here makes the
class less reusable.
And what if you want to use an existing PDO object?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-11 22:40 +0200 |
| Message-ID | <jm4q84$j6t$1@news.albasani.net> |
| In reply to | #5465 |
Jerry Stuckle schrieb:
>> class MyDatabase
>> {
>> public function __wakeup()
>> {
>> $this->pdo = new PDO( ... );
>> }
>> }
>
> Which connection? Which database? Specifying the data here makes the
> class less reusable.
The connection parameters would be taken from some config file or they
would have been serialized along with the object.
> And what if you want to use an existing PDO object?
MyDatabaseFactory::getConnectionObject( $config )
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-12 00:02 -0400 |
| Message-ID | <jm5k43$tss$1@dont-email.me> |
| In reply to | #5466 |
On 4/11/2012 4:40 PM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>>> class MyDatabase
>>> {
>>> public function __wakeup()
>>> {
>>> $this->pdo = new PDO( ... );
>>> }
>>> }
>>
>> Which connection? Which database? Specifying the data here makes the
>> class less reusable.
>
> The connection parameters would be taken from some config file or they
> would have been serialized along with the object.
>
OK, that part would work.
>> And what if you want to use an existing PDO object?
>
> MyDatabaseFactory::getConnectionObject( $config )
>
> Greetings,
> Thomas
>
You have 5 different connections to the database. Which one is the
correct one to use?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | "M. Strobel" <sorry_no_mail_here@nowhere.dee> |
|---|---|
| Date | 2012-04-12 12:00 +0200 |
| Message-ID | <9unneaFpiaU1@mid.uni-berlin.de> |
| In reply to | #5472 |
Am 12.04.2012 06:02, schrieb Jerry Stuckle:
> On 4/11/2012 4:40 PM, Thomas Mlynarczyk wrote:
>> Jerry Stuckle schrieb:
>>
>>>> class MyDatabase
>>>> {
>>>> public function __wakeup()
>>>> {
>>>> $this->pdo = new PDO( ... );
>>>> }
>>>> }
>>>
>>> Which connection? Which database? Specifying the data here makes the
>>> class less reusable.
>>
>> The connection parameters would be taken from some config file or they
>> would have been serialized along with the object.
>>
>
> OK, that part would work.
>
>>> And what if you want to use an existing PDO object?
>>
>> MyDatabaseFactory::getConnectionObject( $config )
>>
>> Greetings,
>> Thomas
>>
>
> You have 5 different connections to the database. Which one is the correct one to use?
>
Follow the same logic you used in the first place.
Anyway, I vote for a streamlined init code executed at every HTTP request, this
matches the nature of the HTTP protocol. I can't see why server name and protocol,
client IP and some session flags would not do it.
For the biggest requirements an application server would be a match.
/Str.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-12 07:45 -0400 |
| Message-ID | <jm6f91$m9q$1@dont-email.me> |
| In reply to | #5478 |
On 4/12/2012 6:00 AM, M. Strobel wrote:
> Am 12.04.2012 06:02, schrieb Jerry Stuckle:
>> On 4/11/2012 4:40 PM, Thomas Mlynarczyk wrote:
>>> Jerry Stuckle schrieb:
>>>
>>>>> class MyDatabase
>>>>> {
>>>>> public function __wakeup()
>>>>> {
>>>>> $this->pdo = new PDO( ... );
>>>>> }
>>>>> }
>>>>
>>>> Which connection? Which database? Specifying the data here makes the
>>>> class less reusable.
>>>
>>> The connection parameters would be taken from some config file or they
>>> would have been serialized along with the object.
>>>
>>
>> OK, that part would work.
>>
>>>> And what if you want to use an existing PDO object?
>>>
>>> MyDatabaseFactory::getConnectionObject( $config )
>>>
>>> Greetings,
>>> Thomas
>>>
>>
>> You have 5 different connections to the database. Which one is the correct one to use?
>>
>
> Follow the same logic you used in the first place.
>
And how do you do that? In the first place you pass the database object
you wish to use in the constructor.
> Anyway, I vote for a streamlined init code executed at every HTTP request, this
> matches the nature of the HTTP protocol. I can't see why server name and protocol,
> client IP and some session flags would not do it.
>
What do those have to do with it? Database connection doesn't depend on
the client IP, for instance.
> For the biggest requirements an application server would be a match.
>
> /Str.
And how would that help?
These things are quite easy in true OO languages - and quite often done
when doing transactional programming (like web pages are). But they
can't be done the way PHP implements it.
Just another case of how PHP screws things up.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.php
csiph-web