Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #12889 > unrolled thread
| Started by | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| First post | 2014-02-23 18:03 +0100 |
| Last post | 2014-02-24 14:28 +0100 |
| Articles | 20 on this page of 84 — 8 participants |
Back to article view | Back to comp.lang.php
Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-23 18:03 +0100
Re: Operator precedence GS <nomail@nospam.org.invalid> - 2014-02-23 19:42 +0000
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-23 21:23 +0100
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-23 16:34 -0500
Re: Operator precedence Richard Damon <Richard@Damon-Family.org> - 2014-02-23 18:36 -0500
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-23 21:09 -0500
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-24 04:49 +0000
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-24 12:56 +0100
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-24 17:38 +0100
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-24 21:25 +0000
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 00:38 +0100
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 01:07 +0100
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 01:37 +0100
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 02:12 +0100
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 03:29 +0100
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 19:41 +0100
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 19:55 +0100
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 21:36 +0100
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 03:08 +0000
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 04:17 +0100
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 04:45 +0000
Re: Operator precedence GS <nomail@nospam.org.invalid> - 2014-02-25 21:45 +0000
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 07:00 -0500
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-24 18:11 +0100
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 14:27 -0500
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 01:25 +0100
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 20:40 -0500
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-24 21:23 +0000
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 16:45 -0500
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 04:32 +0000
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 23:47 -0500
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 16:56 +0000
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 13:59 -0500
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 20:19 +0100
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 20:43 +0100
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:02 -0500
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:01 -0500
Object constructors/destructors (was: Operator precedence) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 22:19 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:32 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 22:55 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 17:01 -0500
Re: Object constructors/destructors Adam Harvey <usenet@adamharvey.name> - 2014-02-25 23:22 +0000
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 21:10 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 21:10 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 16:01 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 22:59 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 17:19 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 23:39 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 22:30 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-27 18:28 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 16:09 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-28 14:52 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-28 09:08 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-28 16:52 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-28 11:03 -0500
Re: Object constructors/destructors Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-27 01:00 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 22:39 -0500
Re: Object constructors/destructors Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-27 18:29 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 16:14 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 00:18 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 21:08 -0500
Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-02-26 07:50 -0500
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 08:44 -0500
Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-02-26 23:49 -0500
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 08:25 -0500
Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-03-01 12:56 -0500
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-01 14:22 -0500
Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-03-02 14:28 -0500
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-02 15:42 -0500
Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-03-02 17:14 -0500
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-02 17:48 -0500
Re: Object constructors/destructors Tim Streater <timstreater@greenbee.net> - 2014-03-02 23:05 +0000
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 21:08 +0000
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 22:29 +0100
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 23:15 +0000
Re: Operator precedence Richard Damon <Richard@Damon-Family.org> - 2014-02-24 22:41 -0500
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 23:59 -0500
Re: Operator precedence Richard Damon <Richard@Damon-Family.org> - 2014-03-01 13:39 -0500
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-01 14:29 -0500
Re: Operator precedence Richard Damon <Richard@Damon-Family.org> - 2014-03-02 15:22 -0500
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-02 15:49 -0500
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 19:15 +0100
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-23 20:56 +0000
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-24 14:28 +0100
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-25 17:01 -0500 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <lej3sh$gmp$1@dont-email.me> |
| In reply to | #12982 |
On 2/25/2014 4:55 PM, Christoph Michael Becker wrote: > Jerry Stuckle wrote: > >> On 2/25/2014 4:19 PM, Christoph Michael Becker wrote: >>> Jerry Stuckle wrote: >>> >>>> On 2/25/2014 2:19 PM, Christoph Michael Becker wrote: >>>>> Jerry Stuckle wrote: >>>>> >>>>>> I have my own problems with PHP - for instance, it is entirely >>>>>> possible >>>>>> to create an object without calling a constructor - a violation of OO >>>>>> principles. But I work around it. >>>>> >>>>> How is it possible to create an object without its constructor (if >>>>> defined) being called? >>>>> >>>> >>>> Load the object from the $_SESSION. The constructor will not be called. >>>> >>>> However, the constructor is called when the original object was created, >>>> and the destructor called when the original object goes out of scope. >>>> The destructor is also called when the object loaded from the $_SESSION >>>> goes out of scope. >>>> >>>> The result is one constructor call and two destructor calls. A >>>> violation of OO principles. >>> >>> Um, I'm not sure whether this is a violation of OOP principles. Storing >>> an object in the session requires serialization of the object, what is >>> somewhat comparable to cloning an object. So actually, you're not >>> working with the *same* object. >>> >>> Anyway, you can work around these issues by using the magic methods >>> __sleep() and __wakeup(), as you probably know. :) >>> >> >> Yes, it is a violation. When the script starts, the object is >> serialized in the $_SESSION. But it does not exist in the script. >> Creating it requires a constructor call. > > It requires the object to be created in memory somehow, but the defined > constructor function is not called in this case. > Which is a violation of OO principles. >> OO principles require exactly >> one constructor call and one destructor call for every object created. >> Note these may be explicit or implicit, and the functions may be noops, >> but the calls must still be made. > > When you're cloning an object, its constructor will not be called either. > It is in every other language. For instance, in Java, clone() acts like a copy constructor. C++ doesn't have a clone() method, but it does have a copy constructor. >> That is not the case here; you get >> one constructor call and two destructor calls. > > I firmly believe that it wouldn't make sense to call a (user-defined) > constructor when unserializing or cloning an object. A constructor > usually serves to initialize an object -- what already had happened in > both cases. > It makes perfect sense. Not everything is necessarily valid in the new object. For instance, a logging object may require opening the log file. There are many instances where a resource is no longer available and needs to be recreated. PHP's method is only a shallow copy. Copy constructors and the like were created when a deep copy is required (quite often in other languages). >> I know of no other OO language which would allow this. > > Others may. > None that I know of. Please name one. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Adam Harvey <usenet@adamharvey.name> |
|---|---|
| Date | 2014-02-25 23:22 +0000 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <lej8ji$e3a$1@dont-email.me> |
| In reply to | #12983 |
On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote: > On 2/25/2014 4:55 PM, Christoph Michael Becker wrote: >> I firmly believe that it wouldn't make sense to call a (user-defined) >> constructor when unserializing or cloning an object. A constructor >> usually serves to initialize an object -- what already had happened in >> both cases. >> >> > It makes perfect sense. Not everything is necessarily valid in the new > object. For instance, a logging object may require opening the log > file. There are many instances where a resource is no longer available > and needs to be recreated. Indeed, which is why PHP provides the Serializable interface (and, for BC reasons, also __sleep and __wakeup) to allow those sorts of reinitialisation tasks. I agree with Christoph: since the object is already instantiated, it doesn't logically make sense to call the constructor once again. >> Jerry Stuckle wrote: >>> I know of no other OO language which would allow this. >> >> Others may. >> >> > None that I know of. Please name one. Python's pickle operates the same way: http://docs.python.org/2/library/pickle.html#object.__getinitargs__ Providing a way to instantiate objects without calling the constructor does have valid uses (mostly for testing), which is why PHP 5.4 and later versions also provide a way to do so via reflection (avoiding the unserialize() hack): http://php.net/reflectionclass.newinstancewithoutconstructor Adam
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-25 21:10 -0500 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <lejife$v6d$2@dont-email.me> |
| In reply to | #12988 |
On 2/25/2014 6:22 PM, Adam Harvey wrote: > On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote: >> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote: >>> I firmly believe that it wouldn't make sense to call a (user-defined) >>> constructor when unserializing or cloning an object. A constructor >>> usually serves to initialize an object -- what already had happened in >>> both cases. >>> >>> >> It makes perfect sense. Not everything is necessarily valid in the new >> object. For instance, a logging object may require opening the log >> file. There are many instances where a resource is no longer available >> and needs to be recreated. > > Indeed, which is why PHP provides the Serializable interface (and, for BC > reasons, also __sleep and __wakeup) to allow those sorts of > reinitialisation tasks. > > I agree with Christoph: since the object is already instantiated, it > doesn't logically make sense to call the constructor once again. > But the object is NOT instantiated. It was at one time, then destroyed. When the new script starts, there is no object in existence. >>> Jerry Stuckle wrote: >>>> I know of no other OO language which would allow this. >>> >>> Others may. >>> >>> >> None that I know of. Please name one. > > Python's pickle operates the same way: > http://docs.python.org/2/library/pickle.html#object.__getinitargs__ > > Providing a way to instantiate objects without calling the constructor > does have valid uses (mostly for testing), which is why PHP 5.4 and later > versions also provide a way to do so via reflection (avoiding the > unserialize() hack): > http://php.net/reflectionclass.newinstancewithoutconstructor > > Adam > Not knowing Python, I can't say. But if it is a true object, then they are also violating OO principles. OO demands creation of a new object requires a constructor call. Period. If you think otherwise, I suggest you learn more about how OO is supposed to work. PHP is not a good example. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-26 21:10 +0100 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <530e4a38$0$9520$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #12992 |
Jerry Stuckle wrote: > On 2/25/2014 6:22 PM, Adam Harvey wrote: >> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote: >>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote: >>>> I firmly believe that it wouldn't make sense to call a (user-defined) >>>> constructor when unserializing or cloning an object. A constructor >>>> usually serves to initialize an object -- what already had happened in >>>> both cases. >>>> >>>> >>> It makes perfect sense. Not everything is necessarily valid in the new >>> object. For instance, a logging object may require opening the log >>> file. There are many instances where a resource is no longer available >>> and needs to be recreated. >> >> Indeed, which is why PHP provides the Serializable interface (and, for BC >> reasons, also __sleep and __wakeup) to allow those sorts of >> reinitialisation tasks. >> >> I agree with Christoph: since the object is already instantiated, it >> doesn't logically make sense to call the constructor once again. >> > > But the object is NOT instantiated. It was at one time, then destroyed. > When the new script starts, there is no object in existence. > >>>> Jerry Stuckle wrote: >>>>> I know of no other OO language which would allow this. >>>> >>>> Others may. >>>> >>>> >>> None that I know of. Please name one. >> >> Python's pickle operates the same way: >> http://docs.python.org/2/library/pickle.html#object.__getinitargs__ >> >> Providing a way to instantiate objects without calling the constructor >> does have valid uses (mostly for testing), which is why PHP 5.4 and later >> versions also provide a way to do so via reflection (avoiding the >> unserialize() hack): >> http://php.net/reflectionclass.newinstancewithoutconstructor >> >> Adam >> > > Not knowing Python, I can't say. But if it is a true object, then they > are also violating OO principles. > > OO demands creation of a new object requires a constructor call. > Period. Do you understand, what's the purpose of a constructor? It is there to *initialize* an instance. If there is nothing to initialize, it is not strictly necessary to call any constructor. But anyway, unserializing an object is *not* creating a new object. Consider a class man. When a new object is instantiated the constructor is called to initialize the person with respective properties (e.g. age = 0). Later this man goes to sleep (serialize); after he wakes up (unserialize) the constructor is not called again, as this would reset the man to his initial properties, and surely after a good night of sleep one may feel younger, but the age has not been reset. > If you think otherwise, I suggest you learn more about how OO > is supposed to work. PHP is not a good example. I refrain from commenting this statement. -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-26 16:01 -0500 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <lelkn9$919$1@dont-email.me> |
| In reply to | #13003 |
On 2/26/2014 3:10 PM, Christoph Michael Becker wrote: > Jerry Stuckle wrote: > >> On 2/25/2014 6:22 PM, Adam Harvey wrote: >>> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote: >>>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote: >>>>> I firmly believe that it wouldn't make sense to call a (user-defined) >>>>> constructor when unserializing or cloning an object. A constructor >>>>> usually serves to initialize an object -- what already had happened in >>>>> both cases. >>>>> >>>>> >>>> It makes perfect sense. Not everything is necessarily valid in the new >>>> object. For instance, a logging object may require opening the log >>>> file. There are many instances where a resource is no longer available >>>> and needs to be recreated. >>> >>> Indeed, which is why PHP provides the Serializable interface (and, for BC >>> reasons, also __sleep and __wakeup) to allow those sorts of >>> reinitialisation tasks. >>> >>> I agree with Christoph: since the object is already instantiated, it >>> doesn't logically make sense to call the constructor once again. >>> >> >> But the object is NOT instantiated. It was at one time, then destroyed. >> When the new script starts, there is no object in existence. >> >>>>> Jerry Stuckle wrote: >>>>>> I know of no other OO language which would allow this. >>>>> >>>>> Others may. >>>>> >>>>> >>>> None that I know of. Please name one. >>> >>> Python's pickle operates the same way: >>> http://docs.python.org/2/library/pickle.html#object.__getinitargs__ >>> >>> Providing a way to instantiate objects without calling the constructor >>> does have valid uses (mostly for testing), which is why PHP 5.4 and later >>> versions also provide a way to do so via reflection (avoiding the >>> unserialize() hack): >>> http://php.net/reflectionclass.newinstancewithoutconstructor >>> >>> Adam >>> >> >> Not knowing Python, I can't say. But if it is a true object, then they >> are also violating OO principles. >> >> OO demands creation of a new object requires a constructor call. >> Period. > > Do you understand, what's the purpose of a constructor? It is there to > *initialize* an instance. If there is nothing to initialize, it is not > strictly necessary to call any constructor. > Yes, I understand the purpose of a constructor - it looks like much more than you do. > But anyway, unserializing an object is *not* creating a new object. > Consider a class man. When a new object is instantiated the constructor > is called to initialize the person with respective properties (e.g. age > = 0). Later this man goes to sleep (serialize); after he wakes up > (unserialize) the constructor is not called again, as this would reset > the man to his initial properties, and surely after a good night of > sleep one may feel younger, but the age has not been reset. > It is creating a new object. Before unserialize(), the object does not exist - only a bunch of data. And that data is NOT an object! You cannot call an object method on the data, for instance. It is no different than if the data were stored in a file and loaded in Java or C++, for instance. To create the object requires a call to a constructor. >> If you think otherwise, I suggest you learn more about how OO >> is supposed to work. PHP is not a good example. > > I refrain from commenting this statement. > If you think otherwise, I suggest you learn more about how OO is supposed to work. PHP is not a good example. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-26 22:59 +0100 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <530e63d3$0$9502$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #13004 |
Jerry Stuckle wrote: > On 2/26/2014 3:10 PM, Christoph Michael Becker wrote: >> Jerry Stuckle wrote: >> >>> On 2/25/2014 6:22 PM, Adam Harvey wrote: >>>> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote: >>>>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote: >>>>>> I firmly believe that it wouldn't make sense to call a (user-defined) >>>>>> constructor when unserializing or cloning an object. A constructor >>>>>> usually serves to initialize an object -- what already had >>>>>> happened in >>>>>> both cases. >>>>>> >>>>>> >>>>> It makes perfect sense. Not everything is necessarily valid in the >>>>> new >>>>> object. For instance, a logging object may require opening the log >>>>> file. There are many instances where a resource is no longer >>>>> available >>>>> and needs to be recreated. >>>> >>>> Indeed, which is why PHP provides the Serializable interface (and, >>>> for BC >>>> reasons, also __sleep and __wakeup) to allow those sorts of >>>> reinitialisation tasks. >>>> >>>> I agree with Christoph: since the object is already instantiated, it >>>> doesn't logically make sense to call the constructor once again. >>>> >>> >>> But the object is NOT instantiated. It was at one time, then destroyed. >>> When the new script starts, there is no object in existence. >>> >>>>>> Jerry Stuckle wrote: >>>>>>> I know of no other OO language which would allow this. >>>>>> >>>>>> Others may. >>>>>> >>>>>> >>>>> None that I know of. Please name one. >>>> >>>> Python's pickle operates the same way: >>>> http://docs.python.org/2/library/pickle.html#object.__getinitargs__ >>>> >>>> Providing a way to instantiate objects without calling the constructor >>>> does have valid uses (mostly for testing), which is why PHP 5.4 and >>>> later >>>> versions also provide a way to do so via reflection (avoiding the >>>> unserialize() hack): >>>> http://php.net/reflectionclass.newinstancewithoutconstructor >>>> >>>> Adam >>>> >>> >>> Not knowing Python, I can't say. But if it is a true object, then they >>> are also violating OO principles. >>> >>> OO demands creation of a new object requires a constructor call. >>> Period. >> >> Do you understand, what's the purpose of a constructor? It is there to >> *initialize* an instance. If there is nothing to initialize, it is not >> strictly necessary to call any constructor. >> > > Yes, I understand the purpose of a constructor - it looks like much more > than you do. > >> But anyway, unserializing an object is *not* creating a new object. >> Consider a class man. When a new object is instantiated the constructor >> is called to initialize the person with respective properties (e.g. age >> = 0). Later this man goes to sleep (serialize); after he wakes up >> (unserialize) the constructor is not called again, as this would reset >> the man to his initial properties, and surely after a good night of >> sleep one may feel younger, but the age has not been reset. >> > > It is creating a new object. Before unserialize(), the object does not > exist - only a bunch of data. And that data is NOT an object! You > cannot call an object method on the data, for instance. It is no > different than if the data were stored in a file and loaded in Java or > C++, for instance. To create the object requires a call to a constructor. If you really need to think this way, just take Serializable::serialize() resp. __sleep() as a destructor and Serializable::unserialize() resp. __wakeup() as a constructor. Actually, the documentation of the Serializable interface explaines it that way. >>> If you think otherwise, I suggest you learn more about how OO >>> is supposed to work. PHP is not a good example. >> >> I refrain from commenting this statement. >> > > If you think otherwise, I suggest you learn more about how OO is > supposed to work. PHP is not a good example. No comment. -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-26 17:19 -0500 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <lelp8j$5n8$1@dont-email.me> |
| In reply to | #13008 |
On 2/26/2014 4:59 PM, Christoph Michael Becker wrote: > Jerry Stuckle wrote: > >> On 2/26/2014 3:10 PM, Christoph Michael Becker wrote: >>> Jerry Stuckle wrote: >>> >>>> On 2/25/2014 6:22 PM, Adam Harvey wrote: >>>>> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote: >>>>>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote: >>>>>>> I firmly believe that it wouldn't make sense to call a (user-defined) >>>>>>> constructor when unserializing or cloning an object. A constructor >>>>>>> usually serves to initialize an object -- what already had >>>>>>> happened in >>>>>>> both cases. >>>>>>> >>>>>>> >>>>>> It makes perfect sense. Not everything is necessarily valid in the >>>>>> new >>>>>> object. For instance, a logging object may require opening the log >>>>>> file. There are many instances where a resource is no longer >>>>>> available >>>>>> and needs to be recreated. >>>>> >>>>> Indeed, which is why PHP provides the Serializable interface (and, >>>>> for BC >>>>> reasons, also __sleep and __wakeup) to allow those sorts of >>>>> reinitialisation tasks. >>>>> >>>>> I agree with Christoph: since the object is already instantiated, it >>>>> doesn't logically make sense to call the constructor once again. >>>>> >>>> >>>> But the object is NOT instantiated. It was at one time, then destroyed. >>>> When the new script starts, there is no object in existence. >>>> >>>>>>> Jerry Stuckle wrote: >>>>>>>> I know of no other OO language which would allow this. >>>>>>> >>>>>>> Others may. >>>>>>> >>>>>>> >>>>>> None that I know of. Please name one. >>>>> >>>>> Python's pickle operates the same way: >>>>> http://docs.python.org/2/library/pickle.html#object.__getinitargs__ >>>>> >>>>> Providing a way to instantiate objects without calling the constructor >>>>> does have valid uses (mostly for testing), which is why PHP 5.4 and >>>>> later >>>>> versions also provide a way to do so via reflection (avoiding the >>>>> unserialize() hack): >>>>> http://php.net/reflectionclass.newinstancewithoutconstructor >>>>> >>>>> Adam >>>>> >>>> >>>> Not knowing Python, I can't say. But if it is a true object, then they >>>> are also violating OO principles. >>>> >>>> OO demands creation of a new object requires a constructor call. >>>> Period. >>> >>> Do you understand, what's the purpose of a constructor? It is there to >>> *initialize* an instance. If there is nothing to initialize, it is not >>> strictly necessary to call any constructor. >>> >> >> Yes, I understand the purpose of a constructor - it looks like much more >> than you do. >> >>> But anyway, unserializing an object is *not* creating a new object. >>> Consider a class man. When a new object is instantiated the constructor >>> is called to initialize the person with respective properties (e.g. age >>> = 0). Later this man goes to sleep (serialize); after he wakes up >>> (unserialize) the constructor is not called again, as this would reset >>> the man to his initial properties, and surely after a good night of >>> sleep one may feel younger, but the age has not been reset. >>> >> >> It is creating a new object. Before unserialize(), the object does not >> exist - only a bunch of data. And that data is NOT an object! You >> cannot call an object method on the data, for instance. It is no >> different than if the data were stored in a file and loaded in Java or >> C++, for instance. To create the object requires a call to a constructor. > > If you really need to think this way, just take > Serializable::serialize() resp. __sleep() as a destructor and > Serializable::unserialize() resp. __wakeup() as a constructor. > Actually, the documentation of the Serializable interface explaines it > that way. > Then it is wrong in another respect, because the destructor is called after __sleep(), when the object goes out of scope. >>>> If you think otherwise, I suggest you learn more about how OO >>>> is supposed to work. PHP is not a good example. >>> >>> I refrain from commenting this statement. >>> >> >> If you think otherwise, I suggest you learn more about how OO is >> supposed to work. PHP is not a good example. > > No comment. > No matter how you look at it, PHP's implementation violates OO principles and works differently than any other OO language. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-26 23:39 +0100 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <530e6d33$0$9521$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #13009 |
Jerry Stuckle wrote: > On 2/26/2014 4:59 PM, Christoph Michael Becker wrote: >> Jerry Stuckle wrote: >> >>> On 2/26/2014 3:10 PM, Christoph Michael Becker wrote: >>>> Jerry Stuckle wrote: >>>> >>>>> On 2/25/2014 6:22 PM, Adam Harvey wrote: >>>>>> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote: >>>>>>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote: >>>>>>>> I firmly believe that it wouldn't make sense to call a >>>>>>>> (user-defined) >>>>>>>> constructor when unserializing or cloning an object. A constructor >>>>>>>> usually serves to initialize an object -- what already had >>>>>>>> happened in >>>>>>>> both cases. >>>>>>>> >>>>>>>> >>>>>>> It makes perfect sense. Not everything is necessarily valid in the >>>>>>> new >>>>>>> object. For instance, a logging object may require opening the log >>>>>>> file. There are many instances where a resource is no longer >>>>>>> available >>>>>>> and needs to be recreated. >>>>>> >>>>>> Indeed, which is why PHP provides the Serializable interface (and, >>>>>> for BC >>>>>> reasons, also __sleep and __wakeup) to allow those sorts of >>>>>> reinitialisation tasks. >>>>>> >>>>>> I agree with Christoph: since the object is already instantiated, it >>>>>> doesn't logically make sense to call the constructor once again. >>>>>> >>>>> >>>>> But the object is NOT instantiated. It was at one time, then >>>>> destroyed. >>>>> When the new script starts, there is no object in existence. >>>>> >>>>>>>> Jerry Stuckle wrote: >>>>>>>>> I know of no other OO language which would allow this. >>>>>>>> >>>>>>>> Others may. >>>>>>>> >>>>>>>> >>>>>>> None that I know of. Please name one. >>>>>> >>>>>> Python's pickle operates the same way: >>>>>> http://docs.python.org/2/library/pickle.html#object.__getinitargs__ >>>>>> >>>>>> Providing a way to instantiate objects without calling the >>>>>> constructor >>>>>> does have valid uses (mostly for testing), which is why PHP 5.4 and >>>>>> later >>>>>> versions also provide a way to do so via reflection (avoiding the >>>>>> unserialize() hack): >>>>>> http://php.net/reflectionclass.newinstancewithoutconstructor >>>>>> >>>>>> Adam >>>>>> >>>>> >>>>> Not knowing Python, I can't say. But if it is a true object, then >>>>> they >>>>> are also violating OO principles. >>>>> >>>>> OO demands creation of a new object requires a constructor call. >>>>> Period. >>>> >>>> Do you understand, what's the purpose of a constructor? It is there to >>>> *initialize* an instance. If there is nothing to initialize, it is not >>>> strictly necessary to call any constructor. >>>> >>> >>> Yes, I understand the purpose of a constructor - it looks like much more >>> than you do. >>> >>>> But anyway, unserializing an object is *not* creating a new object. >>>> Consider a class man. When a new object is instantiated the >>>> constructor >>>> is called to initialize the person with respective properties (e.g. age >>>> = 0). Later this man goes to sleep (serialize); after he wakes up >>>> (unserialize) the constructor is not called again, as this would reset >>>> the man to his initial properties, and surely after a good night of >>>> sleep one may feel younger, but the age has not been reset. >>>> >>> >>> It is creating a new object. Before unserialize(), the object does not >>> exist - only a bunch of data. And that data is NOT an object! You >>> cannot call an object method on the data, for instance. It is no >>> different than if the data were stored in a file and loaded in Java or >>> C++, for instance. To create the object requires a call to a >>> constructor. >> >> If you really need to think this way, just take >> Serializable::serialize() resp. __sleep() as a destructor and >> Serializable::unserialize() resp. __wakeup() as a constructor. >> Actually, the documentation of the Serializable interface explaines it >> that way. >> > > Then it is wrong in another respect, because the destructor is called > after __sleep(), when the object goes out of scope. > >>>>> If you think otherwise, I suggest you learn more about >>>>> how OO >>>>> is supposed to work. PHP is not a good example. >>>> >>>> I refrain from commenting this statement. >>>> >>> >>> If you think otherwise, I suggest you learn more about how OO is >>> supposed to work. PHP is not a good example. >> >> No comment. >> > > No matter how you look at it, PHP's implementation violates OO > principles and works differently than any other OO language. You have claimed that often enough, but yet you have not brought any proof. E.g. what happens in Java if an object that implements the java.io.Serializable interface is given as argument to java.io.OutputStream.writeObject()? Is the destructor called? -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-26 22:30 -0500 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <lembfp$3ee$1@dont-email.me> |
| In reply to | #13011 |
On 2/26/2014 5:39 PM, Christoph Michael Becker wrote: > Jerry Stuckle wrote: > >> On 2/26/2014 4:59 PM, Christoph Michael Becker wrote: >>> Jerry Stuckle wrote: >>> >>>> On 2/26/2014 3:10 PM, Christoph Michael Becker wrote: >>>>> Jerry Stuckle wrote: >>>>> >>>>>> On 2/25/2014 6:22 PM, Adam Harvey wrote: >>>>>>> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote: >>>>>>>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote: >>>>>>>>> I firmly believe that it wouldn't make sense to call a >>>>>>>>> (user-defined) >>>>>>>>> constructor when unserializing or cloning an object. A constructor >>>>>>>>> usually serves to initialize an object -- what already had >>>>>>>>> happened in >>>>>>>>> both cases. >>>>>>>>> >>>>>>>>> >>>>>>>> It makes perfect sense. Not everything is necessarily valid in the >>>>>>>> new >>>>>>>> object. For instance, a logging object may require opening the log >>>>>>>> file. There are many instances where a resource is no longer >>>>>>>> available >>>>>>>> and needs to be recreated. >>>>>>> >>>>>>> Indeed, which is why PHP provides the Serializable interface (and, >>>>>>> for BC >>>>>>> reasons, also __sleep and __wakeup) to allow those sorts of >>>>>>> reinitialisation tasks. >>>>>>> >>>>>>> I agree with Christoph: since the object is already instantiated, it >>>>>>> doesn't logically make sense to call the constructor once again. >>>>>>> >>>>>> >>>>>> But the object is NOT instantiated. It was at one time, then >>>>>> destroyed. >>>>>> When the new script starts, there is no object in existence. >>>>>> >>>>>>>>> Jerry Stuckle wrote: >>>>>>>>>> I know of no other OO language which would allow this. >>>>>>>>> >>>>>>>>> Others may. >>>>>>>>> >>>>>>>>> >>>>>>>> None that I know of. Please name one. >>>>>>> >>>>>>> Python's pickle operates the same way: >>>>>>> http://docs.python.org/2/library/pickle.html#object.__getinitargs__ >>>>>>> >>>>>>> Providing a way to instantiate objects without calling the >>>>>>> constructor >>>>>>> does have valid uses (mostly for testing), which is why PHP 5.4 and >>>>>>> later >>>>>>> versions also provide a way to do so via reflection (avoiding the >>>>>>> unserialize() hack): >>>>>>> http://php.net/reflectionclass.newinstancewithoutconstructor >>>>>>> >>>>>>> Adam >>>>>>> >>>>>> >>>>>> Not knowing Python, I can't say. But if it is a true object, then >>>>>> they >>>>>> are also violating OO principles. >>>>>> >>>>>> OO demands creation of a new object requires a constructor call. >>>>>> Period. >>>>> >>>>> Do you understand, what's the purpose of a constructor? It is there to >>>>> *initialize* an instance. If there is nothing to initialize, it is not >>>>> strictly necessary to call any constructor. >>>>> >>>> >>>> Yes, I understand the purpose of a constructor - it looks like much more >>>> than you do. >>>> >>>>> But anyway, unserializing an object is *not* creating a new object. >>>>> Consider a class man. When a new object is instantiated the >>>>> constructor >>>>> is called to initialize the person with respective properties (e.g. age >>>>> = 0). Later this man goes to sleep (serialize); after he wakes up >>>>> (unserialize) the constructor is not called again, as this would reset >>>>> the man to his initial properties, and surely after a good night of >>>>> sleep one may feel younger, but the age has not been reset. >>>>> >>>> >>>> It is creating a new object. Before unserialize(), the object does not >>>> exist - only a bunch of data. And that data is NOT an object! You >>>> cannot call an object method on the data, for instance. It is no >>>> different than if the data were stored in a file and loaded in Java or >>>> C++, for instance. To create the object requires a call to a >>>> constructor. >>> >>> If you really need to think this way, just take >>> Serializable::serialize() resp. __sleep() as a destructor and >>> Serializable::unserialize() resp. __wakeup() as a constructor. >>> Actually, the documentation of the Serializable interface explaines it >>> that way. >>> >> >> Then it is wrong in another respect, because the destructor is called >> after __sleep(), when the object goes out of scope. >> >>>>>> If you think otherwise, I suggest you learn more about >>>>>> how OO >>>>>> is supposed to work. PHP is not a good example. >>>>> >>>>> I refrain from commenting this statement. >>>>> >>>> >>>> If you think otherwise, I suggest you learn more about how OO is >>>> supposed to work. PHP is not a good example. >>> >>> No comment. >>> >> >> No matter how you look at it, PHP's implementation violates OO >> principles and works differently than any other OO language. > > You have claimed that often enough, but yet you have not brought any > proof. > > E.g. what happens in Java if an object that implements the > java.io.Serializable interface is given as argument to > java.io.OutputStream.writeObject()? Is the destructor called? > Yes, it is. But when the new object is created, a constructor is called. You cannot unserialize an object without a constructor being called first. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-27 18:28 +0100 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <530f759b$0$9503$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #13014 |
Jerry Stuckle wrote: > On 2/26/2014 5:39 PM, Christoph Michael Becker wrote: >> Jerry Stuckle wrote: >> >>> On 2/26/2014 4:59 PM, Christoph Michael Becker wrote: >>>> Jerry Stuckle wrote: >>>> >>>>> On 2/26/2014 3:10 PM, Christoph Michael Becker wrote: >>>>>> Jerry Stuckle wrote: >>>>>> >>>>>>> On 2/25/2014 6:22 PM, Adam Harvey wrote: >>>>>>>> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote: >>>>>>>>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote: >>>>>>>>>> I firmly believe that it wouldn't make sense to call a >>>>>>>>>> (user-defined) >>>>>>>>>> constructor when unserializing or cloning an object. A >>>>>>>>>> constructor >>>>>>>>>> usually serves to initialize an object -- what already had >>>>>>>>>> happened in >>>>>>>>>> both cases. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> It makes perfect sense. Not everything is necessarily valid in >>>>>>>>> the >>>>>>>>> new >>>>>>>>> object. For instance, a logging object may require opening the >>>>>>>>> log >>>>>>>>> file. There are many instances where a resource is no longer >>>>>>>>> available >>>>>>>>> and needs to be recreated. >>>>>>>> >>>>>>>> Indeed, which is why PHP provides the Serializable interface (and, >>>>>>>> for BC >>>>>>>> reasons, also __sleep and __wakeup) to allow those sorts of >>>>>>>> reinitialisation tasks. >>>>>>>> >>>>>>>> I agree with Christoph: since the object is already >>>>>>>> instantiated, it >>>>>>>> doesn't logically make sense to call the constructor once again. >>>>>>>> >>>>>>> >>>>>>> But the object is NOT instantiated. It was at one time, then >>>>>>> destroyed. >>>>>>> When the new script starts, there is no object in existence. >>>>>>> >>>>>>>>>> Jerry Stuckle wrote: >>>>>>>>>>> I know of no other OO language which would allow this. >>>>>>>>>> >>>>>>>>>> Others may. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> None that I know of. Please name one. >>>>>>>> >>>>>>>> Python's pickle operates the same way: >>>>>>>> http://docs.python.org/2/library/pickle.html#object.__getinitargs__ >>>>>>>> >>>>>>>> Providing a way to instantiate objects without calling the >>>>>>>> constructor >>>>>>>> does have valid uses (mostly for testing), which is why PHP 5.4 and >>>>>>>> later >>>>>>>> versions also provide a way to do so via reflection (avoiding the >>>>>>>> unserialize() hack): >>>>>>>> http://php.net/reflectionclass.newinstancewithoutconstructor >>>>>>>> >>>>>>>> Adam >>>>>>>> >>>>>>> >>>>>>> Not knowing Python, I can't say. But if it is a true object, then >>>>>>> they >>>>>>> are also violating OO principles. >>>>>>> >>>>>>> OO demands creation of a new object requires a constructor call. >>>>>>> Period. >>>>>> >>>>>> Do you understand, what's the purpose of a constructor? It is >>>>>> there to >>>>>> *initialize* an instance. If there is nothing to initialize, it >>>>>> is not >>>>>> strictly necessary to call any constructor. >>>>>> >>>>> >>>>> Yes, I understand the purpose of a constructor - it looks like much >>>>> more >>>>> than you do. >>>>> >>>>>> But anyway, unserializing an object is *not* creating a new object. >>>>>> Consider a class man. When a new object is instantiated the >>>>>> constructor >>>>>> is called to initialize the person with respective properties >>>>>> (e.g. age >>>>>> = 0). Later this man goes to sleep (serialize); after he wakes up >>>>>> (unserialize) the constructor is not called again, as this would >>>>>> reset >>>>>> the man to his initial properties, and surely after a good night of >>>>>> sleep one may feel younger, but the age has not been reset. >>>>>> >>>>> >>>>> It is creating a new object. Before unserialize(), the object does >>>>> not >>>>> exist - only a bunch of data. And that data is NOT an object! You >>>>> cannot call an object method on the data, for instance. It is no >>>>> different than if the data were stored in a file and loaded in Java or >>>>> C++, for instance. To create the object requires a call to a >>>>> constructor. >>>> >>>> If you really need to think this way, just take >>>> Serializable::serialize() resp. __sleep() as a destructor and >>>> Serializable::unserialize() resp. __wakeup() as a constructor. >>>> Actually, the documentation of the Serializable interface explaines it >>>> that way. >>>> >>> >>> Then it is wrong in another respect, because the destructor is called >>> after __sleep(), when the object goes out of scope. >>> >>>>>>> If you think otherwise, I suggest you learn more about >>>>>>> how OO >>>>>>> is supposed to work. PHP is not a good example. >>>>>> >>>>>> I refrain from commenting this statement. >>>>>> >>>>> >>>>> If you think otherwise, I suggest you learn more about how OO is >>>>> supposed to work. PHP is not a good example. >>>> >>>> No comment. >>>> >>> >>> No matter how you look at it, PHP's implementation violates OO >>> principles and works differently than any other OO language. >> >> You have claimed that often enough, but yet you have not brought any >> proof. >> >> E.g. what happens in Java if an object that implements the >> java.io.Serializable interface is given as argument to >> java.io.OutputStream.writeObject()? Is the destructor called? >> > > Yes, it is. I strongly doubt that. On one hand this would mean you can't use the object as soon as it has been written to the stream, and on the other hand there are no *destructors* in Java (finalize() is similar to a destructor, but it is not guaranteed that it will be called). Furthermore it depends on the garbage collector, when an object will be *destroyed*. > But when the new object is created, a constructor is > called. You cannot unserialize an object without a constructor being > called first. I doubt that, too. After all, java.io.ObjectInputStream.readObject() returns an object, which of course has to be *created* -- but there's no need to call its *constructor*. However, I believe our dissent mainly stems from different use of terms. I am accustomed to understand constructor/destructor as user defined functions (which can be defined for custom initialization/finalization tasks), while this may not be the common definition. When you're talking about OO principles wrt. to construction/destruction, you're most likely referring to RAII, which is not necessarily a general OO principle, and might not be possible to be cleanly implemented in garbage collected languages generally (consider cyclic references). Anyway, I somewhat consider this discussion as harping on about principles, and I still don't see that PHP lacks the really important concepts regarding object (de)serialization and cloning. -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-27 16:09 -0500 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <leo9iq$p2i$1@dont-email.me> |
| In reply to | #13022 |
On 2/27/2014 12:28 PM, Christoph Michael Becker wrote: > Jerry Stuckle wrote: > >> On 2/26/2014 5:39 PM, Christoph Michael Becker wrote: >>> Jerry Stuckle wrote: >>> >>>> On 2/26/2014 4:59 PM, Christoph Michael Becker wrote: >>>>> Jerry Stuckle wrote: >>>>> >>>>>> On 2/26/2014 3:10 PM, Christoph Michael Becker wrote: >>>>>>> Jerry Stuckle wrote: >>>>>>> >>>>>>>> On 2/25/2014 6:22 PM, Adam Harvey wrote: >>>>>>>>> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote: >>>>>>>>>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote: >>>>>>>>>>> I firmly believe that it wouldn't make sense to call a >>>>>>>>>>> (user-defined) >>>>>>>>>>> constructor when unserializing or cloning an object. A >>>>>>>>>>> constructor >>>>>>>>>>> usually serves to initialize an object -- what already had >>>>>>>>>>> happened in >>>>>>>>>>> both cases. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> It makes perfect sense. Not everything is necessarily valid in >>>>>>>>>> the >>>>>>>>>> new >>>>>>>>>> object. For instance, a logging object may require opening the >>>>>>>>>> log >>>>>>>>>> file. There are many instances where a resource is no longer >>>>>>>>>> available >>>>>>>>>> and needs to be recreated. >>>>>>>>> >>>>>>>>> Indeed, which is why PHP provides the Serializable interface (and, >>>>>>>>> for BC >>>>>>>>> reasons, also __sleep and __wakeup) to allow those sorts of >>>>>>>>> reinitialisation tasks. >>>>>>>>> >>>>>>>>> I agree with Christoph: since the object is already >>>>>>>>> instantiated, it >>>>>>>>> doesn't logically make sense to call the constructor once again. >>>>>>>>> >>>>>>>> >>>>>>>> But the object is NOT instantiated. It was at one time, then >>>>>>>> destroyed. >>>>>>>> When the new script starts, there is no object in existence. >>>>>>>> >>>>>>>>>>> Jerry Stuckle wrote: >>>>>>>>>>>> I know of no other OO language which would allow this. >>>>>>>>>>> >>>>>>>>>>> Others may. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> None that I know of. Please name one. >>>>>>>>> >>>>>>>>> Python's pickle operates the same way: >>>>>>>>> http://docs.python.org/2/library/pickle.html#object.__getinitargs__ >>>>>>>>> >>>>>>>>> Providing a way to instantiate objects without calling the >>>>>>>>> constructor >>>>>>>>> does have valid uses (mostly for testing), which is why PHP 5.4 and >>>>>>>>> later >>>>>>>>> versions also provide a way to do so via reflection (avoiding the >>>>>>>>> unserialize() hack): >>>>>>>>> http://php.net/reflectionclass.newinstancewithoutconstructor >>>>>>>>> >>>>>>>>> Adam >>>>>>>>> >>>>>>>> >>>>>>>> Not knowing Python, I can't say. But if it is a true object, then >>>>>>>> they >>>>>>>> are also violating OO principles. >>>>>>>> >>>>>>>> OO demands creation of a new object requires a constructor call. >>>>>>>> Period. >>>>>>> >>>>>>> Do you understand, what's the purpose of a constructor? It is >>>>>>> there to >>>>>>> *initialize* an instance. If there is nothing to initialize, it >>>>>>> is not >>>>>>> strictly necessary to call any constructor. >>>>>>> >>>>>> >>>>>> Yes, I understand the purpose of a constructor - it looks like much >>>>>> more >>>>>> than you do. >>>>>> >>>>>>> But anyway, unserializing an object is *not* creating a new object. >>>>>>> Consider a class man. When a new object is instantiated the >>>>>>> constructor >>>>>>> is called to initialize the person with respective properties >>>>>>> (e.g. age >>>>>>> = 0). Later this man goes to sleep (serialize); after he wakes up >>>>>>> (unserialize) the constructor is not called again, as this would >>>>>>> reset >>>>>>> the man to his initial properties, and surely after a good night of >>>>>>> sleep one may feel younger, but the age has not been reset. >>>>>>> >>>>>> >>>>>> It is creating a new object. Before unserialize(), the object does >>>>>> not >>>>>> exist - only a bunch of data. And that data is NOT an object! You >>>>>> cannot call an object method on the data, for instance. It is no >>>>>> different than if the data were stored in a file and loaded in Java or >>>>>> C++, for instance. To create the object requires a call to a >>>>>> constructor. >>>>> >>>>> If you really need to think this way, just take >>>>> Serializable::serialize() resp. __sleep() as a destructor and >>>>> Serializable::unserialize() resp. __wakeup() as a constructor. >>>>> Actually, the documentation of the Serializable interface explaines it >>>>> that way. >>>>> >>>> >>>> Then it is wrong in another respect, because the destructor is called >>>> after __sleep(), when the object goes out of scope. >>>> >>>>>>>> If you think otherwise, I suggest you learn more about >>>>>>>> how OO >>>>>>>> is supposed to work. PHP is not a good example. >>>>>>> >>>>>>> I refrain from commenting this statement. >>>>>>> >>>>>> >>>>>> If you think otherwise, I suggest you learn more about how OO is >>>>>> supposed to work. PHP is not a good example. >>>>> >>>>> No comment. >>>>> >>>> >>>> No matter how you look at it, PHP's implementation violates OO >>>> principles and works differently than any other OO language. >>> >>> You have claimed that often enough, but yet you have not brought any >>> proof. >>> >>> E.g. what happens in Java if an object that implements the >>> java.io.Serializable interface is given as argument to >>> java.io.OutputStream.writeObject()? Is the destructor called? >>> >> >> Yes, it is. > > I strongly doubt that. On one hand this would mean you can't use the > object as soon as it has been written to the stream, and on the other > hand there are no *destructors* in Java (finalize() is similar to a > destructor, but it is not guaranteed that it will be called). > Furthermore it depends on the garbage collector, when an object will be > *destroyed*. > >> But when the new object is created, a constructor is >> called. You cannot unserialize an object without a constructor being >> called first. > > I doubt that, too. After all, java.io.ObjectInputStream.readObject() > returns an object, which of course has to be *created* -- but there's no > need to call its *constructor*. > No, because the constructor is called automatically. > However, I believe our dissent mainly stems from different use of terms. > I am accustomed to understand constructor/destructor as user defined > functions (which can be defined for custom initialization/finalization > tasks), while this may not be the common definition. > They may be user defined, or they may be defined by the system (as in the absence of a user-defined constructor). > When you're talking about OO principles wrt. to > construction/destruction, you're most likely referring to RAII, which is > not necessarily a general OO principle, and might not be possible to be > cleanly implemented in garbage collected languages generally (consider > cyclic references). > No, I am not referring to RAII. I am referring to basic OO principles. > Anyway, I somewhat consider this discussion as harping on about > principles, and I still don't see that PHP lacks the really important > concepts regarding object (de)serialization and cloning. > Just that it doesn't follow OO principles - which has caused me problems in the past. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-28 14:52 +0100 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <531094a4$0$9522$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #13027 |
Jerry Stuckle wrote:
> On 2/27/2014 12:28 PM, Christoph Michael Becker wrote:
>> Jerry Stuckle wrote:
>>
>>> On 2/26/2014 5:39 PM, Christoph Michael Becker wrote:
>>>> Jerry Stuckle wrote:
>>>>
>>>>> No matter how you look at it, PHP's implementation violates OO
>>>>> principles and works differently than any other OO language.
>>>>
>>>> You have claimed that often enough, but yet you have not brought any
>>>> proof.
>>>>
>>>> E.g. what happens in Java if an object that implements the
>>>> java.io.Serializable interface is given as argument to
>>>> java.io.OutputStream.writeObject()? Is the destructor called?
>>>>
>>>
>>> Yes, it is.
>>
>> I strongly doubt that. On one hand this would mean you can't use the
>> object as soon as it has been written to the stream, and on the other
>> hand there are no *destructors* in Java (finalize() is similar to a
>> destructor, but it is not guaranteed that it will be called).
>> Furthermore it depends on the garbage collector, when an object will be
>> *destroyed*.
>>
>>> But when the new object is created, a constructor is
>>> called. You cannot unserialize an object without a constructor being
>>> called first.
>>
>> I doubt that, too. After all, java.io.ObjectInputStream.readObject()
>> returns an object, which of course has to be *created* -- but there's no
>> need to call its *constructor*.
>>
>
> No, because the constructor is called automatically.
Wrong, see below.
>> However, I believe our dissent mainly stems from different use of terms.
>> I am accustomed to understand constructor/destructor as user defined
>> functions (which can be defined for custom initialization/finalization
>> tasks), while this may not be the common definition.
>>
>
> They may be user defined, or they may be defined by the system (as in
> the absence of a user-defined constructor).
>
>> When you're talking about OO principles wrt. to
>> construction/destruction, you're most likely referring to RAII, which is
>> not necessarily a general OO principle, and might not be possible to be
>> cleanly implemented in garbage collected languages generally (consider
>> cyclic references).
>>
>
> No, I am not referring to RAII. I am referring to basic OO principles.
>
>> Anyway, I somewhat consider this discussion as harping on about
>> principles, and I still don't see that PHP lacks the really important
>> concepts regarding object (de)serialization and cloning.
>>
>
> Just that it doesn't follow OO principles - which has caused me problems
> in the past.
To shorten further discussion I have installed the JDK 7u51, and written
the following classes:
---- Foo.java ----
public class Foo implements java.io.Serializable {
protected int bar;
public Foo() {
System.out.println("Constructor of Foo called");
bar = 0;
}
public int getBar() {
return bar;
}
public void setBar(int value) {
bar = value;
}
}
---- Demo.java ----
import java.io.*;
public class Demo {
public static void main(String[] args)
throws IOException, ClassNotFoundException {
Foo foo = new Foo();
foo.setBar(42);
FileOutputStream fileOut = new FileOutputStream("./ser");
ObjectOutputStream out = new ObjectOutputStream(fileOut);
out.writeObject(foo);
out.close();
fileOut.close();
System.out.println("Serialized foo");
System.out.print("bar = ");
System.out.println(foo.getBar());
foo = null;
FileInputStream fileIn = new FileInputStream("./ser");
ObjectInputStream in = new ObjectInputStream(fileIn);
foo = (Foo) in.readObject();
in.close();
fileIn.close();
System.out.println("Unserialized foo");
System.out.print("bar = ");
System.out.println(foo.getBar());
}
}
To compare that with PHP's behavior, I've written the following script:
---- demo.php ----
<?php
class Foo
{
protected $bar;
public function __construct() {
echo "Constructor of Foo called\n";
$this->bar = 0;
}
public function getBar() {
return $this->bar;
}
public function setBar($value) {
$this->bar = $value;
}
}
$foo = new Foo();
$foo->setBar(42);
file_put_contents('./ser', serialize($foo));
echo "Serialized foo\nbar = ", $foo->getBar(), "\n";
$foo = null;
$foo = unserialize(file_get_contents('./ser'));
echo "Unserialized foo\nbar = ", $foo->getBar(), "\n";
Running the java programm and the PHP script (PHP 5.4.19 cli) produces
the following output:
Constructor of Foo called
Serialized foo
bar = 42
Unserialized foo
bar = 42
Any conclusions are left to the reader.
--
Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-28 09:08 -0500 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <leq591$9q6$1@dont-email.me> |
| In reply to | #13032 |
On 2/28/2014 8:52 AM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 2/27/2014 12:28 PM, Christoph Michael Becker wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> On 2/26/2014 5:39 PM, Christoph Michael Becker wrote:
>>>>> Jerry Stuckle wrote:
>>>>>
>>>>>> No matter how you look at it, PHP's implementation violates OO
>>>>>> principles and works differently than any other OO language.
>>>>>
>>>>> You have claimed that often enough, but yet you have not brought any
>>>>> proof.
>>>>>
>>>>> E.g. what happens in Java if an object that implements the
>>>>> java.io.Serializable interface is given as argument to
>>>>> java.io.OutputStream.writeObject()? Is the destructor called?
>>>>>
>>>>
>>>> Yes, it is.
>>>
>>> I strongly doubt that. On one hand this would mean you can't use the
>>> object as soon as it has been written to the stream, and on the other
>>> hand there are no *destructors* in Java (finalize() is similar to a
>>> destructor, but it is not guaranteed that it will be called).
>>> Furthermore it depends on the garbage collector, when an object will be
>>> *destroyed*.
>>>
>>>> But when the new object is created, a constructor is
>>>> called. You cannot unserialize an object without a constructor being
>>>> called first.
>>>
>>> I doubt that, too. After all, java.io.ObjectInputStream.readObject()
>>> returns an object, which of course has to be *created* -- but there's no
>>> need to call its *constructor*.
>>>
>>
>> No, because the constructor is called automatically.
>
> Wrong, see below.
>
>>> However, I believe our dissent mainly stems from different use of terms.
>>> I am accustomed to understand constructor/destructor as user defined
>>> functions (which can be defined for custom initialization/finalization
>>> tasks), while this may not be the common definition.
>>>
>>
>> They may be user defined, or they may be defined by the system (as in
>> the absence of a user-defined constructor).
>>
>>> When you're talking about OO principles wrt. to
>>> construction/destruction, you're most likely referring to RAII, which is
>>> not necessarily a general OO principle, and might not be possible to be
>>> cleanly implemented in garbage collected languages generally (consider
>>> cyclic references).
>>>
>>
>> No, I am not referring to RAII. I am referring to basic OO principles.
>>
>>> Anyway, I somewhat consider this discussion as harping on about
>>> principles, and I still don't see that PHP lacks the really important
>>> concepts regarding object (de)serialization and cloning.
>>>
>>
>> Just that it doesn't follow OO principles - which has caused me problems
>> in the past.
>
> To shorten further discussion I have installed the JDK 7u51, and written
> the following classes:
>
> ---- Foo.java ----
> public class Foo implements java.io.Serializable {
> protected int bar;
> public Foo() {
> System.out.println("Constructor of Foo called");
> bar = 0;
> }
> public int getBar() {
> return bar;
> }
> public void setBar(int value) {
> bar = value;
> }
> }
>
> ---- Demo.java ----
> import java.io.*;
>
> public class Demo {
> public static void main(String[] args)
> throws IOException, ClassNotFoundException {
> Foo foo = new Foo();
> foo.setBar(42);
> FileOutputStream fileOut = new FileOutputStream("./ser");
> ObjectOutputStream out = new ObjectOutputStream(fileOut);
> out.writeObject(foo);
> out.close();
> fileOut.close();
> System.out.println("Serialized foo");
> System.out.print("bar = ");
> System.out.println(foo.getBar());
> foo = null;
> FileInputStream fileIn = new FileInputStream("./ser");
> ObjectInputStream in = new ObjectInputStream(fileIn);
> foo = (Foo) in.readObject();
> in.close();
> fileIn.close();
> System.out.println("Unserialized foo");
> System.out.print("bar = ");
> System.out.println(foo.getBar());
> }
> }
>
> To compare that with PHP's behavior, I've written the following script:
>
> ---- demo.php ----
> <?php
>
> class Foo
> {
> protected $bar;
> public function __construct() {
> echo "Constructor of Foo called\n";
> $this->bar = 0;
> }
> public function getBar() {
> return $this->bar;
> }
> public function setBar($value) {
> $this->bar = $value;
> }
> }
>
> $foo = new Foo();
> $foo->setBar(42);
> file_put_contents('./ser', serialize($foo));
> echo "Serialized foo\nbar = ", $foo->getBar(), "\n";
> $foo = null;
> $foo = unserialize(file_get_contents('./ser'));
> echo "Unserialized foo\nbar = ", $foo->getBar(), "\n";
>
> Running the java programm and the PHP script (PHP 5.4.19 cli) produces
> the following output:
>
> Constructor of Foo called
> Serialized foo
> bar = 42
> Unserialized foo
> bar = 42
>
> Any conclusions are left to the reader.
>
Which shows just how little you understand programming.
In either case you have not created a new Foo object before serializing;
you have only serialized into an existing object. So obviously no
constructor is called.
Your stoopidity is amazing.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-28 16:52 +0100 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <5310b0b7$0$9503$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #13033 |
Jerry Stuckle wrote:
> On 2/28/2014 8:52 AM, Christoph Michael Becker wrote:
>> Jerry Stuckle wrote:
>>
>>> On 2/27/2014 12:28 PM, Christoph Michael Becker wrote:
>>>> Jerry Stuckle wrote:
>>>>
>>>>> On 2/26/2014 5:39 PM, Christoph Michael Becker wrote:
>>>>>> Jerry Stuckle wrote:
>>>>>>
>>>>>>> No matter how you look at it, PHP's implementation violates OO
>>>>>>> principles and works differently than any other OO language.
>>>>>>
>>>>>> You have claimed that often enough, but yet you have not brought any
>>>>>> proof.
>>>>>>
>>>>>> E.g. what happens in Java if an object that implements the
>>>>>> java.io.Serializable interface is given as argument to
>>>>>> java.io.OutputStream.writeObject()? Is the destructor called?
>>>>>>
>>>>>
>>>>> Yes, it is.
>>>>
>>>> I strongly doubt that. On one hand this would mean you can't use the
>>>> object as soon as it has been written to the stream, and on the other
>>>> hand there are no *destructors* in Java (finalize() is similar to a
>>>> destructor, but it is not guaranteed that it will be called).
>>>> Furthermore it depends on the garbage collector, when an object will be
>>>> *destroyed*.
>>>>
>>>>> But when the new object is created, a constructor is
>>>>> called. You cannot unserialize an object without a constructor being
>>>>> called first.
>>>>
>>>> I doubt that, too. After all, java.io.ObjectInputStream.readObject()
>>>> returns an object, which of course has to be *created* -- but
>>>> there's no
>>>> need to call its *constructor*.
>>>>
>>>
>>> No, because the constructor is called automatically.
>>
>> Wrong, see below.
>>
>>>> However, I believe our dissent mainly stems from different use of
>>>> terms.
>>>> I am accustomed to understand constructor/destructor as user defined
>>>> functions (which can be defined for custom initialization/finalization
>>>> tasks), while this may not be the common definition.
>>>>
>>>
>>> They may be user defined, or they may be defined by the system (as in
>>> the absence of a user-defined constructor).
>>>
>>>> When you're talking about OO principles wrt. to
>>>> construction/destruction, you're most likely referring to RAII,
>>>> which is
>>>> not necessarily a general OO principle, and might not be possible to be
>>>> cleanly implemented in garbage collected languages generally (consider
>>>> cyclic references).
>>>>
>>>
>>> No, I am not referring to RAII. I am referring to basic OO principles.
>>>
>>>> Anyway, I somewhat consider this discussion as harping on about
>>>> principles, and I still don't see that PHP lacks the really important
>>>> concepts regarding object (de)serialization and cloning.
>>>>
>>>
>>> Just that it doesn't follow OO principles - which has caused me problems
>>> in the past.
>>
>> To shorten further discussion I have installed the JDK 7u51, and written
>> the following classes:
>>
>> ---- Foo.java ----
>> public class Foo implements java.io.Serializable {
>> protected int bar;
>> public Foo() {
>> System.out.println("Constructor of Foo called");
>> bar = 0;
>> }
>> public int getBar() {
>> return bar;
>> }
>> public void setBar(int value) {
>> bar = value;
>> }
>> }
>>
>> ---- Demo.java ----
>> import java.io.*;
>>
>> public class Demo {
>> public static void main(String[] args)
>> throws IOException, ClassNotFoundException {
>> Foo foo = new Foo();
>> foo.setBar(42);
>> FileOutputStream fileOut = new FileOutputStream("./ser");
>> ObjectOutputStream out = new ObjectOutputStream(fileOut);
>> out.writeObject(foo);
>> out.close();
>> fileOut.close();
>> System.out.println("Serialized foo");
>> System.out.print("bar = ");
>> System.out.println(foo.getBar());
>> foo = null;
>> FileInputStream fileIn = new FileInputStream("./ser");
>> ObjectInputStream in = new ObjectInputStream(fileIn);
>> foo = (Foo) in.readObject();
>> in.close();
>> fileIn.close();
>> System.out.println("Unserialized foo");
>> System.out.print("bar = ");
>> System.out.println(foo.getBar());
>> }
>> }
>>
>> To compare that with PHP's behavior, I've written the following script:
>>
>> ---- demo.php ----
>> <?php
>>
>> class Foo
>> {
>> protected $bar;
>> public function __construct() {
>> echo "Constructor of Foo called\n";
>> $this->bar = 0;
>> }
>> public function getBar() {
>> return $this->bar;
>> }
>> public function setBar($value) {
>> $this->bar = $value;
>> }
>> }
>>
>> $foo = new Foo();
>> $foo->setBar(42);
>> file_put_contents('./ser', serialize($foo));
>> echo "Serialized foo\nbar = ", $foo->getBar(), "\n";
>> $foo = null;
>> $foo = unserialize(file_get_contents('./ser'));
>> echo "Unserialized foo\nbar = ", $foo->getBar(), "\n";
>>
>> Running the java programm and the PHP script (PHP 5.4.19 cli) produces
>> the following output:
>>
>> Constructor of Foo called
>> Serialized foo
>> bar = 42
>> Unserialized foo
>> bar = 42
>>
>> Any conclusions are left to the reader.
>>
>
> Which shows just how little you understand programming.
>
> In either case you have not created a new Foo object before serializing;
> you have only serialized into an existing object. So obviously no
> constructor is called.
Of course, I have created a new Foo object before serializing in both
cases. You're probably talking about the unserializing code (please
look up the difference), but in this case your statement is wrong, as I
have assigned null to $foo (what would not have been necessary, though).
However, maybe you want
$foo = null;
replaced by
$foo = new Foo();
(resp. for the Java code). While the only benefit of this change would
be to keep the processor busy, it does no real harm (unless in a not
garbage collected environment, where it would create a memory leak).
So what do you think (or rather guess), the last line of the output
would be when changing the code repectively? Answer: bar = 42. That
proofs that the constructor is not called on the unserialized object.
Anyway, both programs behave equivalent, so Java also does not follow
basic OO principles wrt. to object (un)serialization, according to your
claim. However, you have stated it would, so obviously there's a
contradiction.
> Your stoopidity is amazing.
You may consider changing your attitude to not make a fool of you in the
public, again.
--
Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-28 11:03 -0500 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <leqc07$m8i$1@dont-email.me> |
| In reply to | #13034 |
On 2/28/2014 10:52 AM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 2/28/2014 8:52 AM, Christoph Michael Becker wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> On 2/27/2014 12:28 PM, Christoph Michael Becker wrote:
>>>>> Jerry Stuckle wrote:
>>>>>
>>>>>> On 2/26/2014 5:39 PM, Christoph Michael Becker wrote:
>>>>>>> Jerry Stuckle wrote:
>>>>>>>
>>>>>>>> No matter how you look at it, PHP's implementation violates OO
>>>>>>>> principles and works differently than any other OO language.
>>>>>>>
>>>>>>> You have claimed that often enough, but yet you have not brought any
>>>>>>> proof.
>>>>>>>
>>>>>>> E.g. what happens in Java if an object that implements the
>>>>>>> java.io.Serializable interface is given as argument to
>>>>>>> java.io.OutputStream.writeObject()? Is the destructor called?
>>>>>>>
>>>>>>
>>>>>> Yes, it is.
>>>>>
>>>>> I strongly doubt that. On one hand this would mean you can't use the
>>>>> object as soon as it has been written to the stream, and on the other
>>>>> hand there are no *destructors* in Java (finalize() is similar to a
>>>>> destructor, but it is not guaranteed that it will be called).
>>>>> Furthermore it depends on the garbage collector, when an object will be
>>>>> *destroyed*.
>>>>>
>>>>>> But when the new object is created, a constructor is
>>>>>> called. You cannot unserialize an object without a constructor being
>>>>>> called first.
>>>>>
>>>>> I doubt that, too. After all, java.io.ObjectInputStream.readObject()
>>>>> returns an object, which of course has to be *created* -- but
>>>>> there's no
>>>>> need to call its *constructor*.
>>>>>
>>>>
>>>> No, because the constructor is called automatically.
>>>
>>> Wrong, see below.
>>>
>>>>> However, I believe our dissent mainly stems from different use of
>>>>> terms.
>>>>> I am accustomed to understand constructor/destructor as user defined
>>>>> functions (which can be defined for custom initialization/finalization
>>>>> tasks), while this may not be the common definition.
>>>>>
>>>>
>>>> They may be user defined, or they may be defined by the system (as in
>>>> the absence of a user-defined constructor).
>>>>
>>>>> When you're talking about OO principles wrt. to
>>>>> construction/destruction, you're most likely referring to RAII,
>>>>> which is
>>>>> not necessarily a general OO principle, and might not be possible to be
>>>>> cleanly implemented in garbage collected languages generally (consider
>>>>> cyclic references).
>>>>>
>>>>
>>>> No, I am not referring to RAII. I am referring to basic OO principles.
>>>>
>>>>> Anyway, I somewhat consider this discussion as harping on about
>>>>> principles, and I still don't see that PHP lacks the really important
>>>>> concepts regarding object (de)serialization and cloning.
>>>>>
>>>>
>>>> Just that it doesn't follow OO principles - which has caused me problems
>>>> in the past.
>>>
>>> To shorten further discussion I have installed the JDK 7u51, and written
>>> the following classes:
>>>
>>> ---- Foo.java ----
>>> public class Foo implements java.io.Serializable {
>>> protected int bar;
>>> public Foo() {
>>> System.out.println("Constructor of Foo called");
>>> bar = 0;
>>> }
>>> public int getBar() {
>>> return bar;
>>> }
>>> public void setBar(int value) {
>>> bar = value;
>>> }
>>> }
>>>
>>> ---- Demo.java ----
>>> import java.io.*;
>>>
>>> public class Demo {
>>> public static void main(String[] args)
>>> throws IOException, ClassNotFoundException {
>>> Foo foo = new Foo();
>>> foo.setBar(42);
>>> FileOutputStream fileOut = new FileOutputStream("./ser");
>>> ObjectOutputStream out = new ObjectOutputStream(fileOut);
>>> out.writeObject(foo);
>>> out.close();
>>> fileOut.close();
>>> System.out.println("Serialized foo");
>>> System.out.print("bar = ");
>>> System.out.println(foo.getBar());
>>> foo = null;
>>> FileInputStream fileIn = new FileInputStream("./ser");
>>> ObjectInputStream in = new ObjectInputStream(fileIn);
>>> foo = (Foo) in.readObject();
>>> in.close();
>>> fileIn.close();
>>> System.out.println("Unserialized foo");
>>> System.out.print("bar = ");
>>> System.out.println(foo.getBar());
>>> }
>>> }
>>>
>>> To compare that with PHP's behavior, I've written the following script:
>>>
>>> ---- demo.php ----
>>> <?php
>>>
>>> class Foo
>>> {
>>> protected $bar;
>>> public function __construct() {
>>> echo "Constructor of Foo called\n";
>>> $this->bar = 0;
>>> }
>>> public function getBar() {
>>> return $this->bar;
>>> }
>>> public function setBar($value) {
>>> $this->bar = $value;
>>> }
>>> }
>>>
>>> $foo = new Foo();
>>> $foo->setBar(42);
>>> file_put_contents('./ser', serialize($foo));
>>> echo "Serialized foo\nbar = ", $foo->getBar(), "\n";
>>> $foo = null;
>>> $foo = unserialize(file_get_contents('./ser'));
>>> echo "Unserialized foo\nbar = ", $foo->getBar(), "\n";
>>>
>>> Running the java programm and the PHP script (PHP 5.4.19 cli) produces
>>> the following output:
>>>
>>> Constructor of Foo called
>>> Serialized foo
>>> bar = 42
>>> Unserialized foo
>>> bar = 42
>>>
>>> Any conclusions are left to the reader.
>>>
>>
>> Which shows just how little you understand programming.
>>
>> In either case you have not created a new Foo object before serializing;
>> you have only serialized into an existing object. So obviously no
>> constructor is called.
>
> Of course, I have created a new Foo object before serializing in both
> cases. You're probably talking about the unserializing code (please
> look up the difference), but in this case your statement is wrong, as I
> have assigned null to $foo (what would not have been necessary, though).
>
> However, maybe you want
>
> $foo = null;
>
> replaced by
>
> $foo = new Foo();
>
> (resp. for the Java code). While the only benefit of this change would
> be to keep the processor busy, it does no real harm (unless in a not
> garbage collected environment, where it would create a memory leak).
>
> So what do you think (or rather guess), the last line of the output
> would be when changing the code repectively? Answer: bar = 42. That
> proofs that the constructor is not called on the unserialized object.
>
> Anyway, both programs behave equivalent, so Java also does not follow
> basic OO principles wrt. to object (un)serialization, according to your
> claim. However, you have stated it would, so obviously there's a
> contradiction.
>
>> Your stoopidity is amazing.
>
> You may consider changing your attitude to not make a fool of you in the
> public, again.
>
Yes, you continue to make a fool of yourself in public - as your last
statement shows. You have absolutely NO idea what you are talking
about, or how OO works.
I correspond off-list with some knowledgeable people who have followed
this conversation. They can't believe I even try to educate you. It's
like teaching a pig to sing.
And I'm through wasting my time. Your comments aren't even worth a
response (which is why I also refused to fall into your trap as to how I
define an "expression").
You don't discuss. You argue for the sake of argument.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-02-27 01:00 +0100 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <92903185.IQx5DTPeva@PointedEars.de> |
| In reply to | #13003 |
Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>> On 2/25/2014 6:22 PM, Adam Harvey wrote:
>>> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote:
>>>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote:
>>>>> Jerry Stuckle wrote:
>>>>>> I know of no other OO language which would allow this.
>>>>>
>>>>> Others may.
>>>>>
>>>> None that I know of. Please name one.
>>>
>>> Python's pickle operates the same way:
>>> http://docs.python.org/2/library/pickle.html#object.__getinitargs__
>>>
>>> Providing a way to instantiate objects without calling the constructor
>>> does have valid uses (mostly for testing), which is why PHP 5.4 and
>>> later versions also provide a way to do so via reflection (avoiding the
>>> unserialize() hack):
>>> http://php.net/reflectionclass.newinstancewithoutconstructor
>>
>> Not knowing Python, I can't say. But if it is a true object, then they
>> are also violating OO principles.
>>
>> OO demands creation of a new object requires a constructor call.
>> Period.
>
> Do you understand, what's the purpose of a constructor? It is there to
> *initialize* an instance. If there is nothing to initialize, it is not
> strictly necessary to call any constructor.
A constructor does not need to mean initialization; primarily it means
*instantiation*: creating an object and, optionally, creating a relation
between it and another object (in the general sense) it inherits from.
However, both instantiation and initialization also can be done by a factory
method. Factory is one of the GoF design patterns, and it does not violate
principles of OOP at all (those people *literally* wrote the book on OOP).
A factory is a function, usually (but not necessarily) a static method, that
returns (a reference to) an object.¹
Speaking of Python, ISTM that it has generalized the Factory pattern so that
both the concept of constructor and the keyword “new” become unnecessary (so
that “new” is not a keyword or reserved word at all) there: A class can be
called like a function – e.g., Class() –, which invokes the __init__()
method of the class if defined, for initialization, and passes to it the
parameters passed to the class/constructor call; otherwise it just
instantiates that class, returning a reference to the instance. (However,
initialization of the instance not dependent on parameters of the
instantiation can also be done in the class code itself.)
$ python3
Python 3.3.5rc1 (default, Feb 23 2014, 19:47:14)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> new = 2
>>> class Class(object): pass
...
>>> Class
<class '__main__.Class'>
>>> Class()
<__main__.Class object at 0xb718d04c>
See also <http://docs.python.org/3/tutorial/classes.html#a-first-look-at-classes>
> But anyway, unserializing an object is *not* creating a new object.
IBTD. However, as we will see soon, it is largely irrelevant that
unserializing *necessarily* creates a new object. Because the relation
between an object and the object it inherits from is just data that can
be stored, and later retrieved to restore that relation, much like a
constructor initially does.
The only important thing is that the relevant parts of the code that
serialized the object and that unserialize data to restore the object must
be identical; otherwise the restored state is not functionally
indistinguishable to the original state of the object. (WLOG, that is the
case as the serializing and unserializing code are the same and are running
in the same or at least a compatible environment.)
> Consider a class man. When a new object is instantiated the constructor
> is called to initialize the person with respective properties (e.g. age
> = 0). Later this man goes to sleep (serialize); after he wakes up
> (unserialize) the constructor is not called again, as this would reset
> the man to his initial properties, and surely after a good night of
> sleep one may feel younger, but the age has not been reset.
That is a really good analogy. (Too bad that Jerry did not understand it.)
It points out that, basically, an object is a collection of data, and
methods to operate on/with that data. WLOG, data is serializable, and
methods are inherited from another object (in the general sense; in class-
based OOP: a class). The relation to that other object again is just data.²
Data can be stored in different forms, and retrieved. Therefore, an object
can be restored to its previous state, or at least to a state that is
functionally indistinguishable from its previous state, without calling a
constructor.
$ php -r '
class C implements Serializable
{
private $_data = 42;
function serialize()
{
return serialize($this->_data);
}
function unserialize ($serialized)
{
echo "\$serialized = "; var_dump($serialized);
$this->_data = unserialize($serialized);
}
};
$c = new C();
echo "\$c = "; var_dump($c);
$s = serialize($c);
echo "\$s = "; var_dump($s);
$c = unserialize($s);
echo "\$c = "; var_dump($c);
'
class C#1 (1) {
private $_data =>
int(42)
}
string(17) "C:1:"C":5:{i:42;}"
string(5) "i:42;"
class C#2 (1) {
private $_data =>
int(42)
}
PointedEars
___________
¹ Those who object to considering a mere function OOP should read the
ECMAScript Language Specification, which shows that every function can be
made a method of an object; especially, globally declared functions are
methods of a global object.
² Even if a method is not inherited (which cannot happen in PHP) it would
be possible to serialize it as it is just code. However, this is not
always possible by means of the language itself instead of the core
language implementation.
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-26 22:39 -0500 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <lemc2a$6mb$1@dont-email.me> |
| In reply to | #13013 |
On 2/26/2014 7:00 PM, Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>
>> Jerry Stuckle wrote:
>>> On 2/25/2014 6:22 PM, Adam Harvey wrote:
>>>> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote:
>>>>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote:
>>>>>> Jerry Stuckle wrote:
>>>>>>> I know of no other OO language which would allow this.
>>>>>>
>>>>>> Others may.
>>>>>>
>>>>> None that I know of. Please name one.
>>>>
>>>> Python's pickle operates the same way:
>>>> http://docs.python.org/2/library/pickle.html#object.__getinitargs__
>>>>
>>>> Providing a way to instantiate objects without calling the constructor
>>>> does have valid uses (mostly for testing), which is why PHP 5.4 and
>>>> later versions also provide a way to do so via reflection (avoiding the
>>>> unserialize() hack):
>>>> http://php.net/reflectionclass.newinstancewithoutconstructor
>>>
>>> Not knowing Python, I can't say. But if it is a true object, then they
>>> are also violating OO principles.
>>>
>>> OO demands creation of a new object requires a constructor call.
>>> Period.
>>
>> Do you understand, what's the purpose of a constructor? It is there to
>> *initialize* an instance. If there is nothing to initialize, it is not
>> strictly necessary to call any constructor.
>
> A constructor does not need to mean initialization; primarily it means
> *instantiation*: creating an object and, optionally, creating a relation
> between it and another object (in the general sense) it inherits from.
> However, both instantiation and initialization also can be done by a factory
> method. Factory is one of the GoF design patterns, and it does not violate
> principles of OOP at all (those people *literally* wrote the book on OOP).
> A factory is a function, usually (but not necessarily) a static method, that
> returns (a reference to) an object.¹
>
Incorrect (as usual). The constructor is designed to initialize an
object. In OO programming, an object is always valid, or, if not valid,
refuses any operations which depend on the object being valid.
A factory is only a means of instantiating the object. It does not
replace or preclude the constructor being called.
> Speaking of Python, ISTM that it has generalized the Factory pattern so that
> both the concept of constructor and the keyword “new” become unnecessary (so
> that “new” is not a keyword or reserved word at all) there: A class can be
> called like a function – e.g., Class() –, which invokes the __init__()
> method of the class if defined, for initialization, and passes to it the
> parameters passed to the class/constructor call; otherwise it just
> instantiates that class, returning a reference to the instance. (However,
> initialization of the instance not dependent on parameters of the
> instantiation can also be done in the class code itself.)
>
> $ python3
> Python 3.3.5rc1 (default, Feb 23 2014, 19:47:14)
> [GCC 4.8.2] on linux
> Type "help", "copyright", "credits" or "license" for more information.
Which means the constructor IS called.
>>>> new = 2
>>>> class Class(object): pass
> ...
>>>> Class
> <class '__main__.Class'>
>>>> Class()
> <__main__.Class object at 0xb718d04c>
>
> See also <http://docs.python.org/3/tutorial/classes.html#a-first-look-at-classes>
>
>> But anyway, unserializing an object is *not* creating a new object.
>
> IBTD. However, as we will see soon, it is largely irrelevant that
> unserializing *necessarily* creates a new object. Because the relation
> between an object and the object it inherits from is just data that can
> be stored, and later retrieved to restore that relation, much like a
> constructor initially does.
>
It is not at all irrelevant. Unserializing an object by definition
creates a new object.
> The only important thing is that the relevant parts of the code that
> serialized the object and that unserialize data to restore the object must
> be identical; otherwise the restored state is not functionally
> indistinguishable to the original state of the object. (WLOG, that is the
> case as the serializing and unserializing code are the same and are running
> in the same or at least a compatible environment.)
>
But it cannot always be identical. For instance, one of the members of
an object may be a file handle; that file handle is no longer valid and
the file being used must be opened again - creating a new file handle.
>> Consider a class man. When a new object is instantiated the constructor
>> is called to initialize the person with respective properties (e.g. age
>> = 0). Later this man goes to sleep (serialize); after he wakes up
>> (unserialize) the constructor is not called again, as this would reset
>> the man to his initial properties, and surely after a good night of
>> sleep one may feel younger, but the age has not been reset.
>
> That is a really good analogy. (Too bad that Jerry did not understand it.)
> It points out that, basically, an object is a collection of data, and
> methods to operate on/with that data. WLOG, data is serializable, and
> methods are inherited from another object (in the general sense; in class-
> based OOP: a class). The relation to that other object again is just data.²
> Data can be stored in different forms, and retrieved. Therefore, an object
> can be restored to its previous state, or at least to a state that is
> functionally indistinguishable from its previous state, without calling a
> constructor.
>
I understood it, but it is a bad example. Calling a constructor does
NOT necessarily reset the object to an initial state - this happens only
in PHP. In REAL OO languages, the object can be initialized to other
data - a good example is the copy constructor in either C++ or Java.
> $ php -r '
> class C implements Serializable
> {
> private $_data = 42;
>
> function serialize()
> {
> return serialize($this->_data);
> }
>
> function unserialize ($serialized)
> {
> echo "\$serialized = "; var_dump($serialized);
>
> $this->_data = unserialize($serialized);
> }
> };
>
> $c = new C();
>
> echo "\$c = "; var_dump($c);
>
> $s = serialize($c);
>
> echo "\$s = "; var_dump($s);
>
> $c = unserialize($s);
>
> echo "\$c = "; var_dump($c);
> '
> class C#1 (1) {
> private $_data =>
> int(42)
> }
> string(17) "C:1:"C":5:{i:42;}"
> string(5) "i:42;"
> class C#2 (1) {
> private $_data =>
> int(42)
> }
>
>
Which just shows that PHP does not implement OO operations properly.
P.S. Your sig separator is broken. It should be exactly
hyphen-hyphen-space-newline.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-02-27 18:29 +0100 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <4576501.4h626yCCDb@PointedEars.de> |
| In reply to | #13015 |
Jerry Stuckle wrote:
> On 2/26/2014 7:00 PM, Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> Jerry Stuckle wrote:
>>>> On 2/25/2014 6:22 PM, Adam Harvey wrote:
>>>>> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote:
>>>>>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote:
>>>>>>> Jerry Stuckle wrote:
>>>>>>>> I know of no other OO language which would allow this.
>>>>>>> Others may.
>>>>>> None that I know of. Please name one.
>>>>>
>>>>> Python's pickle operates the same way:
>>>>> http://docs.python.org/2/library/pickle.html#object.__getinitargs__
>>>>>
>>>>> Providing a way to instantiate objects without calling the constructor
>>>>> does have valid uses (mostly for testing), which is why PHP 5.4 and
>>>>> later versions also provide a way to do so via reflection (avoiding
>>>>> the unserialize() hack):
>>>>> http://php.net/reflectionclass.newinstancewithoutconstructor
>>>>
>>>> Not knowing Python, I can't say. But if it is a true object, then they
>>>> are also violating OO principles.
>>>>
>>>> OO demands creation of a new object requires a constructor call.
>>>> Period.
>>>
>>> Do you understand, what's the purpose of a constructor? It is there to
>>> *initialize* an instance. If there is nothing to initialize, it is not
>>> strictly necessary to call any constructor.
>>
>> A constructor does not need to mean initialization; primarily it means
>> *instantiation*: creating an object and, optionally, creating a relation
>> between it and another object (in the general sense) it inherits from.
>> However, both instantiation and initialization also can be done by a
>> factory method. Factory is one of the GoF design patterns, and it does
>> not violate principles of OOP at all (those people *literally* wrote the
>> book on OOP). A factory is a function, usually (but not necessarily) a
>> static method, that returns (a reference to) an object.¹
>
> Incorrect (as usual). The constructor is designed to initialize an
> object. In OO programming, an object is always valid, or, if not valid,
> refuses any operations which depend on the object being valid.
At this point I would refer you to “Design Patterns. Elements of Reusable
Object-Oriented Software” (ISBN 3-8273-2199-9) if I not already knew that
you knew everything that is to know about OOP :->
> A factory is only a means of instantiating the object.
No, it can initialize the object, too. I have already given an example *in
PHP*; you are not paying attention.
> It does not replace or preclude the constructor being called.
Nobody said it would.
> [tl;dr Jerry's further misconceptions]
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-27 16:14 -0500 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <leo9ri$s2i$1@dont-email.me> |
| In reply to | #13023 |
On 2/27/2014 12:29 PM, Thomas 'PointedEars' Lahn wrote: > Jerry Stuckle wrote: > >> On 2/26/2014 7:00 PM, Thomas 'PointedEars' Lahn wrote: >>> Christoph Michael Becker wrote: >>>> Jerry Stuckle wrote: >>>>> On 2/25/2014 6:22 PM, Adam Harvey wrote: >>>>>> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote: >>>>>>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote: >>>>>>>> Jerry Stuckle wrote: >>>>>>>>> I know of no other OO language which would allow this. >>>>>>>> Others may. >>>>>>> None that I know of. Please name one. >>>>>> >>>>>> Python's pickle operates the same way: >>>>>> http://docs.python.org/2/library/pickle.html#object.__getinitargs__ >>>>>> >>>>>> Providing a way to instantiate objects without calling the constructor >>>>>> does have valid uses (mostly for testing), which is why PHP 5.4 and >>>>>> later versions also provide a way to do so via reflection (avoiding >>>>>> the unserialize() hack): >>>>>> http://php.net/reflectionclass.newinstancewithoutconstructor >>>>> >>>>> Not knowing Python, I can't say. But if it is a true object, then they >>>>> are also violating OO principles. >>>>> >>>>> OO demands creation of a new object requires a constructor call. >>>>> Period. >>>> >>>> Do you understand, what's the purpose of a constructor? It is there to >>>> *initialize* an instance. If there is nothing to initialize, it is not >>>> strictly necessary to call any constructor. >>> >>> A constructor does not need to mean initialization; primarily it means >>> *instantiation*: creating an object and, optionally, creating a relation >>> between it and another object (in the general sense) it inherits from. >>> However, both instantiation and initialization also can be done by a >>> factory method. Factory is one of the GoF design patterns, and it does >>> not violate principles of OOP at all (those people *literally* wrote the >>> book on OOP). A factory is a function, usually (but not necessarily) a >>> static method, that returns (a reference to) an object.¹ >> >> Incorrect (as usual). The constructor is designed to initialize an >> object. In OO programming, an object is always valid, or, if not valid, >> refuses any operations which depend on the object being valid. > > At this point I would refer you to “Design Patterns. Elements of Reusable > Object-Oriented Software” (ISBN 3-8273-2199-9) if I not already knew that > you knew everything that is to know about OOP :-> > Which does not contradict my statement. >> A factory is only a means of instantiating the object. > > No, it can initialize the object, too. I have already given an example *in > PHP*; you are not paying attention. > Yes, and in real OO languages, it uses a constructor to do so. It does not eliminate the need for the constructor(s). For instance, a factory object cannot directly initialize the private or protected members of an object (an exception being if it is declared a "friend" object in C++ - which is frowned upon), nor can it initialize the private or protected members of a base class. But then a factory is generally not a static method of an object; rather it is normally another object. >> It does not replace or preclude the constructor being called. > > Nobody said it would. > >> [tl;dr Jerry's further misconceptions] > > > PointedEars > Shot down again, Pointed Head. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-26 00:18 +0100 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <530d24cc$0$9525$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #12983 |
Jerry Stuckle wrote:
> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote:
>> Jerry Stuckle wrote:
>>
>>> On 2/25/2014 4:19 PM, Christoph Michael Becker wrote:
>>>> Jerry Stuckle wrote:
>>>>
>>>>> On 2/25/2014 2:19 PM, Christoph Michael Becker wrote:
>>>>>> Jerry Stuckle wrote:
>>>>>>
>>>>>>> I have my own problems with PHP - for instance, it is entirely
>>>>>>> possible
>>>>>>> to create an object without calling a constructor - a violation
>>>>>>> of OO
>>>>>>> principles. But I work around it.
>>>>>>
>>>>>> How is it possible to create an object without its constructor (if
>>>>>> defined) being called?
>>>>>>
>>>>>
>>>>> Load the object from the $_SESSION. The constructor will not be
>>>>> called.
>>>>>
>>>>> However, the constructor is called when the original object was
>>>>> created,
>>>>> and the destructor called when the original object goes out of scope.
>>>>> The destructor is also called when the object loaded from the
>>>>> $_SESSION
>>>>> goes out of scope.
>>>>>
>>>>> The result is one constructor call and two destructor calls. A
>>>>> violation of OO principles.
>>>>
>>>> Um, I'm not sure whether this is a violation of OOP principles.
>>>> Storing
>>>> an object in the session requires serialization of the object, what is
>>>> somewhat comparable to cloning an object. So actually, you're not
>>>> working with the *same* object.
>>>>
>>>> Anyway, you can work around these issues by using the magic methods
>>>> __sleep() and __wakeup(), as you probably know. :)
>>>>
>>>
>>> Yes, it is a violation. When the script starts, the object is
>>> serialized in the $_SESSION. But it does not exist in the script.
>>> Creating it requires a constructor call.
>>
>> It requires the object to be created in memory somehow, but the defined
>> constructor function is not called in this case.
>>
>
> Which is a violation of OO principles.
>
>>> OO principles require exactly
>>> one constructor call and one destructor call for every object created.
>>> Note these may be explicit or implicit, and the functions may be noops,
>>> but the calls must still be made.
>>
>> When you're cloning an object, its constructor will not be called either.
>>
>
> It is in every other language. For instance, in Java, clone() acts like
> a copy constructor. C++ doesn't have a clone() method, but it does have
> a copy constructor.
Isn't the copy constructor called on other occassions as the normal
constructor?
If so, then PHP doesn't handle that too different. While
__constructor() would be the counterpart of a normal constructor,
__clone() would be the counterpart of a copy constructor.
>>> That is not the case here; you get
>>> one constructor call and two destructor calls.
>>
>> I firmly believe that it wouldn't make sense to call a (user-defined)
>> constructor when unserializing or cloning an object. A constructor
>> usually serves to initialize an object -- what already had happened in
>> both cases.
>>
>
> It makes perfect sense. Not everything is necessarily valid in the new
> object. For instance, a logging object may require opening the log
> file. There are many instances where a resource is no longer available
> and needs to be recreated.
Therefore there are __sleep() and wakeup(). In __sleep() you can close
the log file (if it's still open), and in __wakeup() you can open it again.
Anyway, consider the following snippet:
<?php
class Foo {
function __construct() {
$this->bar = 'foo';
}
function setBar($bar) {
$this->bar = $bar;
}
}
$foo = new Foo();
$foo->setBar('bar');
$bar = unserialize(serialize($foo));
echo $bar->bar;
What output would you expect?
> PHP's method is only a shallow copy. Copy constructors and the like
> were created when a deep copy is required (quite often in other languages).
You can force a deep copy yourself by respectively defining __clone().
>>> I know of no other OO language which would allow this.
>>
>> Others may.
>>
>
> None that I know of. Please name one.
Obviously, I was too terse here. I meant: "I can't name one, but others
may be able to name one."
--
Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.php
csiph-web