Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #13014
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Newsgroups | comp.lang.php |
| Subject | Re: Object constructors/destructors |
| Date | 2014-02-26 22:30 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <lembfp$3ee$1@dont-email.me> (permalink) |
| References | (17 earlier) <530e4a38$0$9520$9b4e6d93@newsspool1.arcor-online.net> <lelkn9$919$1@dont-email.me> <530e63d3$0$9502$9b4e6d93@newsspool1.arcor-online.net> <lelp8j$5n8$1@dont-email.me> <530e6d33$0$9521$9b4e6d93@newsspool1.arcor-online.net> |
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 ==================
Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web