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

Groups > comp.lang.php > #12889 > unrolled thread

Operator precedence

Back to article view | Back to comp.lang.php

Contents

  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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#12991 — Re: Object constructors/destructors

On 2/25/2014 6:18 PM, Christoph Michael Becker wrote:
> 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?
>

A copy constructor is a constructor.  It can be called, or another one 
can be called.

> 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.
>

__clone() is not called, either.

>>>>                                     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.
>

Which have nothing to do with construction/destruction.

> 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?
>

$bar is a new Foo object, so I would expect a constructor for class Foo 
to be called for object $bar.  That is how it would work in any true OO 
language.

>> 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().
>

__clone() is not called when initializing from a $_SESSION value.

>>>> 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."
>

You can't name one because true OO languages do it right.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12994 — Re: Object constructors/destructors

On 2/25/14, 4:32 PM, 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.  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.  That is not the case here; you get
> one constructor call and two destructor calls.
> 
> I know of no other OO language which would allow this.
> 

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.

[toc] | [prev] | [next] | [standalone]

#12995 — Re: Object constructors/destructors

On 2/26/2014 7:50 AM, Richard Damon wrote:
> On 2/25/14, 4:32 PM, 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.  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.  That is not the case here; you get
>> one constructor call and two destructor calls.
>>
>> I know of no other OO language which would allow this.
>>
>
> 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.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13016 — Re: Object constructors/destructors

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.

[toc] | [prev] | [next] | [standalone]

#13019 — Re: Object constructors/destructors

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.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13038 — Re: Object constructors/destructors

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.

[toc] | [prev] | [next] | [standalone]

#13040 — Re: Object constructors/destructors

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!

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13044 — Re: Object constructors/destructors

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.

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).

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).

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.)

[toc] | [prev] | [next] | [standalone]

#13046 — Re: Object constructors/destructors

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.

> 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.

> 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.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13049 — Re: Object constructors/destructors

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.

[toc] | [prev] | [next] | [standalone]

#13050 — Re: Object constructors/destructors

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
==================

[toc] | [prev] | [next] | [standalone]

#13051 — Re: Object constructors/destructors

In article <lf0cgi$c21$1@dont-email.me>, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

> 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:

[shitloads snipped]

> > 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.

How about the pair of you learn how to snip, eh? Or is that too
difficult?

-- 
"The idea that Bill Gates has appeared like a knight in shining armour to
 lead all customers out of a mire of technological chaos neatly ignores 
 the fact that it was he who, by peddling second-rate technology, led them
 into it in the first place."                             - Douglas Adams

[toc] | [prev] | [next] | [standalone]

#12976

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 2/25/2014 11:56 AM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 2/24/2014 11:32 PM, Ben Bacarisse wrote:
>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
<snip>
>>>>> Documentation indicates what you CAN do - not what you CAN'T do.  This
>>>>> is true of languages, databases, spreadsheets and about anything else
>>>>> around.
>>>>
>>>> What can you do with the ',' operator?  From the PHP documentation:
>>>
>>> Where in the PHP manual does it say ',' is an operator?
>>
>>    "A full list of PHP operators follows in the section Operator
>>    Precedence."  (which is the section immediately following)
>>
>> That list includes ',' as you yourself stated:
>>
>>    "It is an operator, as indicated by its appearance in the table of
>>    operators.  Operators are not limited to +-*/.".
>>
>> But if that is no longer your position, then we are in agreement.
>>
>
> OK, it does show up in the operator precedence table.  But it also
> says "many uses".  It doesn't define those uses in the table; it
> doesn't tell you what you can't do.

Nor what you can do.  The manual shows all sorts of places where commas
are used but none of the fit the description of an operator as given
else where in the manual.
>
>> <snip>
>>>> As to your general point, the C language standard is an excellent
>>>> example of documentation that says both what you can do and what you
>>>> can't do.
<snip>
>>> No, the C specification does NOT say what you cannot do.
<snip>
>> How many examples would you like?  For example, the C standard gives a
>> grammar for expressions and then, for each operator, it gives
>> constraints on that general form.  The grammar permits 1 = 1, but the
>> constraints on the = operator state that the expression on the left hand
>> side must be a modifiable lvalue.  The upshot is that you can tell what
>> forms of expression are and are not permitted.  In particular, C does
>> not permit (cond ? a : b) = expr; but C++ does.
>
> Exactly.  It tells you what you CAN do.  It does not tell you what you
> cannot do.

We could waste a lot of time going back and forth about what is a
statement about what can be done, and what is a statement about what
can't be done.  The long and the sort of it is that PHP has restrictions
on how some operators can be used which are not documented.  That, in
your interpretation of things, means that the manual fails to tell you
what you *can* do.  According to my view, it fails to tell you what you
can't do.  The effect is the same -- undocumented cases.

