Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #12889 > unrolled thread
| Started by | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| First post | 2014-02-23 18:03 +0100 |
| Last post | 2014-02-24 14:28 +0100 |
| Articles | 20 on this page of 84 — 8 participants |
Back to article view | Back to comp.lang.php
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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-02-25 04:45 +0000 |
| Message-ID | <0.3af1a24cc7c6e5125c15.20140225044517GMT.878uszreaq.fsf@bsb.me.uk> |
| In reply to | #12948 |
Thomas 'PointedEars' Lahn <PointedEars@web.de> writes: > Ben Bacarisse wrote: > >> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes: >>> Ben Bacarisse wrote: >>>> Thomas 'PointedEars' Lahn <PointedEars@web.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); >> >> But try this: >> >> for (($i = 0, $j = 42); $i < $j; ++$i); > > Bogus example. > >> In general, putting an expression in parentheses does not stop it being >> an expression. This is why it's not bogus. By all means explain why your understanding of what an operator permits the construction of something that is not an expression, but don't just say "bogus". I contend that for ',' to be an operator, it should form part of an expression, and I contend that expressions can be put in parentheses and remain expressions. You can challenge either notion, but then I think we will be disagreeing only about definitions. <snip> >>> Please define what you consider to be an operator in a “normal sense of >>> the word”. >> >> It's a syntactic symbol that can be used to combine simpler expressions >> in such a way that the result is also, syntactically, an expression. > > A very narrow definition of “operator”. Maybe, but it comports with what PHP considers to be an operator: "An operator is something that takes one or more values (or expressions, in programming jargon) and yields another value (so that the construction itself becomes an expression)." If you have a different definition, we could just agree on the fact that PHP has no ',' operator as PHP defines the term. What is your definition? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | GS <nomail@nospam.org.invalid> |
|---|---|
| Date | 2014-02-25 21:45 +0000 |
| Message-ID | <XnsA2DFDD5A74418R2D2@127.0.0.1> |
| In reply to | #12930 |
Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote: > Ben Bacarisse wrote: > >> Thomas 'PointedEars' Lahn <PointedEars@web.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.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-24 07:00 -0500 |
| Message-ID | <lefc8a$7ki$1@dont-email.me> |
| In reply to | #12913 |
On 2/23/2014 11:49 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 2/23/2014 6:36 PM, Richard Damon wrote: >>> On 2/23/14, 4:34 PM, Jerry Stuckle wrote: >>>> On 2/23/2014 2:42 PM, GS wrote: >>>>> This shows one of the major problems with PHP: there is no formal >>>>> language >>>>> definition, you have to go by examples in the help file to intuit what is >>>>> or is not valid. Where is the BNF definition of the language? There is >>>>> none >>>>> AFAICT. >>>>> >>>> Incorrect. There is a formal definition, as indicated in the doc at >>>> www.php.net. >>>> >>> Do you have a pointer to where "expression" is precisely defined (other >>> than reading code). >> >> Try any Introduction to Programming book. Documentation (not just >> PHP) does not normally define commonly used terms. > > I don't think it's that clear cut. 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. > It is an operator, as indicated by its appearance in the table of operators. Operators are not limited to +-*/. > <snip> >>> That doesn't mean it isn't powerful, or useful, or the right tool to use >>> in some places, but does say that it lacks some formal rigor. >> >> Once again, incorrect. >> >>> The lack of formal rigor says that there are some questions which just >>> can't be answered by reading the language documentation. >> >> It can if you have a basic understanding of programming. > > Again, I don't think it's that simple. How would you determine if the > following program is permitted and, if it is, what it does? > > if (false) label: else echo "else\n"; > goto label; > > You could try it, of course, but that's hardly very formal. > 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. >>> The original question was a good example of this. the assignment >>> operator is described as having a precedence (fairly low) just like all >>> other operators, with some vague comments that it is done in a way that >>> certain things just work. In comments on looking at the code, the left >>> operand of assignment is a variable, and not an expression, effectively >>> giving assignment a very high precedence to the left, and a very low >>> precedence to the right (if the grammar even does end up being actually >>> describable precisely with precedence). To my knowledge, this detail is >>> NOT formally presented in the documentation. >> >> No, the original question shows a basic lack of knowledge of terms >> used in programming. As does your argument. > > This puzzles me. What basic knowledge would have cleared up the > original question? > The definition of "expression". It's something covered in our "Introduction to Programming" course - which does not cover any language, only the basic process. > 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. > 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. But it does mean you are trolling. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-24 18:11 +0100 |
| Message-ID | <530b7d38$0$9508$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #12915 |
Jerry Stuckle wrote: > On 2/23/2014 11:49 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 2/23/2014 6:36 PM, Richard Damon wrote: >>>> The original question was a good example of this. the assignment >>>> operator is described as having a precedence (fairly low) just like all >>>> other operators, with some vague comments that it is done in a way that >>>> certain things just work. In comments on looking at the code, the left >>>> operand of assignment is a variable, and not an expression, effectively >>>> giving assignment a very high precedence to the left, and a very low >>>> precedence to the right (if the grammar even does end up being actually >>>> describable precisely with precedence). To my knowledge, this detail is >>>> NOT formally presented in the documentation. >>> >>> No, the original question shows a basic lack of knowledge of terms >>> used in programming. As does your argument. >> >> This puzzles me. What basic knowledge would have cleared up the >> original question? >> > > The definition of "expression". It's something covered in our > "Introduction to Programming" course - which does not cover any > language, only the basic process. Would you mind stating your definition of "expression" here? -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-24 14:27 -0500 |
| Message-ID | <leg6f0$bkk$1@dont-email.me> |
| In reply to | #12920 |
On 2/24/2014 12:11 PM, Christoph Michael Becker wrote: > Jerry Stuckle wrote: > >> On 2/23/2014 11:49 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 2/23/2014 6:36 PM, Richard Damon wrote: >>>>> The original question was a good example of this. the assignment >>>>> operator is described as having a precedence (fairly low) just like all >>>>> other operators, with some vague comments that it is done in a way that >>>>> certain things just work. In comments on looking at the code, the left >>>>> operand of assignment is a variable, and not an expression, effectively >>>>> giving assignment a very high precedence to the left, and a very low >>>>> precedence to the right (if the grammar even does end up being actually >>>>> describable precisely with precedence). To my knowledge, this detail is >>>>> NOT formally presented in the documentation. >>>> >>>> No, the original question shows a basic lack of knowledge of terms >>>> used in programming. As does your argument. >>> >>> This puzzles me. What basic knowledge would have cleared up the >>> original question? >>> >> >> The definition of "expression". It's something covered in our >> "Introduction to Programming" course - which does not cover any >> language, only the basic process. > > Would you mind stating your definition of "expression" here? > I don't think you want MY definition. That will just cause another argument. Why don't you look up the common definition of "expression"? I'm sure you know how to use Google. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-25 01:25 +0100 |
| Message-ID | <530be2e6$0$9512$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #12923 |
Jerry Stuckle wrote: > On 2/24/2014 12:11 PM, Christoph Michael Becker wrote: >> Jerry Stuckle wrote: >> >>> On 2/23/2014 11:49 PM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 2/23/2014 6:36 PM, Richard Damon wrote: >>>>>> The original question was a good example of this. the assignment >>>>>> operator is described as having a precedence (fairly low) just >>>>>> like all >>>>>> other operators, with some vague comments that it is done in a way >>>>>> that >>>>>> certain things just work. In comments on looking at the code, the >>>>>> left >>>>>> operand of assignment is a variable, and not an expression, >>>>>> effectively >>>>>> giving assignment a very high precedence to the left, and a very low >>>>>> precedence to the right (if the grammar even does end up being >>>>>> actually >>>>>> describable precisely with precedence). To my knowledge, this >>>>>> detail is >>>>>> NOT formally presented in the documentation. >>>>> >>>>> No, the original question shows a basic lack of knowledge of terms >>>>> used in programming. As does your argument. >>>> >>>> This puzzles me. What basic knowledge would have cleared up the >>>> original question? >>>> >>> >>> The definition of "expression". It's something covered in our >>> "Introduction to Programming" course - which does not cover any >>> language, only the basic process. >> >> Would you mind stating your definition of "expression" here? >> > > I don't think you want MY definition. That will just cause another > argument. Why don't you look up the common definition of "expression"? > I'm sure you know how to use Google. Well, you have claimed that my original question shows a basic lack of knowledge of terms used in programming", and that the definition of "expression", what's covered in your "Introduction to Programming" course would have cleared up my question. So stating this definition here would be helpful, won't it? Otherwise it occurs to me that you've made a claim that you can't prove. -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-24 20:40 -0500 |
| Message-ID | <legsb4$d93$1@dont-email.me> |
| In reply to | #12935 |
On 2/24/2014 7:25 PM, Christoph Michael Becker wrote: > Jerry Stuckle wrote: > >> On 2/24/2014 12:11 PM, Christoph Michael Becker wrote: >>> Jerry Stuckle wrote: >>> >>>> On 2/23/2014 11:49 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> On 2/23/2014 6:36 PM, Richard Damon wrote: >>>>>>> The original question was a good example of this. the assignment >>>>>>> operator is described as having a precedence (fairly low) just >>>>>>> like all >>>>>>> other operators, with some vague comments that it is done in a way >>>>>>> that >>>>>>> certain things just work. In comments on looking at the code, the >>>>>>> left >>>>>>> operand of assignment is a variable, and not an expression, >>>>>>> effectively >>>>>>> giving assignment a very high precedence to the left, and a very low >>>>>>> precedence to the right (if the grammar even does end up being >>>>>>> actually >>>>>>> describable precisely with precedence). To my knowledge, this >>>>>>> detail is >>>>>>> NOT formally presented in the documentation. >>>>>> >>>>>> No, the original question shows a basic lack of knowledge of terms >>>>>> used in programming. As does your argument. >>>>> >>>>> This puzzles me. What basic knowledge would have cleared up the >>>>> original question? >>>>> >>>> >>>> The definition of "expression". It's something covered in our >>>> "Introduction to Programming" course - which does not cover any >>>> language, only the basic process. >>> >>> Would you mind stating your definition of "expression" here? >>> >> >> I don't think you want MY definition. That will just cause another >> argument. Why don't you look up the common definition of "expression"? >> I'm sure you know how to use Google. > > Well, you have claimed that my original question shows a basic lack of > knowledge of terms used in programming", and that the definition of > "expression", what's covered in your "Introduction to Programming" > course would have cleared up my question. So stating this definition > here would be helpful, won't it? > > Otherwise it occurs to me that you've made a claim that you can't prove. > No, I'm not going to fall for your trolling. I told you it was a basic lack of knowledge of terms. Then I suggested you look up the terms yourself. If I give you my definition, it will just give you another excuse to troll. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-02-24 21:23 +0000 |
| Message-ID | <0.176fb73a1430ceabf46e.20140224212342GMT.87y510qk69.fsf@bsb.me.uk> |
| In reply to | #12915 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 2/23/2014 11:49 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 2/23/2014 6:36 PM, Richard Damon wrote: >>>> On 2/23/14, 4:34 PM, Jerry Stuckle wrote: >>>>> On 2/23/2014 2:42 PM, GS wrote: >>>>>> This shows one of the major problems with PHP: there is no formal >>>>>> language >>>>>> definition, you have to go by examples in the help file to intuit what is >>>>>> or is not valid. Where is the BNF definition of the language? There is >>>>>> none >>>>>> AFAICT. >>>>>> >>>>> Incorrect. There is a formal definition, as indicated in the doc at >>>>> www.php.net. >>>>> >>>> Do you have a pointer to where "expression" is precisely defined (other >>>> than reading code). >>> >>> Try any Introduction to Programming book. Documentation (not just >>> PHP) does not normally define commonly used terms. >> >> I don't think it's that clear cut. 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. > > It is an operator, as indicated by its appearance in the table of > operators. Operators are not limited to +-*/. I am familiar with languages that have a ',' operator, which is why I brought it up. Normally, combining expressions with an operator makes a new expression, but that's not true in PHP for the comma. For example, f() and g() are expressions, but (f(), g()) is not. That's why, presumably, there is no description of what it does in the section on operators -- it isn't one! <snip> >>>> The lack of formal rigor says that there are some questions which just >>>> can't be answered by reading the language documentation. >>> >>> It can if you have a basic understanding of programming. >> >> Again, I don't think it's that simple. How would you determine if the >> following program is permitted and, if it is, what it does? >> >> if (false) label: else echo "else\n"; >> goto label; >> >> You could try it, of course, but that's hardly very formal. > > What language gives every possible way for you to screw up your > programming? You seemed to be disagreeing with the statement that there are some questions which just can't be answered by reading the language documentation. All I was doing was giving an example of a question I could not answer from the documentation. I agree it's very much a corner case (and many not worth an answer) but there are other such questions. For example, from the documentation alone I can't explain why ($i++, $j++) is not a valid expression, given that it appears to consist of brackets and operators and variables, all put together in the usual way. > If you want to find out how some screwed-up code works in ANY > language, you try it and find out. That's a flawed method. If I have an algorithm that shifts bits about, but sometimes shifts them *all* out, how can I be sure what 1 << PHP_INT_SIZE*8 really does? If I test it, and it does what I want, can I be sure that on some other hardware it will do the same? Does PHP define the meaning of this expression, or does it leave it open (and possibly up to what the hardware does)? <snip> >> 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. I never suggested otherwise. However, in more rigorously defined languages you can find out what combinations are permitted from the specification. With PHP, I often end up just trying things because I can't find the answer in the documentation. I then assume that what happens now is what will always happen -- i.e. that the reference implementation is the specification. >> 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. I think that's exactly what it means. > But it does mean you are trolling. Eh? This whole thread is an interesting technical discussion about the degree to which PHP programs are well-defined. If you really think my contributions are trolling, you know the well-worn advice: don't feed me. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-24 16:45 -0500 |
| Message-ID | <legehm$286$1@dont-email.me> |
| In reply to | #12926 |
On 2/24/2014 4:23 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 2/23/2014 11:49 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 2/23/2014 6:36 PM, Richard Damon wrote: >>>>> On 2/23/14, 4:34 PM, Jerry Stuckle wrote: >>>>>> On 2/23/2014 2:42 PM, GS wrote: >>>>>>> This shows one of the major problems with PHP: there is no formal >>>>>>> language >>>>>>> definition, you have to go by examples in the help file to intuit what is >>>>>>> or is not valid. Where is the BNF definition of the language? There is >>>>>>> none >>>>>>> AFAICT. >>>>>>> >>>>>> Incorrect. There is a formal definition, as indicated in the doc at >>>>>> www.php.net. >>>>>> >>>>> Do you have a pointer to where "expression" is precisely defined (other >>>>> than reading code). >>>> >>>> Try any Introduction to Programming book. Documentation (not just >>>> PHP) does not normally define commonly used terms. >>> >>> I don't think it's that clear cut. 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. >> >> It is an operator, as indicated by its appearance in the table of >> operators. Operators are not limited to +-*/. > > I am familiar with languages that have a ',' operator, which is why I > brought it up. Normally, combining expressions with an operator makes a > new expression, but that's not true in PHP for the comma. For example, > f() and g() are expressions, but (f(), g()) is not. That's why, > presumably, there is no description of what it does in the section on > operators -- it isn't one! > Documentation indicates what you CAN do - not what you CAN'T do. This is true of languages, databases, spreadsheets and about anything else around. > <snip> >>>>> The lack of formal rigor says that there are some questions which just >>>>> can't be answered by reading the language documentation. >>>> >>>> It can if you have a basic understanding of programming. >>> >>> Again, I don't think it's that simple. How would you determine if the >>> following program is permitted and, if it is, what it does? >>> >>> if (false) label: else echo "else\n"; >>> goto label; >>> >>> You could try it, of course, but that's hardly very formal. >> >> What language gives every possible way for you to screw up your >> programming? > > You seemed to be disagreeing with the statement that there are some > questions which just can't be answered by reading the language > documentation. All I was doing was giving an example of a question I > could not answer from the documentation. > See above. > I agree it's very much a corner case (and many not worth an answer) but > there are other such questions. For example, from the documentation > alone I can't explain why ($i++, $j++) is not a valid expression, given > that it appears to consist of brackets and operators and variables, all > put together in the usual way. > See above. Also, this is PHP, not C or C++. >> If you want to find out how some screwed-up code works in ANY >> language, you try it and find out. > > That's a flawed method. If I have an algorithm that shifts bits about, > but sometimes shifts them *all* out, how can I be sure what > > 1 << PHP_INT_SIZE*8 > > really does? If I test it, and it does what I want, can I be sure that > on some other hardware it will do the same? Does PHP define the > meaning of this expression, or does it leave it open (and possibly up to > what the hardware does)? > That is how you test anything. And you can NEVER be sure that ANY operation will work the same when you change compilers/interpreters. You need to be looking at the documentation for the software you're using, not something else. For instance a 32 bit C compiler will have different results than a 64 bit C compiler, even if both are run on a 64 bit machine. And even different 32 bit C compilers can have different output. For instance, in a 32 bit C compiler, an int can be 8, 16, or 32 bits long - all within the specs (which only states the length of an int is >= the length of a short, and <= the length of a long). So it is entirely possible one C compiler will have a 16 bit int, while another has a 32 bit int. And both are within the C spec. And on 64 bit hardware, an int could be 64 bits long. > <snip> >>> 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. > > I never suggested otherwise. However, in more rigorously defined > languages you can find out what combinations are permitted from the > specification. With PHP, I often end up just trying things because I > can't find the answer in the documentation. I then assume that what > happens now is what will always happen -- i.e. that the reference > implementation is the specification. > The PHP doc shows you what combinations are permitted. You are asking about what is NOT permitted. >>> 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. > > I think that's exactly what it means. > Fine. Go ahead and document every possible bad combination of operators. I won't wait up for your results. >> But it does mean you are trolling. > > Eh? This whole thread is an interesting technical discussion about the > degree to which PHP programs are well-defined. If you really think my > contributions are trolling, you know the well-worn advice: don't feed > me. > You claim you understand why things which can't be done are not documented. Then you argue because what you want to try is not documented, and denigrate PHP because it doesn't follow YOUR definition of "rigorously defined". What else would you call it? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-02-25 04:32 +0000 |
| Message-ID | <0.0e19cf148bd81c84c7e8.20140225043254GMT.87eh2rrevd.fsf@bsb.me.uk> |
| In reply to | #12928 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 2/24/2014 4:23 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: <snip> >>> It is an operator, as indicated by its appearance in the table of >>> operators. Operators are not limited to +-*/. >> >> I am familiar with languages that have a ',' operator, which is why I >> brought it up. Normally, combining expressions with an operator makes a >> new expression, but that's not true in PHP for the comma. For example, >> f() and g() are expressions, but (f(), g()) is not. That's why, >> presumably, there is no description of what it does in the section on >> operators -- it isn't one! > > 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: An operator is something that takes one or more values (or expressions, in programming jargon) and yields another value (so that the construction itself becomes an expression). I can't see any usage of ',' that matches this definition. By the manual's own definition, ',' in not an operator in PHP. 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. In extreme cases the distinction disappears, because a language that specifies exactly what can be done, implicitly defines what can't. But n practice it's easier to do a bit of both. For example, you might give a general grammar, and then explain some restrictions, such as what forms are not permitted on the left of an assignment. >> <snip> >>>>>> The lack of formal rigor says that there are some questions which just >>>>>> can't be answered by reading the language documentation. >>>>> >>>>> It can if you have a basic understanding of programming. >>>> >>>> Again, I don't think it's that simple. How would you determine if the >>>> following program is permitted and, if it is, what it does? >>>> >>>> if (false) label: else echo "else\n"; >>>> goto label; >>>> >>>> You could try it, of course, but that's hardly very formal. >>> >>> What language gives every possible way for you to screw up your >>> programming? >> >> You seemed to be disagreeing with the statement that there are some >> questions which just can't be answered by reading the language >> documentation. All I was doing was giving an example of a question I >> could not answer from the documentation. > > See above. So you think my example is of something that can't be done and that is why you can't tell what the code done by > >> I agree it's very much a corner case (and many not worth an answer) but >> there are other such questions. For example, from the documentation >> alone I can't explain why ($i++, $j++) is not a valid expression, given >> that it appears to consist of brackets and operators and variables, all >> put together in the usual way. >> > > See above. Also, this is PHP, not C or C++. > >>> If you want to find out how some screwed-up code works in ANY >>> language, you try it and find out. >> >> That's a flawed method. If I have an algorithm that shifts bits about, >> but sometimes shifts them *all* out, how can I be sure what >> >> 1 << PHP_INT_SIZE*8 >> >> really does? If I test it, and it does what I want, can I be sure that >> on some other hardware it will do the same? Does PHP define the >> meaning of this expression, or does it leave it open (and possibly up to >> what the hardware does)? >> > > That is how you test anything. And you can NEVER be sure that ANY > operation will work the same when you change > compilers/interpreters. You need to be looking at the documentation > for the software you're using, not something else. > > For instance a 32 bit C compiler will have different results than a 64 > bit C compiler, even if both are run on a 64 bit machine. And even > different 32 bit C compilers can have different output. 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. > (which only states the length of an int is >= the > length of a short, and <= the length of a long). So it is entirely > possible one C compiler will have a 16 bit int, while another has a 32 > bit int. And both are within the C spec. Yes, but the language gives minimum guarantees which can be used to permit code to be ported. It also (often) explicitly says where there is no guarantee. For example, shifting right by the width of the type being shifted is explicitly "undefined". It's useful to know that, because you can simply avoid the situation in the first place. That's simpler that testing it, seeing that it does what you expect, and then finding that it fails on some other hardware. > And on 64 bit hardware, an int could be 64 bits long. More surprisingly, so could a char! >> <snip> >>>> 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. >> >> I never suggested otherwise. However, in more rigorously defined >> languages you can find out what combinations are permitted from the >> specification. With PHP, I often end up just trying things because I >> can't find the answer in the documentation. I then assume that what >> happens now is what will always happen -- i.e. that the reference >> implementation is the specification. >> > 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. <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. >> >> I think that's exactly what it means. > > Fine. Go ahead and document every possible bad combination of > operators. I won't wait up for your results. Well, I'd rather not. PHP has a more special cases than other languages I've used, so it would be harder than for those. But I am surprised that that you think it's so unreasonable to expect at least a moderately rigorous definition of what is and is not permitted. As I said before, it seems perfect reasonable to me. Even a grammar for the language (surely not that hard) would have eliminated the OP's question from the get go. >>> But it does mean you are trolling. >> >> Eh? This whole thread is an interesting technical discussion about the >> degree to which PHP programs are well-defined. If you really think my >> contributions are trolling, you know the well-worn advice: don't feed >> me. > > You claim you understand why things which can't be done are not > documented. Then you argue because what you want to try is not > documented, and denigrate PHP because it doesn't follow YOUR > definition of "rigorously defined". I don't recognise any of that. I was making a sound technical point in reply to you: that PHP does not have a ',' operator except in some sort of literalist sense: the manual says it does, so it does, despite the fact that its meaning is undefined and you can't use it in expressions to make bigger expressions. Your counter argument seems to be that the manual is not obliged to document what you can't do. I disagree about that, but even if this is granted, it is surely a mistake to list ',' as an operator when it clearly isn't. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-24 23:47 -0500 |
| Message-ID | <leh78v$tkk$1@dont-email.me> |
| In reply to | #12951 |
On 2/24/2014 11:32 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 2/24/2014 4:23 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: > <snip> >>>> It is an operator, as indicated by its appearance in the table of >>>> operators. Operators are not limited to +-*/. >>> >>> I am familiar with languages that have a ',' operator, which is why I >>> brought it up. Normally, combining expressions with an operator makes a >>> new expression, but that's not true in PHP for the comma. For example, >>> f() and g() are expressions, but (f(), g()) is not. That's why, >>> presumably, there is no description of what it does in the section on >>> operators -- it isn't one! >> >> 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? > An operator is something that takes one or more values (or > expressions, in programming jargon) and yields another value (so that > the construction itself becomes an expression). > > I can't see any usage of ',' that matches this definition. By the > manual's own definition, ',' in not an operator in PHP. > > 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. In extreme cases the distinction disappears, because a > language that specifies exactly what can be done, implicitly defines > what can't. But n practice it's easier to do a bit of both. For > example, you might give a general grammar, and then explain some > restrictions, such as what forms are not permitted on the left of an > assignment. > No, the C specification does NOT say what you cannot do. Some books may add some things you cannot do, but the language itself doesn't. Check it out yourself - it's available at the ANSI website (for a price). Some university and/or technical libraries also have a copy. >>> <snip> >>>>>>> The lack of formal rigor says that there are some questions which just >>>>>>> can't be answered by reading the language documentation. >>>>>> >>>>>> It can if you have a basic understanding of programming. >>>>> >>>>> Again, I don't think it's that simple. How would you determine if the >>>>> following program is permitted and, if it is, what it does? >>>>> >>>>> if (false) label: else echo "else\n"; >>>>> goto label; >>>>> >>>>> You could try it, of course, but that's hardly very formal. >>>> >>>> What language gives every possible way for you to screw up your >>>> programming? >>> >>> You seemed to be disagreeing with the statement that there are some >>> questions which just can't be answered by reading the language >>> documentation. All I was doing was giving an example of a question I >>> could not answer from the documentation. >> >> See above. > > So you think my example is of something that can't be done and that is > why you can't tell what the code done by If it's not documented that you can do it, you can try it and see if it works. But beware that undocumented "features" may or may not act the same way in the next release. >> >>> I agree it's very much a corner case (and many not worth an answer) but >>> there are other such questions. For example, from the documentation >>> alone I can't explain why ($i++, $j++) is not a valid expression, given >>> that it appears to consist of brackets and operators and variables, all >>> put together in the usual way. >>> >> >> See above. Also, this is PHP, not C or C++. >> >>>> If you want to find out how some screwed-up code works in ANY >>>> language, you try it and find out. >>> >>> That's a flawed method. If I have an algorithm that shifts bits about, >>> but sometimes shifts them *all* out, how can I be sure what >>> >>> 1 << PHP_INT_SIZE*8 >>> >>> really does? If I test it, and it does what I want, can I be sure that >>> on some other hardware it will do the same? Does PHP define the >>> meaning of this expression, or does it leave it open (and possibly up to >>> what the hardware does)? >>> >> >> That is how you test anything. And you can NEVER be sure that ANY >> operation will work the same when you change >> compilers/interpreters. You need to be looking at the documentation >> for the software you're using, not something else. >> >> For instance a 32 bit C compiler will have different results than a 64 >> bit C compiler, even if both are run on a 64 bit machine. And even >> different 32 bit C compilers can have different output. 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). >> (which only states the length of an int is >= the >> length of a short, and <= the length of a long). So it is entirely >> possible one C compiler will have a 16 bit int, while another has a 32 >> bit int. And both are within the C spec. > > Yes, but the language gives minimum guarantees which can be used to > permit code to be ported. It also (often) explicitly says where there > is no guarantee. For example, shifting right by the width of the type > being shifted is explicitly "undefined". It's useful to know that, > because you can simply avoid the situation in the first place. That's > simpler that testing it, seeing that it does what you expect, and then > finding that it fails on some other hardware. > The only minimum is that an int must not be smaller than a short. >> And on 64 bit hardware, an int could be 64 bits long. > > More surprisingly, so could a char! > >>> <snip> >>>>> 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. >>> >>> I never suggested otherwise. However, in more rigorously defined >>> languages you can find out what combinations are permitted from the >>> specification. With PHP, I often end up just trying things because I >>> can't find the answer in the documentation. I then assume that what >>> happens now is what will always happen -- i.e. that the reference >>> implementation is the specification. >>> >> 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. > <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. >>> >>> I think that's exactly what it means. >> >> Fine. Go ahead and document every possible bad combination of >> operators. I won't wait up for your results. > > Well, I'd rather not. PHP has a more special cases than other languages > I've used, so it would be harder than for those. But I am surprised > that that you think it's so unreasonable to expect at least a moderately > rigorous definition of what is and is not permitted. As I said before, > it seems perfect reasonable to me. Even a grammar for the language > (surely not that hard) would have eliminated the OP's question from the > get go. > PHP is documented exactly the same as all of the other 20-odd languages I've used over the years. About the only difference is that PHP doc is written in a friendlier language (have you ever read an ANSI spec, for instance?). >>>> But it does mean you are trolling. >>> >>> Eh? This whole thread is an interesting technical discussion about the >>> degree to which PHP programs are well-defined. If you really think my >>> contributions are trolling, you know the well-worn advice: don't feed >>> me. >> >> You claim you understand why things which can't be done are not >> documented. Then you argue because what you want to try is not >> documented, and denigrate PHP because it doesn't follow YOUR >> definition of "rigorously defined". > > I don't recognise any of that. > Why not? It's exactly what you are saying. > I was making a sound technical point in reply to you: that PHP does not > have a ',' operator except in some sort of literalist sense: the manual > says it does, so it does, despite the fact that its meaning is undefined > and you can't use it in expressions to make bigger expressions. > I never claimed it does. Where in the manual does it say you can use the ',' operator like you want? > Your counter argument seems to be that the manual is not obliged to > document what you can't do. I disagree about that, but even if this is > granted, it is surely a mistake to list ',' as an operator when it > clearly isn't. > > <snip> > Exactly. The manual is obliged to only document what you can do. That is true for any language. Please show where in the manual it shows you can use the ',' operator like you want. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-02-25 16:56 +0000 |
| Message-ID | <0.8872fc115a445007d00d.20140225165618GMT.878uszjfm5.fsf@bsb.me.uk> |
| In reply to | #12953 |
Jerry Stuckle <jstucklex@attglobal.net> writes:
> On 2/24/2014 11:32 PM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 2/24/2014 4:23 PM, Ben Bacarisse wrote:
>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> <snip>
>>>>> It is an operator, as indicated by its appearance in the table of
>>>>> operators. Operators are not limited to +-*/.
>>>>
>>>> I am familiar with languages that have a ',' operator, which is why I
>>>> brought it up. Normally, combining expressions with an operator makes a
>>>> new expression, but that's not true in PHP for the comma. For example,
>>>> f() and g() are expressions, but (f(), g()) is not. That's why,
>>>> presumably, there is no description of what it does in the section on
>>>> operators -- it isn't one!
>>>
>>> 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.
<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. In extreme cases the distinction disappears, because a
>> language that specifies exactly what can be done, implicitly defines
>> what can't. But n practice it's easier to do a bit of both. For
>> example, you might give a general grammar, and then explain some
>> restrictions, such as what forms are not permitted on the left of an
>> assignment.
>
> No, the C specification does NOT say what you cannot do. Some books
> may add some things you cannot do, but the language itself doesn't.
> Check it out yourself - it's available at the ANSI website (for a
> price). Some university and/or technical libraries also have a copy.
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.
PHP is, as far as I can tell, silent on this matter. Don't you think
some more clarity about what is permitted and what is not permitted
would be useful?
(If you want to make a linguistic point that a constraint on what you
can do is not the same as saying that you cannot do something, then I
refer you to my C++ quote below.)
<snip>
>>> For instance a 32 bit C compiler will have different results than a 64
>>> bit C compiler, even if both are run on a 64 bit machine. And even
>>> different 32 bit C compilers can have different output. 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.)
>>> (which only states the length of an int is >= the
>>> length of a short, and <= the length of a long). So it is entirely
>>> possible one C compiler will have a 16 bit int, while another has a 32
>>> bit int. And both are within the C spec.
>>
>> Yes, but the language gives minimum guarantees which can be used to
>> permit code to be ported. It also (often) explicitly says where there
>> is no guarantee. For example, shifting right by the width of the type
>> being shifted is explicitly "undefined". It's useful to know that,
>> because you can simply avoid the situation in the first place. That's
>> simpler that testing it, seeing that it does what you expect, and then
>> finding that it fails on some other hardware.
>
> 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.
<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.
<snip>
> PHP is documented exactly the same as all of the other 20-odd
> languages I've used over the years. About the only difference is that
> PHP doc is written in a friendlier language (have you ever read an
> ANSI spec, for instance?).
Given the above, I think you can conclude that I have. But we do agree:
I like the informal, friendly, language of the reference manual. But
for many other languages I've used, there is also a relatively rigorous
specification that forgoes friendly language in order to answer exactly
the kind of questions that I and OP raised in this thread. It's not
essential, and I understand why no one wants to produce it, but that it
would be a good idea does not seem to me to be at all controversial.
<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.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-25 13:59 -0500 |
| Message-ID | <leip6d$cmb$1@dont-email.me> |
| In reply to | #12958 |
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: >>> >>>> On 2/24/2014 4:23 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> <snip> >>>>>> It is an operator, as indicated by its appearance in the table of >>>>>> operators. Operators are not limited to +-*/. >>>>> >>>>> I am familiar with languages that have a ',' operator, which is why I >>>>> brought it up. Normally, combining expressions with an operator makes a >>>>> new expression, but that's not true in PHP for the comma. For example, >>>>> f() and g() are expressions, but (f(), g()) is not. That's why, >>>>> presumably, there is no description of what it does in the section on >>>>> operators -- it isn't one! >>>> >>>> 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. > <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. In extreme cases the distinction disappears, because a >>> language that specifies exactly what can be done, implicitly defines >>> what can't. But n practice it's easier to do a bit of both. For >>> example, you might give a general grammar, and then explain some >>> restrictions, such as what forms are not permitted on the left of an >>> assignment. >> >> No, the C specification does NOT say what you cannot do. Some books >> may add some things you cannot do, but the language itself doesn't. >> Check it out yourself - it's available at the ANSI website (for a >> price). Some university and/or technical libraries also have a copy. > > 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. > PHP is, as far as I can tell, silent on this matter. Don't you think > some more clarity about what is permitted and what is not permitted > would be useful? > > (If you want to make a linguistic point that a constraint on what you > can do is not the same as saying that you cannot do something, then I > refer you to my C++ quote below.) > If you don't like the doc, submit a bug report for it. > <snip> >>>> For instance a 32 bit C compiler will have different results than a 64 >>>> bit C compiler, even if both are run on a 64 bit machine. And even >>>> different 32 bit C compilers can have different output. 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. >>>> (which only states the length of an int is >= the >>>> length of a short, and <= the length of a long). So it is entirely >>>> possible one C compiler will have a 16 bit int, while another has a 32 >>>> bit int. And both are within the C spec. >>> >>> Yes, but the language gives minimum guarantees which can be used to >>> permit code to be ported. It also (often) explicitly says where there >>> is no guarantee. For example, shifting right by the width of the type >>> being shifted is explicitly "undefined". It's useful to know that, >>> because you can simply avoid the situation in the first place. That's >>> simpler that testing it, seeing that it does what you expect, and then >>> finding that it fails on some other hardware. >> >> 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? There are some out there. It's been a while since I did any work on one, but I know of several embedded systems which are still in use (and being updated). > <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. > <snip> >> PHP is documented exactly the same as all of the other 20-odd >> languages I've used over the years. About the only difference is that >> PHP doc is written in a friendlier language (have you ever read an >> ANSI spec, for instance?). > > Given the above, I think you can conclude that I have. But we do agree: > I like the informal, friendly, language of the reference manual. But > for many other languages I've used, there is also a relatively rigorous > specification that forgoes friendly language in order to answer exactly > the kind of questions that I and OP raised in this thread. It's not > essential, and I understand why no one wants to produce it, but that it > would be a good idea does not seem to me to be at all controversial. > No, I can't conclude that you have read anything. All I know is that you've googled for excerpts from it. 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). > <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 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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-25 20:19 +0100 |
| Message-ID | <530cecd1$0$9508$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #12963 |
Jerry Stuckle wrote: > 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: >>>> >>>>> For instance a 32 bit C compiler will have different results than a 64 >>>>> bit C compiler, even if both are run on a 64 bit machine. And even >>>>> different 32 bit C compilers can have different output. 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. > >>>>> (which only states the length of an int is >= the >>>>> length of a short, and <= the length of a long). So it is entirely >>>>> possible one C compiler will have a 16 bit int, while another has a 32 >>>>> bit int. And both are within the C spec. >>>> >>>> Yes, but the language gives minimum guarantees which can be used to >>>> permit code to be ported. It also (often) explicitly says where there >>>> is no guarantee. For example, shifting right by the width of the type >>>> being shifted is explicitly "undefined". It's useful to know that, >>>> because you can simply avoid the situation in the first place. That's >>>> simpler that testing it, seeing that it does what you expect, and then >>>> finding that it fails on some other hardware. >>> >>> 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? There > are some out there. It's been a while since I did any work on one, but > I know of several embedded systems which are still in use (and being > updated). It's not necessarily impossible to implement 16bit operations on an 8bit machine. I did this long ago on a 6510, and actually it was rather simple. > 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? -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-02-25 20:43 +0100 |
| Message-ID | <11159375.oy54nrGDZR@PointedEars.de> |
| In reply to | #12965 |
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?
Implicitly: Call a factory method instead (which is neither “a violation of
OO principles” nor PHP-specific).
This can be useful. As you may recall, recently we discussed thread-safe
date formatting in de.comp.lang.php; I suggested the intl extension:
$ php -r 'echo IntlDateFormatter::create("hi@calendar=BUDDHIST",
IntlDateFormatter::FULL, IntlDateFormatter::LONG)->format(mktime(1, 2, 3, 4,
5, 2006)) . "\n";'
बुधवार, 5 अप्रैल ईस्वी2006 को 1:02:03 पूर्वाह्न GMT+2
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-25 16:02 -0500 |
| Message-ID | <lej0ca$pml$2@dont-email.me> |
| In reply to | #12969 |
On 2/25/2014 2:43 PM, Thomas 'PointedEars' Lahn wrote:
> 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?
>
> Implicitly: Call a factory method instead (which is neither “a violation of
> OO principles” nor PHP-specific).
>
The constructor is still being called. I am talking about a case where
the constructor is NEVER called.
> This can be useful. As you may recall, recently we discussed thread-safe
> date formatting in de.comp.lang.php; I suggested the intl extension:
>
> $ php -r 'echo IntlDateFormatter::create("hi@calendar=BUDDHIST",
> IntlDateFormatter::FULL, IntlDateFormatter::LONG)->format(mktime(1, 2, 3, 4,
> 5, 2006)) . "\n";'
> बुधवार, 5 अप्रैल ईस्वी2006 को 1:02:03 पूर्वाह्न GMT+2
>
>
> PointedEars
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-25 16:01 -0500 |
| Message-ID | <lej0av$pml$1@dont-email.me> |
| In reply to | #12965 |
On 2/25/2014 2:19 PM, Christoph Michael Becker wrote: > Jerry Stuckle wrote: > >> 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: >>>>> >>>>>> For instance a 32 bit C compiler will have different results than a 64 >>>>>> bit C compiler, even if both are run on a 64 bit machine. And even >>>>>> different 32 bit C compilers can have different output. 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. >> >>>>>> (which only states the length of an int is >= the >>>>>> length of a short, and <= the length of a long). So it is entirely >>>>>> possible one C compiler will have a 16 bit int, while another has a 32 >>>>>> bit int. And both are within the C spec. >>>>> >>>>> Yes, but the language gives minimum guarantees which can be used to >>>>> permit code to be ported. It also (often) explicitly says where there >>>>> is no guarantee. For example, shifting right by the width of the type >>>>> being shifted is explicitly "undefined". It's useful to know that, >>>>> because you can simply avoid the situation in the first place. That's >>>>> simpler that testing it, seeing that it does what you expect, and then >>>>> finding that it fails on some other hardware. >>>> >>>> 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? There >> are some out there. It's been a while since I did any work on one, but >> I know of several embedded systems which are still in use (and being >> updated). > > It's not necessarily impossible to implement 16bit operations on an 8bit > machine. I did this long ago on a 6510, and actually it was rather simple. > >> 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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-25 22:19 +0100 |
| Subject | Object constructors/destructors (was: Operator precedence) |
| Message-ID | <530d08cd$0$9523$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #12972 |
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. :) -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-02-25 16:32 -0500 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <lej25h$6gs$1@dont-email.me> |
| In reply to | #12977 |
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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-25 22:55 +0100 |
| Subject | Re: Object constructors/destructors |
| Message-ID | <530d1140$0$9522$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #12979 |
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. > 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. > 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. > I know of no other OO language which would allow this. Others may. -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.php
csiph-web