FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » Operator precedence
Show: Today's Messages :: Unread Messages :: Polls :: Message Navigator
| Subscribe to topic | Remove from bookmarks 
Switch to threaded view of this topic Create a new topic Submit Reply
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Re: Operator precedence [message #185078 is a reply to message #185065] Tue, 25 February 2014 16:08 Go to previous messageGo to next message
Ben Bacarisse is currently offline  Ben Bacarisse
Messages: 82
Registered: November 2013
Karma: 0
Member
add to buddy list
ignore all messages by this user
Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:

> On 2/25/2014 11:56 AM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
>>
>>> On 2/24/2014 11:32 PM, Ben Bacarisse wrote:
>>>> Jerry Stuckle <jstucklex(at)attglobal(dot)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.
Message by Christoph Michael Bec is ignored  [reveal message]  [reveal all messages by Christoph Michael Bec]  [stop ignoring this user] Go to previous messageGo to next message
Message by Christoph Michael Bec is ignored  [reveal message]  [reveal all messages by Christoph Michael Bec]  [stop ignoring this user] Go to previous messageGo to next message
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Re: Operator precedence [message #185082 is a reply to message #185032] Tue, 25 February 2014 16:45 Go to previous messageGo to next message
GS is currently offline  GS
Messages: 3
Registered: February 2014
Karma: 0
Junior Member
add to buddy list
ignore all messages by this user
Thomas 'PointedEars' Lahn <PointedEars(at)web(dot)de> wrote:

> Ben Bacarisse wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars(at)web(dot)de> writes:
>>> Ben Bacarisse wrote:
>>>> […] Expressions are built from operators, but is ',' an operator
>>>> in PHP? It appears in the operator precedence table but it isn't an
>>>> operator in an sense that would normally be understood by someone
>>>> familiar with these terms.
>>>
>>> ECMAScript has a “Comma Operator”, too.
>>
>> But my point was the PHP doesn't have one --
>
> But it does:
>
> for ($i = 0, $j = 42; $i < $j; ++$i);
> ^

The comma serves as a separator here, not an operator. It's just
separating items in a list in the same way you do with arguments in a
function call. I think the reason it's in the operator table is just to
clarify that expressions in a list don't need to be bracketed since all
real operators bind more tightly than "," (as you'd expect).

Formally, an operator is just a function which uses infix notation for
its arguments, ie. semantically a OP b = OP(a,b). In fact, some
languages let you define your own operators in exactly the same way as
you do functions. So things like , and ; are not operators (in PHP
anyway) since unlike stuff such as + or > they don't denote functions
which operate on their operands.

The only reason we have operators at all in programming languages is
because the infix notation is familiar and saves us from the LISP hell
of endlessly bracketing everything. Most people find a+b/c easier on
the eye than +(a,/(b,c)). The drawback of the infix notation is it
creates ambiguities that have to be resolved in the language definition
e.g. by assigning a precedence to every operator, or stipulating linear
evaluation, or requiring that every expression containing more than one
operator be bracketed.

This brings us back to what started this thread, namely that in order to
understand the meaning of a PHP expression you need a formal definition
of how expressions are evaluated, including precedence rules. The
existence of a "but..." in the operator precedence documentation subtley
reveals that the formal definition of a PHP expression is not what we
might have thought it to be, as has since been clarified by those
posters who have looked at the source code.

Looking again at the Language Reference page, "Expressions", I think my
original comment that it does not define what an expression is (for
Jerry's benefit I should say "what a PHP expression is"!) still stands.
It gives several examples but falls short of a formal definition which
would tell us whether or not we can use constructions like !$a && $a =
42.
Message by Christoph Michael Bec is ignored  [reveal message]  [reveal all messages by Christoph Michael Bec]  [stop ignoring this user] Go to previous messageGo to next message
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Re: Operator precedence [message #185089 is a reply to message #185080] Tue, 25 February 2014 18:15 Go to previous messageGo to next message
Ben Bacarisse is currently offline  Ben Bacarisse
Messages: 82
Registered: November 2013
Karma: 0
Member
add to buddy list
ignore all messages by this user
Christoph Michael Becker <cmbecker69(at)arcor(dot)de> writes:

> Ben Bacarisse wrote:
>
>> Jerry Stuckle <jstucklex(at)attglobal(dot)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.
Re: Object constructors/destructors [message #185090 is a reply to message #185085] Tue, 25 February 2014 18:22 Go to previous messageGo to next message
Adam Harvey is currently offline  Adam Harvey
Messages: 25
Registered: September 2010
Karma: 0
Junior Member
add to buddy list
ignore all messages by this user
On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote:
> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote:
>> I firmly believe that it wouldn't make sense to call a (user-defined)
>> constructor when unserializing or cloning an object. A constructor
>> usually serves to initialize an object -- what already had happened in
>> both cases.
>>
>>
> It makes perfect sense. Not everything is necessarily valid in the new
> object. For instance, a logging object may require opening the log
> file. There are many instances where a resource is no longer available
> and needs to be recreated.

Indeed, which is why PHP provides the Serializable interface (and, for BC
reasons, also __sleep and __wakeup) to allow those sorts of
reinitialisation tasks.

I agree with Christoph: since the object is already instantiated, it
doesn't logically make sense to call the constructor once again.

>> Jerry Stuckle wrote:
>>> I know of no other OO language which would allow this.
>>
>> Others may.
>>
>>
> None that I know of. Please name one.

Python's pickle operates the same way:
http://docs.python.org/2/library/pickle.html#object.__getinitargs__

Providing a way to instantiate objects without calling the constructor
does have valid uses (mostly for testing), which is why PHP 5.4 and later
versions also provide a way to do so via reflection (avoiding the
unserialize() hack):
http://php.net/reflectionclass.newinstancewithoutconstructor

Adam
Message by Christoph Michael Bec is ignored  [reveal message]  [reveal all messages by Christoph Michael Bec]  [stop ignoring this user] Go to previous messageGo to next message
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Re: Object constructors/destructors [message #185096 is a reply to message #185081] Wed, 26 February 2014 07:50 Go to previous messageGo to next message
Richard Damon is currently offline  Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
Member
add to buddy list
ignore all messages by this user
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.
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Message by Christoph Michael Bec is ignored  [reveal message]  [reveal all messages by Christoph Michael Bec]  [stop ignoring this user] Go to previous messageGo to next message
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Message by Christoph Michael Bec is ignored  [reveal message]  [reveal all messages by Christoph Michael Bec]  [stop ignoring this user] Go to previous messageGo to next message
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Message by Christoph Michael Bec is ignored  [reveal message]  [reveal all messages by Christoph Michael Bec]  [stop ignoring this user] Go to previous messageGo to next message
Re: Object constructors/destructors [message #185115 is a reply to message #185105] Wed, 26 February 2014 19:00 Go to previous messageGo to next message
Thomas 'PointedEars'  is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
Christoph Michael Becker wrote:

> Jerry Stuckle wrote:
>> On 2/25/2014 6:22 PM, Adam Harvey wrote:
>>> On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote:
>>>> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote:
>>>> > Jerry Stuckle wrote:
>>>> >> I know of no other OO language which would allow this.
>>>> >
>>>> > Others may.
>>>> >
>>>> None that I know of. Please name one.
>>>
>>> Python's pickle operates the same way:
>>> http://docs.python.org/2/library/pickle.html#object.__getinitargs__
>>>
>>> Providing a way to instantiate objects without calling the constructor
>>> does have valid uses (mostly for testing), which is why PHP 5.4 and
>>> later versions also provide a way to do so via reflection (avoiding the
>>> unserialize() hack):
>>> http://php.net/reflectionclass.newinstancewithoutconstructor
>>
>> Not knowing Python, I can't say. But if it is a true object, then they
>> are also violating OO principles.
>>
>> OO demands creation of a new object requires a constructor call.
>> Period.
>
> Do you understand, what's the purpose of a constructor? It is there to
> *initialize* an instance. If there is nothing to initialize, it is not
> strictly necessary to call any constructor.

A constructor does not need to mean initialization; primarily it means
*instantiation*: creating an object and, optionally, creating a relation
between it and another object (in the general sense) it inherits from.
However, both instantiation and initialization also can be done by a factory
method. Factory is one of the GoF design patterns, and it does not violate
principles of OOP at all (those people *literally* wrote the book on OOP).
A factory is a function, usually (but not necessarily) a static method, that
returns (a reference to) an object.¹

Speaking of Python, ISTM that it has generalized the Factory pattern so that
both the concept of constructor and the keyword “new” become unnecessary (so
that “new” is not a keyword or reserved word at all) there: A class can be
called like a function – e.g., Class() –, which invokes the __init__()
method of the class if defined, for initialization, and passes to it the
parameters passed to the class/constructor call; otherwise it just
instantiates that class, returning a reference to the instance. (However,
initialization of the instance not dependent on parameters of the
instantiation can also be done in the class code itself.)

$ python3
Python 3.3.5rc1 (default, Feb 23 2014, 19:47:14)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> new = 2
>>> class Class(object): pass
....
>>> Class
<class '__main__.Class'>
>>> Class()
<__main__.Class object at 0xb718d04c>

See also <http://docs.python.org/3/tutorial/classes.html#a-first-look-at-classes>

> But anyway, unserializing an object is *not* creating a new object.

IBTD. However, as we will see soon, it is largely irrelevant that
unserializing *necessarily* creates a new object. Because the relation
between an object and the object it inherits from is just data that can
be stored, and later retrieved to restore that relation, much like a
constructor initially does.

The only important thing is that the relevant parts of the code that
serialized the object and that unserialize data to restore the object must
be identical; otherwise the restored state is not functionally
indistinguishable to the original state of the object. (WLOG, that is the
case as the serializing and unserializing code are the same and are running
in the same or at least a compatible environment.)

> Consider a class man. When a new object is instantiated the constructor
> is called to initialize the person with respective properties (e.g. age
> = 0). Later this man goes to sleep (serialize); after he wakes up
> (unserialize) the constructor is not called again, as this would reset
> the man to his initial properties, and surely after a good night of
> sleep one may feel younger, but the age has not been reset.

That is a really good analogy. (Too bad that Jerry did not understand it.)
It points out that, basically, an object is a collection of data, and
methods to operate on/with that data. WLOG, data is serializable, and
methods are inherited from another object (in the general sense; in class-
based OOP: a class). The relation to that other object again is just data.²
Data can be stored in different forms, and retrieved. Therefore, an object
can be restored to its previous state, or at least to a state that is
functionally indistinguishable from its previous state, without calling a
constructor.

$ php -r '
class C implements Serializable
{
private $_data = 42;

function serialize()
{
return serialize($this->_data);
}

function unserialize ($serialized)
{
echo "\$serialized = "; var_dump($serialized);

$this->_data = unserialize($serialized);
}
};

$c = new C();

echo "\$c = "; var_dump($c);

$s = serialize($c);

echo "\$s = "; var_dump($s);

$c = unserialize($s);

echo "\$c = "; var_dump($c);
'
class C#1 (1) {
private $_data =>
int(42)
}
string(17) "C:1:"C":5:{i:42;}"
string(5) "i:42;"
class C#2 (1) {
private $_data =>
int(42)
}


PointedEars
___________
¹ Those who object to considering a mere function OOP should read the
ECMAScript Language Specification, which shows that every function can be
made a method of an object; especially, globally declared functions are
methods of a global object.
² Even if a method is not inherited (which cannot happen in PHP) it would
be possible to serialize it as it is just code. However, this is not
always possible by means of the language itself instead of the core
language implementation.
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(at)news(dot)demon(dot)co(dot)uk> (2004)
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Re: Object constructors/destructors [message #185118 is a reply to message #185097] Wed, 26 February 2014 23:49 Go to previous messageGo to next message
Richard Damon is currently offline  Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
Member
add to buddy list
ignore all messages by this user
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.
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Message by Christoph Michael Bec is ignored  [reveal message]  [reveal all messages by Christoph Michael Bec]  [stop ignoring this user] Go to previous messageGo to next message
Re: Object constructors/destructors [message #185125 is a reply to message #185117] Thu, 27 February 2014 12:29 Go to previous messageGo to next message
Thomas 'PointedEars'  is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
Jerry Stuckle wrote:

> On 2/26/2014 7:00 PM, Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> Jerry Stuckle wrote:
>>>> On 2/25/2014 6:22 PM, Adam Harvey wrote:
>>>> > On Tue, 25 Feb 2014 17:01:52 -0500, Jerry Stuckle wrote:
>>>> >> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote:
>>>> >>> Jerry Stuckle wrote:
>>>> >>>> I know of no other OO language which would allow this.
>>>> >>> Others may.
>>>> >> None that I know of. Please name one.
>>>> >
>>>> > Python's pickle operates the same way:
>>>> > http://docs.python.org/2/library/pickle.html#object.__getinitargs__
>>>> >
>>>> > Providing a way to instantiate objects without calling the constructor
>>>> > does have valid uses (mostly for testing), which is why PHP 5.4 and
>>>> > later versions also provide a way to do so via reflection (avoiding
>>>> > the unserialize() hack):
>>>> > http://php.net/reflectionclass.newinstancewithoutconstructor
>>>>
>>>> Not knowing Python, I can't say. But if it is a true object, then they
>>>> are also violating OO principles.
>>>>
>>>> OO demands creation of a new object requires a constructor call.
>>>> Period.
>>>
>>> Do you understand, what's the purpose of a constructor? It is there to
>>> *initialize* an instance. If there is nothing to initialize, it is not
>>> strictly necessary to call any constructor.
>>
>> A constructor does not need to mean initialization; primarily it means
>> *instantiation*: creating an object and, optionally, creating a relation
>> between it and another object (in the general sense) it inherits from.
>> However, both instantiation and initialization also can be done by a
>> factory method. Factory is one of the GoF design patterns, and it does
>> not violate principles of OOP at all (those people *literally* wrote the
>> book on OOP). A factory is a function, usually (but not necessarily) a
>> static method, that returns (a reference to) an object.¹
>
> Incorrect (as usual). The constructor is designed to initialize an
> object. In OO programming, an object is always valid, or, if not valid,
> refuses any operations which depend on the object being valid.

At this point I would refer you to “Design Patterns. Elements of Reusable
Object-Oriented Software” (ISBN 3-8273-2199-9) if I not already knew that
you knew everything that is to know about OOP :->

> A factory is only a means of instantiating the object.

No, it can initialize the object, too. I have already given an example *in
PHP*; you are not paying attention.

> It does not replace or preclude the constructor being called.

Nobody said it would.

> [tl;dr Jerry's further misconceptions]


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Message by Christoph Michael Bec is ignored  [reveal message]  [reveal all messages by Christoph Michael Bec]  [stop ignoring this user] Go to previous messageGo to next message
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Message by Christoph Michael Bec is ignored  [reveal message]  [reveal all messages by Christoph Michael Bec]  [stop ignoring this user] Go to previous messageGo to next message
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Re: Object constructors/destructors [message #185140 is a reply to message #185121] Sat, 01 March 2014 12:56 Go to previous messageGo to next message
Richard Damon is currently offline  Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
Member
add to buddy list
ignore all messages by this user
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.
Re: Operator precedence [message #185141 is a reply to message #185056] Sat, 01 March 2014 13:39 Go to previous messageGo to next message
Richard Damon is currently offline  Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
Member
add to buddy list
ignore all messages by this user
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.
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Re: Object constructors/destructors [message #185147 is a reply to message #185142] Sun, 02 March 2014 14:28 Go to previous messageGo to next message
Richard Damon is currently offline  Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
Member
add to buddy list
ignore all messages by this user
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.)
Re: Operator precedence [message #185148 is a reply to message #185143] Sun, 02 March 2014 15:22 Go to previous messageGo to next message
Richard Damon is currently offline  Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
Member
add to buddy list
ignore all messages by this user
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).
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to previous message
Quick Reply
Formatting Tools:   
Pages (3): [ «    1  2  3    »]  Switch to threaded view of this topic Create a new topic
Previous Topic: Correlating curl resources to some other object.
Next Topic: Experienced Web designer required
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Wed Jun 19 21:39:38 EDT 2024

Total time taken to generate the page: 0.05676 seconds