<snip>
>>>>> [...]  For instance,
>>>>> in a 32 bit C compiler, an int can be 8, 16, or 32 bits long - all
>>>>> within the specs
>>>>
>>>> No, C does no permit int to be less that 16 bits wide -- 8 is not
>>>> allowed.
>>>
>>> Actually, the ANSI C spec DOES allow it.  The spec sets no hard
>>> minimum or maximum for the size of any of the numeric values.  C can
>>> still run on 8 bit processors, also (as in imbedded systems).
>>
>> It seems odd to be disagreeing about easily verifiable facts.  ANSI C is
>> often used to refer to the first C standard (1989), in which case look
>> at section 2.2.4.2 "Numerical limits".  If you mean the current ANSI
>> standard, that's ISO/IEC 9899:2011 and the section you need is
>> "5.2.4.2.1 Sizes of integer types <limits.h>".  (You also need the
>> section from each that states that the constraints imposed by limits.h
>> apply to both hosted and free-standing implementations.)
>
> As I said before - I wore my ANSI C standard out and tossed it quite a
> while back.  But even then it did not specify a minimum of 16 bits for
> an integer.  There are still 8 bit processors and compilers out there.

I gave a reference to the relevant section, and I quoted (below) the
minimum rage that was specified.  It been the same from the very first
ANSI standard to the latest ISO standard.  The copy you thew out should
have that text just like every other copy.  I don't see what more I can
do.

<snip>
>>>> Yes, but the language gives minimum guarantees which can be used to
>>>> permit code to be ported.
<snip>
>>> The only minimum is that an int must not be smaller than a short.
>>
>> No, there are others -- in particular, a minimum range of representable
>> values for each of the standard integer types.  For int it is from
>> -32767 to +32767.
>
> Then please tell me how an 8 bit compiler can be ANSI Standard?

By implementing 16-bit ints (or wider) either directly by the code
generator or by calling functions.  But the situation is worse than you
think.  Every version of the C standard has required that long int have
at least 32 bits.  A conforming compiler on an 8-bit processor must
implement a 32-bit integer type as well.

<snip>
>>>>> The PHP doc shows you what combinations are permitted.  You are asking
>>>>> about what is NOT permitted.
>>>>
>>>> Yes, because that is part of the specification of the language.  Aren't
>>>> you curious to know what expression forms are permitted on the left of
>>>> an assignment?  Would you not find a grammar for PHP to be a useful part
>>>> of the documentation?  These thing seem unexceptional to me.
>>>
>>> No, the specification of a language states only what is allowed.  For
>>> instance, the C++ spec specifies which operators may be overridden.
>>> It does NOT specify that the '.' operator may not be overridden.
>>
>> Are you just saying wrong things to wind me up?  Section 13.5
>> "Overloaded operators" of the current C++ standard says:
>>
>>    "The following operators cannot be overloaded:
>>       .   .*   ::   ?:"
>>
>> Similar wording exists in the 1998 and 2003 standards.
>
> That has changed in the standard, then.  It used to not specify those
> operators which cannot be overloaded.

The wording is in every version of the C++ standard that I have seen,
and it even predates the standard.  My copy of Ellis and Stroustrup's
"The Annotated C++ Reference Manual" (1990) has exactly the same wording
on page 330.

<snip>
> If you want to produce a "rigorous standard", you are free to do
> so. But standards are mainly for compiler developers; since there is
> only one, I don't see a need for it (and I doubt ZEND would pay any
> attention to it, anyway).

I am sure they wouldn't.  PHP is (to a first approximation) a single
implementation language, and so the source code for that implementation
is the final reference manual.  That's how it is possible to be sure
that, at the moment, you can't use ',' as an operator in a general
expression.  You can scan the grammar to see all the places where a
comma is permitted and (pretty much) exactly what it does in all those
cases.

>> <snip>
>>> Please show where in the manual it shows you can use the ',' operator
>>> like you want.
>>
>> I don't want to use it in any particular way.  In that, the manual is
>> 100% correct because it says nothing at all about how one might use ','
>> in the way it describes operators as working.  Bun I was just querying
>> your statement that it is one.  If you don't think it's an operator, we
>> are in agreement about that.
>
> OK, I will change my position and agree it is an operator.  But it
> cannot be used anywhere you want.

I can't follow this.  But really, does it matter one iota if it has one
that you can't use (except in few specially documented places) or if it
doesn't have one at all?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#12978

Ben Bacarisse wrote:

> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> If you want to produce a "rigorous standard", you are free to do
>> so. But standards are mainly for compiler developers; since there is
>> only one, I don't see a need for it (and I doubt ZEND would pay any
>> attention to it, anyway).
> 
> I am sure they wouldn't.  PHP is (to a first approximation) a single
> implementation language, and so the source code for that implementation
> is the final reference manual.  That's how it is possible to be sure
> that, at the moment, you can't use ',' as an operator in a general
> expression.  You can scan the grammar to see all the places where a
> comma is permitted and (pretty much) exactly what it does in all those
> cases.

