| Re: Operator precedence [message #185150 is a reply to message #185148] |
Sun, 02 March 2014 20:49   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 3/2/2014 3:22 PM, Richard Damon wrote:
> 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.
>
Then you can't say that PHP is not rigorously defined.
> 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.
>
There are many undefined operations and expressions in other languages
such as C, C++ and java, also. The spec only needs to define what CAN
be done - not what CANNOT be done.
If you think there is an error in the documentation, then file a bug
report against the doc.
> <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 what CAN be done, not what CANNOT be done. If you
follow the spec as to what CAN be done, then the behavior of your
program is defined. If you do not follow the spec, then the behavior of
your program is undefined.
> 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>
>
Exactly. You do not use expressions which are not defined by the spec.
>>>
>>> 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.
>
Which does not mean it cannot be done. A spec does not need to be hard
to read to be rigorous.
>>> 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.
>
You have not proven anything. All you say is that since the PHP spec is
easy to read, PHP is not rigorously defined. I happen to disagree with
that statement.
If you follow the doc, your program will behave as expected. If you
think there is an error in the doc, then you need to file a bug report.
>>> 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).
>
>
I did not say you can file a defect because the standard says something
is to be done different than it is. However, since ZEND is in charge of
the doc and the language, you can file a bug report - and they will
decide whether the language or the doc is wrong.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Object constructors/destructors [message #185152 is a reply to message #185149] |
Sun, 02 March 2014 22:14 |
Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
|
Member |
|
|
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.
|
|
|
|
| Re: Object constructors/destructors [message #185153 is a reply to message #185152] |
Sun, 02 March 2014 22:48 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Object constructors/destructors [message #185154 is a reply to message #185153] |
Sun, 02 March 2014 23:05 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <lf0cgi$c21$1(at)dont-email(dot)me>, Jerry Stuckle
<jstucklex(at)attglobal(dot)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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]