Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #13050

Re: Object constructors/destructors

Path csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From Jerry Stuckle <jstucklex@attglobal.net>
Newsgroups comp.lang.php
Subject Re: Object constructors/destructors
Date Sun, 02 Mar 2014 17:48:53 -0500
Organization A noiseless patient Spider
Lines 183
Message-ID <lf0cgi$c21$1@dont-email.me> (permalink)
References <530a29f4$0$9507$9b4e6d93@newsspool1.arcor-online.net> <lefc8a$7ki$1@dont-email.me> <0.176fb73a1430ceabf46e.20140224212342GMT.87y510qk69.fsf@bsb.me.uk> <legehm$286$1@dont-email.me> <0.0e19cf148bd81c84c7e8.20140225043254GMT.87eh2rrevd.fsf@bsb.me.uk> <leh78v$tkk$1@dont-email.me> <0.8872fc115a445007d00d.20140225165618GMT.878uszjfm5.fsf@bsb.me.uk> <leip6d$cmb$1@dont-email.me> <530cecd1$0$9508$9b4e6d93@newsspool1.arcor-online.net> <lej0av$pml$1@dont-email.me> <530d08cd$0$9523$9b4e6d93@newsspool1.arcor-online.net> <lej25h$6gs$1@dont-email.me> <_plPu.249912$as5.113704@en-nntp-14.dc1.easynews.com> <lekr4e$29n$1@dont-email.me> <ltzPu.118340$2V.82699@en-nntp-16.dc1.easynews.com> <lenebr$4r6$1@dont-email.me> <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>
Mime-Version 1.0
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
Injection-Date Sun, 2 Mar 2014 22:48:51 +0000 (UTC)
Injection-Info mx05.eternal-september.org; posting-host="3088393e34bc61b3e6a923d0c81ae1e3"; logging-data="12353"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19vErZiFJNFURFSaU5klIill0gVr2gLNqc="
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
In-Reply-To <N2OQu.285061$gp1.273501@en-nntp-16.dc1.easynews.com>
Cancel-Lock sha1:wpL27fGeuZcMDXq8lAQG0TZsAFQ=
Xref csiph.com comp.lang.php:13050

Show key headers only | View raw

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

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