There is at least one other important implementation of PHP, namely
HHVM[1], so I wouldn't call PHP a single implementation language.  IMHO
it would be wise to specify the language formally, before
implementations may drift apart.

[1] <http://www.hhvm.com/blog/>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#12987

Christoph Michael Becker <cmbecker69@arcor.de> writes:

> Ben Bacarisse wrote:
>
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> 
>>> If you want to produce a "rigorous standard", you are free to do
>>> so. But standards are mainly for compiler developers; since there is
>>> only one, I don't see a need for it (and I doubt ZEND would pay any
>>> attention to it, anyway).
>> 
>> I am sure they wouldn't.  PHP is (to a first approximation) a single
>> implementation language, and so the source code for that implementation
>> is the final reference manual.  That's how it is possible to be sure
>> that, at the moment, you can't use ',' as an operator in a general
>> expression.  You can scan the grammar to see all the places where a
>> comma is permitted and (pretty much) exactly what it does in all those
>> cases.
>
> There is at least one other important implementation of PHP, namely
> HHVM[1], so I wouldn't call PHP a single implementation language.  IMHO
> it would be wise to specify the language formally, before
> implementations may drift apart.
>
> [1] <http://www.hhvm.com/blog/>

Interesting, thanks.  I was not aware of any other implementations.
From reading a bit of the site, it seems that the objective is full
agreement with the Zend implementation, so, for the moment, there is
still a single implementation that is the ultimate reference.  Any
disagreement in results will be seen as a bug for now (and quite a few
such bugs are listed).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#12950

On 2/24/14, 7:00 AM, Jerry Stuckle wrote:

> What language gives every possible way for you to screw up your
> programming?
> 
> If you want to find out how some screwed-up code works in ANY language,
> you try it and find out.
> 

Herein lies the path to madness.

Take the following C code

#include <stdio.h>

int main() {
  int i = 4;
  i = ++i + i++;
  printf("%i\n", i);
  return 0;
}

Question, you want to find out what this is supposed to do. By your
statement, you run it on a system. The problem is that the answer you
get is only valid for THAT system, and possible for that EXACT piece of
code.

The REAL answer is you compare the code to the formal specification of
the language, and you get the answer.

Too many people use your answer, and then complain because they get a
different answer on another machine, or in different circumstances, and
then complain that the compiler is "broken", when the real answer is
that THEIR program was the one that was broken.

