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 | 20 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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 08:04 -0400 |
| Message-ID | <jm17l8$ngo$1@dont-email.me> |
| In reply to | #5403 |
On 4/10/2012 7:44 AM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> In OO terminology, the correct term is "constructor". I'm not familiar
>> with Python, so I can't say what Python calls it. But the name is not
>> as important as the job.
>
> True. But one still has to keep in mind that the constructor is not
> constructing the object, but initializing it.
>
It does more than that. The system allocates memory for the object.
The constructor parcels out that memory into the appropriate pieces then
initializes those pieces. In truth, it does "construct" the object.
>> Initialization is NEVER harmful if it is done properly. That's the
>> whole purpose of initialization!. wakeup() is NOT a constructor - any
>> more than sleep() is a destructor.
>
> You would have to take extra measures to prevent re-initializing an
> already initialized object. Your constructor would need to detect what
> type of initialization is required (freshly created by `new`, cloned or
> unserialized). While certainly possible, this would be cumbersome.
> Different magic initializers are clearly the better way to go.
>
A serialized object is not an object. By definition, an object has both
state (properties) and behavior (methods operating on those properties).
A serialized object has only state - it is not an object.
True OO languages handle this quite well. But PHP can't seem to figure
that out. But then there are so many ways PHP is lacking.
>> wakeup() is not a constructor. If you consider it a constructor, then
>> you must also consider sleep() to be a destructor - in which case it
>> would be illegal to call the destructor after calling sleep().
>
> __wakeup() is an initializer, just like __construct() and __clone(). And
> __sleep() is still not a destructor -- see my earlier post.
>
__construct() and __clone() are constructors - a term specifically used
in OO terminology ("initializer" is not). Changing their name does not
change the facts.
>> It is the opposite of wakeup() - just like __construct() is the
>> opposite of __destruct(). You can't have it both ways.
>
> I think we do agree that __sleep() is not a destructor. And maybe we can
> agree that __construct(), __clone() and __wakeup() all perform
> initialization tasks and thus could be all called "initializers".
>
> Greetings,
> Thomas
>
>
I agree that __construct() and __clone() are constructors. There is no
"initializer" in OO terminology. Only "constructor".
--
==================
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 17:37 +0200 |
| Message-ID | <jm1k3o$d7j$1@news.albasani.net> |
| In reply to | #5406 |
Jerry Stuckle schrieb:
> But then there are so many ways PHP is lacking.
Finally a sentence I completely agree with ;-)
> __construct() and __clone() are constructors - a term specifically used
> in OO terminology ("initializer" is not). Changing their name does not
> change the facts.
True. And I am aware that "initializer" is not official terminology. I
used the word merely to better illustrate the purpose of those magic
methods.
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 12:19 -0400 |
| Message-ID | <jm1mit$hqm$2@dont-email.me> |
| In reply to | #5418 |
On 4/10/2012 11:37 AM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> But then there are so many ways PHP is lacking.
>
> Finally a sentence I completely agree with ;-)
>
>> __construct() and __clone() are constructors - a term specifically
>> used in OO terminology ("initializer" is not). Changing their name
>> does not change the facts.
>
> True. And I am aware that "initializer" is not official terminology. I
> used the word merely to better illustrate the purpose of those magic
> methods.
>
> Greetings,
> Thomas
>
But if you want to call it object oriented, you need to be using the
correct terminology. Here constructor and destructor have specific
meanings. Yes, one of the purposes (the main, many would argue,
including myself) is to initialize the object. But the term used is
constructor.
For instance, in other languages, part of the constructor's job might be
to dynamically allocate memory. That memory is not part of the original
memory allocated by new(), but it is part of the object. It is truly
"constructing" something, not just initializing it.
--
==================
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:44 +0200 |
| Message-ID | <jm1o0v$mpf$1@news.albasani.net> |
| In reply to | #5424 |
Jerry Stuckle schrieb: > But if you want to call it object oriented, you need to be using the > correct terminology. Here constructor and destructor have specific > meanings. Yes, one of the purposes (the main, many would argue, > including myself) is to initialize the object. But the term used is > constructor. My using of the word "initializer" was merely meant to be illustrative with respect to the purpose of __construct(), __clone() and __wakeup() in PHP. > For instance, in other languages, part of the constructor's job might be > to dynamically allocate memory. That memory is not part of the original > memory allocated by new(), but it is part of the object. It is truly > "constructing" something, not just initializing it. You are right, of course. I was considering only PHP. 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:23 -0400 |
| Message-ID | <jm28c4$686$2@dont-email.me> |
| In reply to | #5428 |
On 4/10/2012 12:44 PM, Thomas Mlynarczyk wrote: > Jerry Stuckle schrieb: > >> But if you want to call it object oriented, you need to be using the >> correct terminology. Here constructor and destructor have specific >> meanings. Yes, one of the purposes (the main, many would argue, >> including myself) is to initialize the object. But the term used is >> constructor. > > My using of the word "initializer" was merely meant to be illustrative > with respect to the purpose of __construct(), __clone() and __wakeup() > in PHP. > >> For instance, in other languages, part of the constructor's job might >> be to dynamically allocate memory. That memory is not part of the >> original memory allocated by new(), but it is part of the object. It >> is truly "constructing" something, not just initializing it. > > You are right, of course. I was considering only PHP. > > Greetings, > Thomas > But OO is language-insensitive. OO only defines a methodology, and the requirements to implement that methodology. It does not define *how* the methodology is implemented. That's up to the language. I see PHP is trying to become more OO. However, due to the poor "design" it has suffered from the start, there are a lot of things holding it back. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Scott Johnson <noonehome@chalupasworld.com> |
|---|---|
| Date | 2012-04-09 11:50 -0700 |
| Message-ID | <jlvb2i$6t4$1@dont-email.me> |
| In reply to | #5382 |
On 4/9/2012 11:04 AM, Thomas Mlynarczyk wrote: > > Serialization creates a kind of "frozen" copy of an object. The original > object continues to exist and its destructor is called as expected. > Later, the "frozen" copy is "warmed up" and can pretend to be the > original object, but it is not the same object. The __sleep() and > __wakeup() methods simply assist with the freezing and warming up and > have nothing to do with the copying. I am not even near to being a voice for OOP in php but something ran through my mind when i read this. I use serialize to save form data from time to time into a DB. Easier then having to have a separate column for each field (with obvious query drawbacks - but I digress) What would be the reason to serialize an object other then to save it for later use, and at the time I can't really come up with a reason for that in my mind (lack of experience in this area I suppose) Now if you are saving it for later use then the original object would no longer exist and the external resources as Jerry explained would no longer be available if not for the constructor. I am not sure if I am even making sense, this just kind of went across my mind as i was reading. Scotty
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-09 23:03 +0200 |
| Message-ID | <jlvis4$og6$1@news.albasani.net> |
| In reply to | #5384 |
Scott Johnson schrieb:
> What would be the reason to serialize an object other then to save it
> for later use, and at the time I can't really come up with a reason for
> that in my mind (lack of experience in this area I suppose)
True, this seems to be the most common use case: Make the object persist
between different HTTP requests.
> Now if you are saving it for later use then the original object would no
> longer exist and the external resources as Jerry explained would no
> longer be available if not for the constructor.
The point is that an unserialized object would usually be in a different
state than a "fresh" object created using the `new` operator and thus
require different initialization tasks to be performed. That's why
different magic methods exist:
__construct(): Object is "fresh", created using `new`
__clone(): Object was copied from another object
__wakeup(): Object was unserialized
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
[toc] | [prev] | [next] | [standalone]
| From | Scott Johnson <noonehome@chalupasworld.com> |
|---|---|
| Date | 2012-04-09 15:27 -0700 |
| Message-ID | <jlvnos$jcs$1@dont-email.me> |
| In reply to | #5389 |
On 4/9/2012 2:03 PM, Thomas Mlynarczyk wrote: > Scott Johnson schrieb: > >> What would be the reason to serialize an object other then to save it >> for later use, and at the time I can't really come up with a reason >> for that in my mind (lack of experience in this area I suppose) > > True, this seems to be the most common use case: Make the object persist > between different HTTP requests. > >> Now if you are saving it for later use then the original object would >> no longer exist and the external resources as Jerry explained would no >> longer be available if not for the constructor. > > The point is that an unserialized object would usually be in a different > state than a "fresh" object created using the `new` operator and thus > require different initialization tasks to be performed. That's why > different magic methods exist: > > __construct(): Object is "fresh", created using `new` > __clone(): Object was copied from another object > __wakeup(): Object was unserialized > > Greetings, > Thomas > OK I see. I had not even thought about the need for creating the object from either new or from a copied version. Thanks for squeezing my brain. Scotty
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-09 20:25 -0400 |
| Message-ID | <jlvuld$qm4$2@dont-email.me> |
| In reply to | #5391 |
On 4/9/2012 6:27 PM, Scott Johnson wrote: > On 4/9/2012 2:03 PM, Thomas Mlynarczyk wrote: >> Scott Johnson schrieb: >> >>> What would be the reason to serialize an object other then to save it >>> for later use, and at the time I can't really come up with a reason >>> for that in my mind (lack of experience in this area I suppose) >> >> True, this seems to be the most common use case: Make the object persist >> between different HTTP requests. >> Scotty, please see my reply to Thomas. Only the state persists between requests. The behavior doesn't. This is a huge difference. >>> Now if you are saving it for later use then the original object would >>> no longer exist and the external resources as Jerry explained would no >>> longer be available if not for the constructor. >> >> The point is that an unserialized object would usually be in a different >> state than a "fresh" object created using the `new` operator and thus >> require different initialization tasks to be performed. That's why >> different magic methods exist: >> >> __construct(): Object is "fresh", created using `new` >> __clone(): Object was copied from another object >> __wakeup(): Object was unserialized >> >> Greetings, >> Thomas >> > OK I see. > > I had not even thought about the need for creating the object from > either new or from a copied version. > Actually, both are quite common in true OO languages such as C++, Java or Smalltalk. > Thanks for squeezing my brain. > > Scotty -- ================== 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 12:48 +0200 |
| Message-ID | <jm1365$9mu$1@news.albasani.net> |
| In reply to | #5395 |
Jerry Stuckle schrieb: >>> True, this seems to be the most common use case: Make the object persist >>> between different HTTP requests. > > Scotty, please see my reply to Thomas. Only the state persists between > requests. The behavior doesn't. This is a huge difference. Behaviour persists as long as you don't modify your script. The behaviour is defined in the class and each instance uses that very same behaviour. 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:06 -0400 |
| Message-ID | <jm17o8$ngo$2@dont-email.me> |
| In reply to | #5401 |
On 4/10/2012 6:48 AM, Thomas Mlynarczyk wrote: > Jerry Stuckle schrieb: >>>> True, this seems to be the most common use case: Make the object >>>> persist >>>> between different HTTP requests. >> >> Scotty, please see my reply to Thomas. Only the state persists between >> requests. The behavior doesn't. This is a huge difference. > > Behaviour persists as long as you don't modify your script. The > behaviour is defined in the class and each instance uses that very same > behaviour. > > Greetings, > Thomas > No, a serialized object (or an object stored in a database) has only state. The behavior doesn't exist until you create a new object from that state. A huge difference - and one real OO languages understand and handle. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Leonardo Azpurua" <leonardo@exmvps.org> |
|---|---|
| Date | 2012-04-10 07:52 -0430 |
| Message-ID | <jm18lj$tbo$1@dont-email.me> |
| In reply to | #5407 |
"Jerry Stuckle" <jstucklex@attglobal.net> escribió en el mensaje news:jm17o8$ngo$2@dont-email.me... > On 4/10/2012 6:48 AM, Thomas Mlynarczyk wrote: >> Jerry Stuckle schrieb: >>>>> True, this seems to be the most common use case: Make the object >>>>> persist >>>>> between different HTTP requests. >>> >>> Scotty, please see my reply to Thomas. Only the state persists between >>> requests. The behavior doesn't. This is a huge difference. >> >> Behaviour persists as long as you don't modify your script. The >> behaviour is defined in the class and each instance uses that very same >> behaviour. >> >> Greetings, >> Thomas >> > > No, a serialized object (or an object stored in a database) has only > state. The behavior doesn't exist until you create a new object from that > state. > > A huge difference - and one real OO languages understand and handle. Hi, Behaviour is defined by the code within the class. State is (shallowly) preserved by serialization. It is the environment (a third factor that has to be taken into account) what *may* be lost. __wakeup should inspect the environment and ensure that all requirements are met. And, by the definition, __wakeup is a special case of constructor. There is no need to get dogmatic about terms. --
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 12:20 -0400 |
| Message-ID | <jm1mku$hqm$3@dont-email.me> |
| In reply to | #5409 |
On 4/10/2012 8:22 AM, Leonardo Azpurua wrote: > "Jerry Stuckle"<jstucklex@attglobal.net> escribió en el mensaje > news:jm17o8$ngo$2@dont-email.me... >> On 4/10/2012 6:48 AM, Thomas Mlynarczyk wrote: >>> Jerry Stuckle schrieb: >>>>>> True, this seems to be the most common use case: Make the object >>>>>> persist >>>>>> between different HTTP requests. >>>> >>>> Scotty, please see my reply to Thomas. Only the state persists between >>>> requests. The behavior doesn't. This is a huge difference. >>> >>> Behaviour persists as long as you don't modify your script. The >>> behaviour is defined in the class and each instance uses that very same >>> behaviour. >>> >>> Greetings, >>> Thomas >>> >> >> No, a serialized object (or an object stored in a database) has only >> state. The behavior doesn't exist until you create a new object from that >> state. >> >> A huge difference - and one real OO languages understand and handle. > > Hi, > > Behaviour is defined by the code within the class. > > State is (shallowly) preserved by serialization. > > It is the environment (a third factor that has to be taken into account) > what *may* be lost. > > __wakeup should inspect the environment and ensure that all requirements are > met. > > And, by the definition, __wakeup is a special case of constructor. > > There is no need to get dogmatic about terms. > > -- > > If you want to call __wakeup() a constructor, then you need to call __sleep() a destructor. You can't have it both ways. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Leonardo Azpurua" <leonardo@exmvps.org> |
|---|---|
| Date | 2012-04-10 12:03 -0430 |
| Message-ID | <jm1ncm$nlj$1@dont-email.me> |
| In reply to | #5425 |
"Jerry Stuckle" <jstucklex@attglobal.net> escribió en el mensaje news:jm1mku$hqm$3@dont-email.me... > > If you want to call __wakeup() a constructor, then you need to call > __sleep() a destructor. You can't have it both ways. Hi, That would be if I had an obssesive love for symmetry, which is not the case :-) I don't care much about terms. PHP lacks polymorphic constructors (a limitation which, after several years using the best available OO practices with VB6, I can perfectly cope with). So, if you need an alternate way to fill an object's data members, then __wakeup seems to come in very handy. With __construct(<args>), you initialize -i.e. fill data members and create the appropriate internal states- the object from args. With __wakeup you know you have your top level data members initialized (from a previous state), so you have to rebuild the apropriate internal states. I have no problem at all with that. It may not be symmetric (but, again, who cares?), but it is precisely documented and it works as expected (I guess, since I have had no experience at all with PHP serialization). --
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 17:28 -0400 |
| Message-ID | <jm28mf$8ml$1@dont-email.me> |
| In reply to | #5426 |
On 4/10/2012 12:33 PM, Leonardo Azpurua wrote: > "Jerry Stuckle"<jstucklex@attglobal.net> escribió en el mensaje > news:jm1mku$hqm$3@dont-email.me... >> >> If you want to call __wakeup() a constructor, then you need to call >> __sleep() a destructor. You can't have it both ways. > > Hi, > > That would be if I had an obssesive love for symmetry, which is not the case > :-) > > I don't care much about terms. > > PHP lacks polymorphic constructors (a limitation which, after several years > using the best available OO practices with VB6, I can perfectly cope with). > So, if you need an alternate way to fill an object's data members, then > __wakeup seems to come in very handy. > > With __construct(<args>), you initialize -i.e. fill data members and create > the appropriate internal states- the object from args. > > With __wakeup you know you have your top level data members initialized > (from a previous state), so you have to rebuild the apropriate internal > states. > > I have no problem at all with that. It may not be symmetric (but, again, who > cares?), but it is precisely documented and it works as expected (I guess, > since I have had no experience at all with PHP serialization). > > -- > > Because it's a violation of OO concepts? It's caused me problems more than once. I no longer even try to store objects in the session. It's hopeless. For instance - what if one of the things your object needs is a database connection? And what if you have several objects using that same connection? There is no way to pass an existing database connection to __wakeup(). You either have to use a global variable, restricting variable names in the rest of your code and limiting flexibility, or create a new connection in the __wakeup() call or remember to call another method to set the database connection after unserializing the object. None are good answers - but all could be easily handled with proper use of constructors. -- ================== 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 00:13 +0200 |
| Message-ID | <jm2bba$3no$1@news.albasani.net> |
| In reply to | #5445 |
Jerry Stuckle schrieb: > I no longer even try to store objects in the session. It's hopeless. Why? I never had any real problems with storing objects in the session. Or maybe I was just lucky ;-) > For instance - what if one of the things your object needs is a database > connection? And what if you have several objects using that same > connection? There is no way to pass an existing database connection to > __wakeup(). You either have to use a global variable, restricting > variable names in the rest of your code and limiting flexibility, or > create a new connection in the __wakeup() call or remember to call > another method to set the database connection after unserializing the > object. MyDatabaseSingleton::getInstance() ? > None are good answers - but all could be easily handled with proper use > of constructors. And how would a "proper use of constructors" solve the above problem? Even if unserialize() called __construct(), you would have no chance to pass any arguments to the constructor. 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:53 -0400 |
| Message-ID | <jm2h5v$q43$2@dont-email.me> |
| In reply to | #5449 |
On 4/10/2012 6:13 PM, Thomas Mlynarczyk wrote: > Jerry Stuckle schrieb: > >> I no longer even try to store objects in the session. It's hopeless. > > Why? I never had any real problems with storing objects in the session. > Or maybe I was just lucky ;-) > >> For instance - what if one of the things your object needs is a >> database connection? And what if you have several objects using that >> same connection? There is no way to pass an existing database >> connection to __wakeup(). You either have to use a global variable, >> restricting variable names in the rest of your code and limiting >> flexibility, or create a new connection in the __wakeup() call or >> remember to call another method to set the database connection after >> unserializing the object. > > MyDatabaseSingleton::getInstance() ? > What if you don't want a singleton? Many times I've had the need to access different databases, for instance. You are limiting the versatility of the class. >> None are good answers - but all could be easily handled with proper >> use of constructors. > > And how would a "proper use of constructors" solve the above problem? > Even if unserialize() called __construct(), you would have no chance to > pass any arguments to the constructor. > > Greetings, > Thomas > By definition you can pass arguments to the constructor. That's why unserialize() is not a good implementation. -- ================== 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:17 +0200 |
| Message-ID | <jm4otm$h3i$1@news.albasani.net> |
| In reply to | #5453 |
Jerry Stuckle schrieb: >> MyDatabaseSingleton::getInstance() ? > > What if you don't want a singleton? Many times I've had the need to > access different databases, for instance. You are limiting the > versatility of the class. MyDatabase::getConnection( $id ) > By definition you can pass arguments to the constructor. That's why > unserialize() is not a good implementation. But how would you pass any constructor arguments to an unserialize() function anyway? You cannot be sure what the string to be unserialized really contains, so how would you know which constructor arguments to pass? This could be a job for __set_state(): unserialize() then wouldn't create objects, but simply call the __set_state() method on the class in question, passing the unserialized state information and leave it to that method to reconstruct the actual object. But this does not seem to be the way PHP works. 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:30 -0400 |
| Message-ID | <jm4pl9$okk$1@dont-email.me> |
| In reply to | #5462 |
On 4/11/2012 4:17 PM, Thomas Mlynarczyk wrote: > Jerry Stuckle schrieb: > >>> MyDatabaseSingleton::getInstance() ? >> >> What if you don't want a singleton? Many times I've had the need to >> access different databases, for instance. You are limiting the >> versatility of the class. > > MyDatabase::getConnection( $id ) > Which once again doesn't reuse an existing connection, nor does it specify what connection is being used. Which host? Which database? If it's defined within the MyDatabase class, you're restricted to that one connection/database. If it's defined in the serialized class, you've limited the usefulness of that class. All is resolved by passing a database object in the constructor of the class. You are using the object the program wants - not one predefined by the class itself. > > By definition you can pass arguments to the constructor. That's why >> unserialize() is not a good implementation. > > But how would you pass any constructor arguments to an unserialize() > function anyway? You cannot be sure what the string to be unserialized > really contains, so how would you know which constructor arguments to > pass? This could be a job for __set_state(): unserialize() then wouldn't > create objects, but simply call the __set_state() method on the class in > question, passing the unserialized state information and leave it to > that method to reconstruct the actual object. But this does not seem to > be the way PHP works. > > Greetings, > Thomas > Which is a big problem with unserialize(). Other languages handle it quite well by having different constructors available. For instance, there could be a constructor which takes the serialized object and an array (or variable arg list) which would unserialize the data and use the additional arguments. But problems like this make almost any but the simplest objects useless for any type of serialization. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-09 20:22 -0400 |
| Message-ID | <jlvugq$qm4$1@dont-email.me> |
| In reply to | #5389 |
On 4/9/2012 5:03 PM, Thomas Mlynarczyk wrote: > Scott Johnson schrieb: > >> What would be the reason to serialize an object other then to save it >> for later use, and at the time I can't really come up with a reason >> for that in my mind (lack of experience in this area I suppose) > > True, this seems to be the most common use case: Make the object persist > between different HTTP requests. > 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. Data may be saved between requests (i.e. $_SESSION in PHP, a database, etc.). But these are not objects. 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. >> Now if you are saving it for later use then the original object would >> no longer exist and the external resources as Jerry explained would no >> longer be available if not for the constructor. > > The point is that an unserialized object would usually be in a different > state than a "fresh" object created using the `new` operator and thus > require different initialization tasks to be performed. That's why > different magic methods exist: > Which is why objects can never persist across transactions. A new object requires a constructor, under OO rules. > __construct(): Object is "fresh", created using `new` > __clone(): Object was copied from another object > __wakeup(): Object was unserialized > > Greetings, > Thomas > Both __construct() and __clone() are types of constructors. __wakeup() is not (unless you consider sleep() to be a destructor - see above). -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.php
csiph-web