Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #13050
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Newsgroups | comp.lang.php |
| Subject | Re: Object constructors/destructors |
| Date | 2014-03-02 17:48 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <lf0cgi$c21$1@dont-email.me> (permalink) |
| References | (16 earlier) <HbpQu.283851$gp1.67482@en-nntp-16.dc1.easynews.com> <letc1u$u6r$1@dont-email.me> <7DLQu.171151$hV.24964@en-nntp-16.dc1.easynews.com> <lf053c$qt2$1@dont-email.me> <N2OQu.285061$gp1.273501@en-nntp-16.dc1.easynews.com> |
On 3/2/2014 5:14 PM, Richard Damon wrote: > On 3/2/14, 3:42 PM, Jerry Stuckle wrote: >> On 3/2/2014 2:28 PM, Richard Damon wrote: >>> On 3/1/14, 2:22 PM, Jerry Stuckle wrote: >>>> On 3/1/2014 12:56 PM, Richard Damon wrote: >>>>> On 2/27/14, 8:25 AM, Jerry Stuckle wrote: >>>>>> On 2/26/2014 11:49 PM, Richard Damon wrote: >>>>>>> On 2/26/14, 8:44 AM, Jerry Stuckle wrote: >>>>>>>> On 2/26/2014 7:50 AM, Richard Damon wrote: >>>>>>>>> >>>>>>>>> An the "name" of the Deserializing constructor in PHP is >>>>>>>>> __wakeup(). >>>>>>>>> >>>>>>>>> You also do NOT get two destructor calls on the same object, the >>>>>>>>> deserializing created a new object. >>>>>>>>> >>>>>>>> >>>>>>>> __wakeup() is not a constructor - and does not do the same thing. >>>>>>>> >>>>>>> >>>>>>> What makes it NOT a constructor? IT seems to be exactly the thing >>>>>>> that >>>>>>> does what you say must be done to make the new object via >>>>>>> unserialization. >>>>>>> >>>>>> >>>>>> If you want to consider __wakeup() to be a constructor, then you must >>>>>> consider __sleep() to be a destructor. In that case, PHP is also >>>>>> wrong >>>>>> because if an object is serialized, it will call both __sleep() and >>>>>> the >>>>>> destructor. This would be two calls to destructors for the same >>>>>> object. >>>>>> >>>>> >>>>> WHY does __sleep() need to be a destructor? >>>>> >>>>> __sleep() is a function to control how an object is serialized, and the >>>>> object, as you seem to know, still exists, so no destructor should >>>>> happen at this point, in fact, if you look at it, __sleep() has not >>>>> expected to have any effect on the current object, its purpose is to >>>>> make sure that __wakeup() will get all the data it needs, and allow the >>>>> removal of data that it won't need. >>>>> >>>> >>>> If you are going to claim __wakeup() is a constructor, then you have to >>>> agree that it's opposite (__sleep()) is a destructor. Otherwise you are >>>> being inconsistent. >>>> >>>> You can't just make up rules as you see fit! >>>> >>> >>> Then why are you claiming that something that isn't a desturctor must be >>> one. >>> >> >> I'm not - you're the one claiming __wakeup() is a constructor, but it's >> opposite, __sleep() is not a destructor. >> >>> Serialization, creates an external representation for an object, that is >>> what __sleep() is part of. This does NOT inherently involve the >>> destruction of the object (at least at that point). >>> >> >> Then __wakeup() does NOT inherently involve creation of an object. >> > > Since __wakeup() is (naturally) invoked as part of the deserializing > operation, and since PHP defines deserialization via a factory function > that returns the deserialized object, and thus creates an object, is, BY > DEFINITION, a construction operation. __wakeup() is part of that > process, to allow the programmer to do any parts of the construction > process that isn't automatically done. > > I suppose if you want to be very pedantic, unserialize() is actually the > unserializing constructor for every object, of which __wakeup() is the > programmer definable class specific piece of it. > >>> Deserialization, on the other hand, creates an object from an external >>> representation. so it will involve the construction of a new object (you >>> can do "in-place" deserialization in some languages, where you first >>> create a dummy object, and then fill it in with the external data, but >>> this is normally a clumsy way to define it). >>> >> >> Not in other languages. It builds from an already existing object where >> the constructor has been called. > > Some cases use something like: > > Type obj; > obj.unserialize(source); > > This default constructs the object first, then serializes into the > object. For this to work, the object must not have any "constant" > members that need to be unserialized. For this method, unserialization > is not construction. > > Other cases you use > > Type obj(source); > > or > > Type *obj = new Type(source); > > or even > > Type *obj = unserializing_factory(source) > > In these cases, the object is directly created from the serialization > source, and thus DOES involve a constructor and you do not run into the > problem of constant members. In the last case, the calling program > doesn't even need to know the exact type of the object, just a base > type, and the factory can determine the exact type from the data source. > unserializing_factory might be a global function, or it might be a > static member of the base type Type. > > This last case is in fact, the method used in PHP. Since PHP is a > totally dynamically typed language, there is a single global function > that does this operation, and the serialization format defines what type > of object is to be created. It uses the "magic method" __wakeup() to > provide it with the type specific parts of the operation. > >> >>> Note that the object oriented paradigm does have asymmetry in it. A >>> given type will tend to have multiple constructors, for the different >>> ways that an object might come into existence. There is usually only one >>> destructor. In PHP, one of these constructors is called __construct() >>> which is the general purpose constructor. (unlike in other statically >>> type languages, we can only define one of these). PHP also lets us >>> define a piece of the deserialing constructor with __wakeup() (PHP does >>> some of the heavy lifting here in parsing the serialized data and >>> setting up the object, __wakeup() is just required to do any final >>> needed operations after the values have been set.) >>> >> >> Constructors are constructors, and the destructor is a destructor. No >> asymmetry there. Except in PHP. >> >> > > The asymmetry is that a type will, often, have many different > constructors defined: Default, copy, conversion, etc each taking some > data source, an making an object out of that. One such constructor might > be a deserializing constructor that creates a new object out of a data > source that was specially built by serializing a different object. > > A type will almost exclusively have a single destructor. This difference > in number is the asymmetry I was referring to. > > PHP does not differ here, all objects are created with some form of > "constructor", although PHP does not call all of them constructors. > > __construct() is used when creating an object via new > __clone() is used when creating an object via clone > __wakeup() is used when creating an object via unserialize() > > All of the magic functions have the role of a constructor. > > Your confusion here is probably due to the less than rigorous method > used to document this in PHP, it isn't clear that the PHP term > "constructor" is different than the same term you learned in your object > oriented class. > > > > > > You are like some others here - you'll argue just to argue. There is nothing new here - and you're still wrong. But I'm not going to try to teach the pig to sing any longer. -- ================== 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