(For those not familiar with C, the answer in this case is that the
program has performed "undefined behavior" by modifying i twice without
a sequence point, and thus *ANY* resultant behavior is acceptable.

Here is a question, does PHP's documentation promise how the equivalent
PHP statement will execute?

...


>> The assignment operators in PHP have, in effect, different precedences
>> on the left and the right (a feature that some languages flaunt) but
>> that is not common and certainly not part of what I'd call basic
>> knowledge.  The documentation gives one example of this peculiarity, but
>> that does not clear the matter up conclusively.  For example, in some
>> languages permit assignment to the result of a conditional expression,
>> but I think it's hard to tell from the documentation what these two do:
>>
>>    $bool ? $a : $b = 42;
>>    ($bool ? $a : $b) = 42;
>>
> 
> Show me what language provides you with examples of every possible
> combination of operators and expressions.

Read the C Grammer definition. It precisely describes how ANY expression
is to be parsed.

It does give the compiler freedom to choose the order to execute the
parse tree, so things without inherent order have no promise of order,
but this is made explicit.


> 
>> The operator precedence table suggests that both mean the same thing,
>> but they don't.  I don't think the meaning of either is easily
>> determined from the documentation.
>>
>> <snip>
>>
> 
> So you try it out, as you do in any language.  But just because you can
> come up with some weird combination of operators which isn't listed in
> the doc does not mean the language is not rigorously defined.
> with 
> But it does mean you are trolling.
> 

Rigorously defined would mean "precisely or exactly defined", which,
yes, does say that if you can come up with a "weird" combination, that
is not documented as to what is to happen, the definition is not
rigorous. A Formal definition, will be complete, as that is part of
being formal.

[toc] | [prev] | [next] | [standalone]

#12954

On 2/24/2014 10:41 PM, Richard Damon wrote:
> On 2/24/14, 7:00 AM, Jerry Stuckle wrote:
>
>> What language gives every possible way for you to screw up your
>> programming?
>>
>> If you want to find out how some screwed-up code works in ANY language,
>> you try it and find out.
>>
>
> Herein lies the path to madness.
>
> Take the following C code
>
> #include <stdio.h>
>
> int main() {
>    int i = 4;
>    i = ++i + i++;
>    printf("%i\n", i);
>    return 0;
> }
>
> Question, you want to find out what this is supposed to do. By your
> statement, you run it on a system. The problem is that the answer you
> get is only valid for THAT system, and possible for that EXACT piece of
> code.
>

No, it shows how it works with THIS compiler.  Not even this system - a 
different compiler may give different results.  But then the same is 
true for ANY compiler.

But then all I claimed was to try it and see how it works for THIS system.

For instance, what is the output of:

int main() {
    int i = 1;
    int j = i << 32;
    printf("%d\n", j);
?>

> The REAL answer is you compare the code to the formal specification of
> the language, and you get the answer.
>

IF you have the formal specification available, and are able to 
understand it.

> Too many people use your answer, and then complain because they get a
> different answer on another machine, or in different circumstances, and
> then complain that the compiler is "broken", when the real answer is
> that THEIR program was the one that was broken.
>
> (For those not familiar with C, the answer in this case is that the
> program has performed "undefined behavior" by modifying i twice without
> a sequence point, and thus *ANY* resultant behavior is acceptable.
>

That is true - and you will not find your example in the ANSI C spec - 
which is why its output is not defined.

> Here is a question, does PHP's documentation promise how the equivalent
> PHP statement will execute?
>
> ...

You tell me.

>
>
>>> The assignment operators in PHP have, in effect, different precedences
>>> on the left and the right (a feature that some languages flaunt) but
>>> that is not common and certainly not part of what I'd call basic
>>> knowledge.  The documentation gives one example of this peculiarity, but
>>> that does not clear the matter up conclusively.  For example, in some
>>> languages permit assignment to the result of a conditional expression,
>>> but I think it's hard to tell from the documentation what these two do:
>>>
>>>     $bool ? $a : $b = 42;
>>>     ($bool ? $a : $b) = 42;
>>>
>>
>> Show me what language provides you with examples of every possible
>> combination of operators and expressions.
>
> Read the C Grammer definition. It precisely describes how ANY expression
> is to be parsed.
>
> It does give the compiler freedom to choose the order to execute the
> parse tree, so things without inherent order have no promise of order,
> but this is made explicit.
>

I have - many times while working on updating C courses.  So much, in 
fact, that I completely wore out the ANSI spec I had (and which cost me 
a bunch of $$$).

The spec specifies the order that operators are evaluated.  It does NOT 
specify the order in which operands are evaluated.  That is why your 
example has undefined results - the spec does not define what should happen.

>
>>
>>> The operator precedence table suggests that both mean the same thing,
>>> but they don't.  I don't think the meaning of either is easily
>>> determined from the documentation.
>>>
>>> <snip>
>>>
>>
>> So you try it out, as you do in any language.  But just because you can
>> come up with some weird combination of operators which isn't listed in
>> the doc does not mean the language is not rigorously defined.
>> with
>> But it does mean you are trolling.
>>
>
> Rigorously defined would mean "precisely or exactly defined", which,
> yes, does say that if you can come up with a "weird" combination, that
> is not documented as to what is to happen, the definition is not
> rigorous. A Formal definition, will be complete, as that is part of
> being formal.
>

PHP is defined as rigorously as other languages.  Just in a more 
reader-friendly way.  (It took me a long time to figure out my way 
through the ANSI C spec - and even longer for SQL).

But then since you seem to hate PHP so much, I suggest you just find 
another language more to your liking and stop wasting people's time in a 
PHP newsgroup.  More trolls we don't need.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13039

On 2/24/14, 11:59 PM, Jerry Stuckle wrote:
> On 2/24/2014 10:41 PM, Richard Damon wrote:
>> On 2/24/14, 7:00 AM, Jerry Stuckle wrote:
>>
>>> What language gives every possible way for you to screw up your
>>> programming?
>>>
>>> If you want to find out how some screwed-up code works in ANY language,
>>> you try it and find out.
>>>
>>
>> Herein lies the path to madness.
>>
>> Take the following C code
>>
>> #include <stdio.h>
>>
>> int main() {
>>    int i = 4;
>>    i = ++i + i++;
>>    printf("%i\n", i);
>>    return 0;
>> }
>>
>> Question, you want to find out what this is supposed to do. By your
>> statement, you run it on a system. The problem is that the answer you
>> get is only valid for THAT system, and possible for that EXACT piece of
>> code.
>>
> 
> No, it shows how it works with THIS compiler.  Not even this system - a
> different compiler may give different results.  But then the same is
> true for ANY compiler.
> 
> But then all I claimed was to try it and see how it works for THIS system.
> 
> For instance, what is the output of:
> 
> int main() {
>    int i = 1;
>    int j = i << 32;
>    printf("%d\n", j);
> ?>
> 

The C language spec makes this clear.

The result of 1 << 32 will be 4,294,967,206.
Now, if INT_MAX is defined to be a smaller value, then the program has
performed "undefined behavior", and the standard provides no constraints
on what happens after that point.

In common terms, if int is a type of at least 34 bits, (to include the
sign bit), this program has defined behavior, and the standard defines
its operation. if int is only a 33 bit type (or smaller), then the
compiler is not obligated to make this work. Practically, you are apt to
get either the result 0 or 1, (0 if the machine actually does the
shifting, 1 if the machine ignores extra shift count bits), but anything
is allowed.

>> The REAL answer is you compare the code to the formal specification of
>> the language, and you get the answer.
>>
> 
> IF you have the formal specification available, and are able to
> understand it.
> 

Not understanding the formal specification is a programmer issue. A
formal language CAN be used without access (or understanding) of the
formal specification through other documentation, and in fact, most
programmers can do a lot without needing to refer to the formal
specifications. The mere existence of them provides a "higher court" to
take issue that seem to come up, and figure out if the documentation or
the implementation has a problem when something doesn't seem right.

>> Too many people use your answer, and then complain because they get a
>> different answer on another machine, or in different circumstances, and
>> then complain that the compiler is "broken", when the real answer is
>> that THEIR program was the one that was broken.
>>
>> (For those not familiar with C, the answer in this case is that the
>> program has performed "undefined behavior" by modifying i twice without
>> a sequence point, and thus *ANY* resultant behavior is acceptable.
>>
> 
> That is true - and you will not find your example in the ANSI C spec -
> which is why its output is not defined.
> 


>> Here is a question, does PHP's documentation promise how the equivalent
>> PHP statement will execute?
>>
>> ...
> 
> You tell me.
> 

YOU made the claim that PHP is rigorously defined. Person making
assertion tends to have burden of proof. Lack of definition would be an
indication that it is NOT so rigorously defined.

>>
>>
>>>> The assignment operators in PHP have, in effect, different precedences
>>>> on the left and the right (a feature that some languages flaunt) but
>>>> that is not common and certainly not part of what I'd call basic
>>>> knowledge.  The documentation gives one example of this peculiarity,
>>>> but
>>>> that does not clear the matter up conclusively.  For example, in some
>>>> languages permit assignment to the result of a conditional expression,
>>>> but I think it's hard to tell from the documentation what these two do:
>>>>
>>>>     $bool ? $a : $b = 42;
>>>>     ($bool ? $a : $b) = 42;
>>>>
>>>
>>> Show me what language provides you with examples of every possible
>>> combination of operators and expressions.
>>
>> Read the C Grammer definition. It precisely describes how ANY expression
>> is to be parsed.
>>
>> It does give the compiler freedom to choose the order to execute the
>> parse tree, so things without inherent order have no promise of order,
>> but this is made explicit.
>>
> 
> I have - many times while working on updating C courses.  So much, in
> fact, that I completely wore out the ANSI spec I had (and which cost me
> a bunch of $$$).
> 
> The spec specifies the order that operators are evaluated.  It does NOT
> specify the order in which operands are evaluated.  That is why your
> example has undefined results - the spec does not define what should
> happen.
> 

Actually, the specification DOES say what happens, the program has
invoked undefined behavior, and any further actions are beyond the scope
of the standard. This IS a precise statement, it may not be real useful
to the programmer figure out predict what will happen, but it does
provide "rules of engagement" for writing programs. The programmer
promises to make sure the code doesn't invoke undefined behavior, and
the standard(s) will define what the program does.

>>
>>>
>>>> The operator precedence table suggests that both mean the same thing,
>>>> but they don't.  I don't think the meaning of either is easily
>>>> determined from the documentation.
>>>>
>>>> <snip>
>>>>
>>>
>>> So you try it out, as you do in any language.  But just because you can
>>> come up with some weird combination of operators which isn't listed in
>>> the doc does not mean the language is not rigorously defined.
>>> with
>>> But it does mean you are trolling.
>>>
>>
>> Rigorously defined would mean "precisely or exactly defined", which,
>> yes, does say that if you can come up with a "weird" combination, that
>> is not documented as to what is to happen, the definition is not
>> rigorous. A Formal definition, will be complete, as that is part of
>> being formal.
>>
> 
> PHP is defined as rigorously as other languages.  Just in a more
> reader-friendly way.  (It took me a long time to figure out my way
> through the ANSI C spec - and even longer for SQL).
> 
> But then since you seem to hate PHP so much, I suggest you just find
> another language more to your liking and stop wasting people's time in a
> PHP newsgroup.  More trolls we don't need.
> 

I don't hate PHP, in fact I find it a very useful language for many usages.

IF you want to claim that PHP is as rigorously defined as a language
like C, then perhaps your problem is you don't understand what rigorous
really means, and where it is useful in defining things.

PHP is NOT "rigorously" defined, its documentation is predominately
"natural language" based, not on formal grammar. This does have
advantages for the "common" programmer, making it easier to learn the
basics of the language, but does leave some minor details, which aren't
normally important poorly defined. Since PHP is predominately a "single
implementation language", it can get away with this.

One other effect of this is that in PHP, it is possible to file a
"documentation bug" for the documentation differing from how the
compiler operates. (this might result in a documentation change, or it
might be determined that it really is a program bug). With a formal
language, the only "bugs" that could be filed against the standard would
be a case where the documentation was in conflict with itself, otherwise
and discrepancy between the documentation and an implementation is, by
definition, a non-conformity in the implementation.

[toc] | [prev] | [next] | [standalone]

#13041

On 3/1/2014 1:39 PM, Richard Damon wrote:
> On 2/24/14, 11:59 PM, Jerry Stuckle wrote:
>> On 2/24/2014 10:41 PM, Richard Damon wrote:
>>> On 2/24/14, 7:00 AM, Jerry Stuckle wrote:
>>>
>>>> What language gives every possible way for you to screw up your
>>>> programming?
>>>>
>>>> If you want to find out how some screwed-up code works in ANY language,
>>>> you try it and find out.
>>>>
>>>
>>> Herein lies the path to madness.
>>>
>>> Take the following C code
>>>
>>> #include <stdio.h>
>>>
>>> int main() {
>>>     int i = 4;
>>>     i = ++i + i++;
>>>     printf("%i\n", i);
>>>     return 0;
>>> }
>>>
>>> Question, you want to find out what this is supposed to do. By your
>>> statement, you run it on a system. The problem is that the answer you
>>> get is only valid for THAT system, and possible for that EXACT piece of
>>> code.
>>>
>>
>> No, it shows how it works with THIS compiler.  Not even this system - a
>> different compiler may give different results.  But then the same is
>> true for ANY compiler.
>>
>> But then all I claimed was to try it and see how it works for THIS system.
>>
>> For instance, what is the output of:
>>
>> int main() {
>>     int i = 1;
>>     int j = i << 32;
>>     printf("%d\n", j);
>> ?>
>>
>
> The C language spec makes this clear.
>
> The result of 1 << 32 will be 4,294,967,206.
> Now, if INT_MAX is defined to be a smaller value, then the program has
> performed "undefined behavior", and the standard provides no constraints
> on what happens after that point.
>

In my compiler, the output is 0.  And it is ANSI compliant.

> In common terms, if int is a type of at least 34 bits, (to include the
> sign bit), this program has defined behavior, and the standard defines
> its operation. if int is only a 33 bit type (or smaller), then the
> compiler is not obligated to make this work. Practically, you are apt to
> get either the result 0 or 1, (0 if the machine actually does the
> shifting, 1 if the machine ignores extra shift count bits), but anything
> is allowed.
>

This has nothing to do with the subject - which is the size of an int.

>>> The REAL answer is you compare the code to the formal specification of
>>> the language, and you get the answer.
>>>
>>
>> IF you have the formal specification available, and are able to
>> understand it.
>>
>
> Not understanding the formal specification is a programmer issue. A
> formal language CAN be used without access (or understanding) of the
> formal specification through other documentation, and in fact, most
> programmers can do a lot without needing to refer to the formal
> specifications. The mere existence of them provides a "higher court" to
> take issue that seem to come up, and figure out if the documentation or
> the implementation has a problem when something doesn't seem right.
>

Yes, but when you're dealing with courseware, knowledge and 
understanding of the specification is a very good idea.

>>> Too many people use your answer, and then complain because they get a
>>> different answer on another machine, or in different circumstances, and
>>> then complain that the compiler is "broken", when the real answer is
>>> that THEIR program was the one that was broken.
>>>
>>> (For those not familiar with C, the answer in this case is that the
>>> program has performed "undefined behavior" by modifying i twice without
>>> a sequence point, and thus *ANY* resultant behavior is acceptable.
>>>
>>
>> That is true - and you will not find your example in the ANSI C spec -
>> which is why its output is not defined.
>>
>
>
>>> Here is a question, does PHP's documentation promise how the equivalent
>>> PHP statement will execute?
>>>
>>> ...
>>
>> You tell me.
>>
>
> YOU made the claim that PHP is rigorously defined. Person making
> assertion tends to have burden of proof. Lack of definition would be an
> indication that it is NOT so rigorously defined.
>

YOU made the first assertion - that PHP is NOT rigorously defined.  So, 
according to your "rules", you have to prove it - which you have not.

>>>
>>>
>>>>> The assignment operators in PHP have, in effect, different precedences
>>>>> on the left and the right (a feature that some languages flaunt) but
>>>>> that is not common and certainly not part of what I'd call basic
>>>>> knowledge.  The documentation gives one example of this peculiarity,
>>>>> but
>>>>> that does not clear the matter up conclusively.  For example, in some
>>>>> languages permit assignment to the result of a conditional expression,
>>>>> but I think it's hard to tell from the documentation what these two do:
>>>>>
>>>>>      $bool ? $a : $b = 42;
>>>>>      ($bool ? $a : $b) = 42;
>>>>>
>>>>
>>>> Show me what language provides you with examples of every possible
>>>> combination of operators and expressions.
>>>
>>> Read the C Grammer definition. It precisely describes how ANY expression
>>> is to be parsed.
>>>
>>> It does give the compiler freedom to choose the order to execute the
>>> parse tree, so things without inherent order have no promise of order,
>>> but this is made explicit.
>>>
>>
>> I have - many times while working on updating C courses.  So much, in
>> fact, that I completely wore out the ANSI spec I had (and which cost me
>> a bunch of $$$).
>>
>> The spec specifies the order that operators are evaluated.  It does NOT
>> specify the order in which operands are evaluated.  That is why your
>> example has undefined results - the spec does not define what should
>> happen.
>>
>
> Actually, the specification DOES say what happens, the program has
> invoked undefined behavior, and any further actions are beyond the scope
> of the standard. This IS a precise statement, it may not be real useful
> to the programmer figure out predict what will happen, but it does
> provide "rules of engagement" for writing programs. The programmer
> promises to make sure the code doesn't invoke undefined behavior, and
> the standard(s) will define what the program does.
>

Actually, no, the specification does not say specifically what happens 
in a case such as j = i++ + ++i;  That is why the operation is 
"undefined" - because nothing in the spec defines what should happen.

>>>
>>>>
>>>>> The operator precedence table suggests that both mean the same thing,
>>>>> but they don't.  I don't think the meaning of either is easily
>>>>> determined from the documentation.
>>>>>
>>>>> <snip>
>>>>>
>>>>
>>>> So you try it out, as you do in any language.  But just because you can
>>>> come up with some weird combination of operators which isn't listed in
>>>> the doc does not mean the language is not rigorously defined.
>>>> with
>>>> But it does mean you are trolling.
>>>>
>>>
>>> Rigorously defined would mean "precisely or exactly defined", which,
>>> yes, does say that if you can come up with a "weird" combination, that
>>> is not documented as to what is to happen, the definition is not
>>> rigorous. A Formal definition, will be complete, as that is part of
>>> being formal.
>>>
>>
>> PHP is defined as rigorously as other languages.  Just in a more
>> reader-friendly way.  (It took me a long time to figure out my way
>> through the ANSI C spec - and even longer for SQL).
>>
>> But then since you seem to hate PHP so much, I suggest you just find
>> another language more to your liking and stop wasting people's time in a
>> PHP newsgroup.  More trolls we don't need.
>>
>
> I don't hate PHP, in fact I find it a very useful language for many usages.
>
> IF you want to claim that PHP is as rigorously defined as a language
> like C, then perhaps your problem is you don't understand what rigorous
> really means, and where it is useful in defining things.
>

I understand exactly what rigorous means.  But you obviously think it 
means "in arcane and hard to understand language".  It does not.

> PHP is NOT "rigorously" defined, its documentation is predominately
> "natural language" based, not on formal grammar. This does have
> advantages for the "common" programmer, making it easier to learn the
> basics of the language, but does leave some minor details, which aren't
> normally important poorly defined. Since PHP is predominately a "single
> implementation language", it can get away with this.
>

And how does the language used make it not "rigorously defined".  Prove 
your statement - according to your rules.

> One other effect of this is that in PHP, it is possible to file a
> "documentation bug" for the documentation differing from how the
> compiler operates. (this might result in a documentation change, or it
> might be determined that it really is a program bug). With a formal
> language, the only "bugs" that could be filed against the standard would
> be a case where the documentation was in conflict with itself, otherwise
> and discrepancy between the documentation and an implementation is, by
> definition, a non-conformity in the implementation.
>

It's also possible to file a "documentation bug" with ANSI 
documentation, also.  It's handled differently, but ANSI understands 
that even its documentation can have errors.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13045

On 3/1/14, 2:29 PM, Jerry Stuckle wrote:
> On 3/1/2014 1:39 PM, Richard Damon wrote:
>> On 2/24/14, 11:59 PM, Jerry Stuckle wrote:
>>>
>>> For instance, what is the output of:
>>>
>>> int main() {
>>>     int i = 1;
>>>     int j = i << 32;
>>>     printf("%d\n", j);
>>> ?>
>>>
>>
>> The C language spec makes this clear.
>>
>> The result of 1 << 32 will be 4,294,967,206.
>> Now, if INT_MAX is defined to be a smaller value, then the program has
>> performed "undefined behavior", and the standard provides no constraints
>> on what happens after that point.
>>
> 
> In my compiler, the output is 0.  And it is ANSI compliant.

Which says that INT_MAX must be less than 4,294,967,206 and thus the
program has invoked undefined behavior so ANY output (including no
output) is compliant. This is clearly specified in the standard.

<snip>

>> YOU made the claim that PHP is rigorously defined. Person making
>> assertion tends to have burden of proof. Lack of definition would be an
>> indication that it is NOT so rigorously defined.
>>
> 
> YOU made the first assertion - that PHP is NOT rigorously defined.  So,
> according to your "rules", you have to prove it - which you have not.
> 

This is easy.

Rigorous: severely exact or accurate; precise.
Thus to be rigorously defined, a language needs a severely exact or
accurate description of what the language is and what results of every
valid program will be.

For computer languages, this is traditionally done with formal
specifications and grammars. PHP does NOT provide us with one. (It is
hard to prove the non-existence of something, but a determined search of
the site does not reveal one, of course, it would be easy to disprove
this statement by pointing it the location of it).

I will agree that a formal grammar isn't absolutely required for a
rigorous definition, if enough care was taken to FULLY describe every
condition in a less formal manner. This clearly has not happened, as the
statement that caused all this discussion is not CLEARLY spelled out in
the documentation.

Namely, why does the statement
!$a && $a = 42;

bind the $a variable to the = operator even though the && operator has a
higher precedence?

Again, proof of absence is impossible, but a search of the documentation
does not find anything that defines this, further evidenced by that fact
that NO ONE in this thread has offered a statement from the
documentation that clearly indicates that this is how it must work.

THUS, it is proved, PHP is not rigorously defined.

<snip>
>> Actually, the specification DOES say what happens, the program has
>> invoked undefined behavior, and any further actions are beyond the scope
>> of the standard. This IS a precise statement, it may not be real useful
>> to the programmer figure out predict what will happen, but it does
>> provide "rules of engagement" for writing programs. The programmer
>> promises to make sure the code doesn't invoke undefined behavior, and
>> the standard(s) will define what the program does.
>>
> 
> Actually, no, the specification does not say specifically what happens
> in a case such as j = i++ + ++i;  That is why the operation is
> "undefined" - because nothing in the spec defines what should happen.
> 
This is a non-sense statement. The C standard specifically defines the
results, using a specifically defined term, "undefined behavior".

Standards define a form of contract, that if the programmer follows a
few basic requirements, the standard will define what are the expected
results of the program. In C, one of those requirements is that the
program will not generate "undefined behavior". In essence, once a
program performs undefined behavior, the standard washes it hands of
what will result.

<snip>

>>
>> IF you want to claim that PHP is as rigorously defined as a language
>> like C, then perhaps your problem is you don't understand what rigorous
>> really means, and where it is useful in defining things.
>>
> 
> I understand exactly what rigorous means.  But you obviously think it
> means "in arcane and hard to understand language".  It does not.
> 

Rigor requires precision, something MUCH harder to do in conversational
language than in something more "precise". Formal grammars tend to be
much easier to be precise, and to verify that you have been complete.

>> PHP is NOT "rigorously" defined, its documentation is predominately
>> "natural language" based, not on formal grammar. This does have
>> advantages for the "common" programmer, making it easier to learn the
>> basics of the language, but does leave some minor details, which aren't
>> normally important poorly defined. Since PHP is predominately a "single
>> implementation language", it can get away with this.
>>
> 
> And how does the language used make it not "rigorously defined".  Prove
> your statement - according to your rules.
> 

See above.

>> One other effect of this is that in PHP, it is possible to file a
>> "documentation bug" for the documentation differing from how the
>> compiler operates. (this might result in a documentation change, or it
>> might be determined that it really is a program bug). With a formal
>> language, the only "bugs" that could be filed against the standard would
>> be a case where the documentation was in conflict with itself, otherwise
>> and discrepancy between the documentation and an implementation is, by
>> definition, a non-conformity in the implementation.
>>
> 
> It's also possible to file a "documentation bug" with ANSI
> documentation, also.  It's handled differently, but ANSI understands
> that even its documentation can have errors.
>

As I said, a defect report can be filed for cases where the standard is
in conflict with itself or is unclear or ambiguous. These are errors in
the standard.

A defect report can NOT be filed because the standard says something is
to be done different than it is, or is wanted to be. These are NOT
"Defects" in the standard. A difference in behavior between an
implementation and what the standard requires is ALWAYS a non-conformity
of the implementation, and not an "error" in the standard (assuming it
isn't something in the standard being contradictory, etc).

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.php

csiph-web