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

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

Check for military time

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

Contents

  Check for military time Derek Turner <frderek@suremail.je> - 2015-10-20 18:57 +0000
    Re: Check for military time Derek Turner <frderek@suremail.je> - 2015-10-20 19:00 +0000
      Re: Check for military time Richard Yates <richard@yatesguitar.com> - 2015-10-20 21:35 -0700
        Re: Check for military time Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-21 16:12 -0400
          Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-21 22:38 -0400
            Re: Check for military time Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 10:43 -0400
              Re: Check for military time Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 10:48 -0400
              Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-22 17:20 +0200
              Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 12:19 -0400
              Re: Check for military time "Peter H. Coffin" <hellsop@ninehells.com> - 2015-10-22 15:32 -0500
                Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-22 23:08 +0200
                  Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 20:19 -0400
                    Re: Check for military time Matthew Carter <m@ahungry.com> - 2015-10-22 22:07 -0400
                  Re: Check for military time "Beauregard T. Shagnasty" <a.nony.mous@example.invalid> - 2015-10-23 02:26 +0000
                Re: Check for military time Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 17:13 -0400
                  Re: Check for military time Tim Streater <timstreater@greenbee.net> - 2015-10-22 22:57 +0100
                    Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 20:22 -0400
                      Re: Check for military time Tim Streater <timstreater@greenbee.net> - 2015-10-23 09:19 +0100
                        Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-23 09:32 -0400
                          Re: Check for military time Tim Streater <timstreater@greenbee.net> - 2015-10-23 15:43 +0100
                            Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-23 11:11 -0400
                          Re: Check for military time gordonb.nwjln@burditt.org (Gordon Burditt) - 2015-10-23 12:36 -0500
                            Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-23 13:40 -0400
                            Re: Check for military time Tim Streater <timstreater@greenbee.net> - 2015-10-23 18:54 +0100
                          Re: Check for military time Norman Peelman <npeelman@cfl.rr.com> - 2015-10-23 22:44 -0400
                            Re: Check for military time Tim Streater <timstreater@greenbee.net> - 2015-10-24 10:32 +0100
                            Re: Check for military time Derek Turner <frderek@suremail.je> - 2015-10-24 11:41 +0000
                              Re: Check for military time Norman Peelman <npeelman@cfl.rr.com> - 2015-10-24 15:15 -0400
                  Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 20:21 -0400
                    Re: Check for military time Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 20:38 -0400
                      Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 20:47 -0400
                Re: Check for military time gordonb.90ylr@burditt.org (Gordon Burditt) - 2015-10-22 18:21 -0500
                  Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 20:23 -0400
              Re: Check for military time gordonb.c5zx1@burditt.org (Gordon Burditt) - 2015-10-22 17:40 -0500
          Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-22 11:12 +0200
            Re: Check for military time Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 11:06 -0400
              Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-22 17:18 +0200
          Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 13:17 -0400
    Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-21 13:55 +0200
      Re: Check for military time "M. Strobel" <strobel@example.com> - 2015-10-21 20:56 +0200
        Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-21 16:48 -0400
    Re: Check for military time Stephan Elinghaus <221015.6.seli@spamgourmet.com> - 2015-10-22 13:16 +0200
      Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-22 15:11 +0200
        Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 10:23 -0400
          Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-10-27 14:10 +0100
            Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-27 09:25 -0400
              Re: Check for military time Jørn Andersen <jorn@jorna.dk> - 2015-10-27 15:19 +0100
                Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-27 10:41 -0400
                  Re: Check for military time Matthew Carter <m@ahungry.com> - 2015-10-27 23:03 -0400
                    Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-27 23:29 -0400
                      Re: Check for military time Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-10-29 10:08 +0100
                        Re: Check for military time Matthew Carter <m@ahungry.com> - 2015-10-29 21:44 -0400
                          Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-29 22:35 -0400
                            Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-10-30 20:08 +0100
                              Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-30 16:22 -0400
                                Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 11:58 +0100
                                  Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 08:27 -0500
                                    Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 14:36 +0100
                                      Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 09:05 -0500
                                        Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 16:51 +0100
                                          Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 11:09 -0500
                          Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-30 22:33 +0100
                            Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-30 20:01 -0400
                            Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-11-03 19:51 +0100
                          Re: Check for military time Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-11-02 13:51 +0100
                            Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-02 18:57 +0100
                              Re: Check for military time Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-11-04 15:18 +0100
                                Re: Check for military time Matthew Carter <m@ahungry.com> - 2015-11-04 21:18 -0500
                                Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-05 07:51 +0100
                  Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-10-30 20:04 +0100
                    Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-30 16:24 -0400
                      Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 12:06 +0100
                        Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 08:30 -0500
                          Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 14:39 +0100
                            Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 09:07 -0500
                              Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 16:58 +0100
                                Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 11:05 -0500
                                  Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-02 08:14 +0100
                                    Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-02 10:01 -0500
                                      Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-02 17:54 +0100
                                        Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-02 12:50 -0500
                                          Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-02 19:05 +0100
                                            Re: Check for military time Tim Streater <timstreater@greenbee.net> - 2015-11-02 18:23 +0000
                                              Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-02 15:23 -0500
                                            Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-02 15:16 -0500
                                              Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-03 05:47 +0100
                                                Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-03 08:47 -0500
                                                  Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-04 03:55 +0100
                                                    Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-03 22:09 -0500
                                                      Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-04 08:49 +0100
                                                        Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-04 08:29 -0500
                                                          Re: Check for military time Paul Herber <paul@pherber.com> - 2015-11-04 14:14 +0000
                                                            Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-04 10:00 -0500
                                                        Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-11-06 13:11 +0100
                                                          Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-06 09:45 -0500
                                                            Re: Check for military time Matthew Carter <m@ahungry.com> - 2015-11-07 21:50 -0500
                                                              Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-07 22:05 -0500
                                                Re: Check for military time gordonb.2zzss@burditt.org (Gordon Burditt) - 2015-11-08 20:50 -0600
                                                  Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-09 10:29 +0100
                                                    Re: Check for military time gordonb.00syf@burditt.org (Gordon Burditt) - 2015-11-10 23:42 -0600
                                                      Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 07:46 +0100
                                                        Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 07:50 +0100
                                                          Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 08:06 -0500
                                                            Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 15:15 +0100
                                                              Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 09:21 -0500
                                                                Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 17:46 +0100
                                                                  Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 15:12 -0500
                                                                    Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 22:23 +0100
                                                                      Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 17:17 -0500
                                                        Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 08:05 -0500
                                                          OT: Munging addresses (was: Re: Check for military time) Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 19:18 +0100
                                                            Re: OT: Munging addresses Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 15:16 -0500
                                                              Re: OT: Munging addresses Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 22:29 +0100
                                                                Re: OT: Munging addresses Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 17:20 -0500
                                                                  Re: OT: Munging addresses Arno Welzel <usenet@arnowelzel.de> - 2015-11-12 07:47 +0100
                                                                    Re: OT: Munging addresses Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-12 10:15 -0500
                                                                      Re: OT: Munging addresses Arno Welzel <usenet@arnowelzel.de> - 2015-11-12 17:17 +0100
                                                                        Re: OT: Munging addresses Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-12 11:59 -0500
                                                                          Re: OT: Munging addresses Arno Welzel <usenet@arnowelzel.de> - 2015-11-12 18:51 +0100
                                                                            Re: OT: Munging addresses Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-12 14:20 -0500
                                                                              Re: OT: Munging addresses Arno Welzel <usenet@arnowelzel.de> - 2015-11-12 20:59 +0100
                                                                                Re: OT: Munging addresses Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-12 16:54 -0500
                                                                Re: OT: Munging addresses Jim Higgins <ILikeMy@Privacy.invalid> - 2015-11-18 16:24 +0000
                PHP code section end marker (was: Check for military time) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-27 22:58 +0100
              Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-10-30 20:01 +0100
                Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-30 16:27 -0400
                  Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 12:12 +0100
                    Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 08:31 -0500

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

#15833

On 11/1/2015 10:51 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-11-01 um 15:05:
> 
>> On 11/1/2015 8:36 AM, Arno Welzel wrote:
>>> Jerry Stuckle schrieb am 2015-11-01 um 14:27:
> [...]
>>> And it was you bringing up this:
>>>
>>> "But to answer your question - the problem is your test can cause a
>>> fatal error, potentially displaying internal information to a user.
>>> This information could be used to hack the system."
>>>
>>> And this is something which will NEVER happen in a production system. A
>>> production system MUST NOT display errors to a user.
>>>
>>
>> That's true.  And using closing tags is one more step which can prevent it.
> 
> You don't get my point: a production system MUST NOT display errors to a
> user - regardless what caused the error.
>

Oh, I get your point.  And you're wrong in thinking it can never happen.

> 
>>> You can not be sure that errors will NEVER happen - even when you end
>>> all your scripts with closing tags. Many things can go wrong during
>>> runtime - e.h. database connections may not be available etc.. And for
>>> all these cases you MUST ensure that users will NEVER see error messages
>>> with internal details about the production system. And yes, this is
>>> possible, even for PHP.
>>>
>>
>> No, you cannot be sure errors will never happen.  You also cannot be
>> sure that your php.ini file will never be changed.  It is NEVER possible
>> to have 100% assurance that error messages will never be displayed.  But
>> using closing tags is one more level of protection against it happening.
> 
> Wrong - mission critical configuration settings MUST stay as defined.
> Otherwise the responsible persons should better look for another job.
>

Wrong again.  You can NEVER guarantee something won't happen.  All you
can to is to protect as well as you can.

> 
>>> So even bringing up the possibility that a *user* of a system may see
>>> error messages with internal information shows me that you either don't
>>> have experience in how to configure and run production systems or you
>>> assume that everybody here is just a hobbyist and does not understand
>>> the difference between a development system and production system.
>>>
>>>
>>
>> The fact you don't consider it possible proves you don't have the
>> necessary experience to work on a production system.  You don't even
>> rate hobbyist level.  You're nothing more than a troll.
> 
> I don't know what you consider "professional" - but I wouldn't consider
> stupid things like allowing internal error messages to be disaplayed to
> the user on a production system just because one of the developers
> created a formal error in one of his scripts and putting them to the
> production system without testing it. I would also never let a software
> developer touch the php.ini of a production system without doing a
> review or even let anyone put scripts to production without testing at all.
> 
> 

Something other than what you are, that's for sure.  You don't
understand even basic good programming practices used by professionals.

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

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

#15818

Matthew Carter wrote:

> There have been 0 good reasons for including a closing [PHP] tag

ACK.

> (it's just too bad we can't actually have a '.phpdef' file type or
> something that simulates a 100% PHP only file, without dropping in and 
> out$ of tags and just avoids the use of the <?php ?> nonsense entirely).

You can have that with CLI scripts.  But the “<?php … ?>” "nonsense" (and, 
more recently, the “<?= … ?>” "nonsense") is actually useful: it allows one 
to write programs where the PHP parser only has to do the absolute minimum; 
static content can be put verbatim outside of “<?… … ?>”.  One must keep in 
mind that it is the *P*HP *H*ypertext *P*reprocessor after all; not just any 
programming language.

I know of no other language that has this power of avoiding “echo” and 
“echo”-like expressions, where the default is *not* to parse content as 
source code.

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#15819

On 10/30/2015 5:33 PM, Thomas 'Pointed Head' Lahn wrote:
> Matthew Carter wrote:
> 
>> There have been 0 good reasons for including a closing [PHP] tag
> 
> ACK.
>

Just what I would expect from you.  Good programmers know better.

>> (it's just too bad we can't actually have a '.phpdef' file type or
>> something that simulates a 100% PHP only file, without dropping in and 
>> out$ of tags and just avoids the use of the <?php ?> nonsense entirely).
> 
> You can have that with CLI scripts.  But the “<?php … ?>” "nonsense" (and, 
> more recently, the “<?= … ?>” "nonsense") is actually useful: it allows one 
> to write programs where the PHP parser only has to do the absolute minimum; 
> static content can be put verbatim outside of “<?… … ?>”.  One must keep in 
> mind that it is the *P*HP *H*ypertext *P*reprocessor after all; not just any 
> programming language.
> 

Good programming practices is not "nonsense".  But you wouldn't know
good programming practices if they bit you in the arse.  You've shown
that over and over again.

All you're able to do is copy/paste others' code; you know nothing about
original coding.

> I know of no other language that has this power of avoiding “echo” and 
> “echo”-like expressions, where the default is *not* to parse content as 
> source code.
> 

You don't know much, do you?  I suggest you crawl back into your little
hole before you show any more of your ignorance.

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

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

#15846

Thomas 'PointedEars' Lahn wrote:

> Matthew Carter wrote:
>> (it's just too bad we can't actually have a '.phpdef' file type or
>> something that simulates a 100% PHP only file, without dropping in and
>> out$ of tags and just avoids the use of the <?php ?> nonsense entirely).
> 
> You can have that with CLI scripts.  […]

I stand corrected by myself.  Unless I have overlooked something, apparently 
it is necessary to use “<?php” in CLI scripts, too.  I do not usually write 
CLI scripts (hence my misconception), but a few days ago I decided to do 
that.  When I ran the script file (its executable attribute was set) on 
GNU/Linux in Bash, the code was not parsed as PHP (but output verbatim 
instead), and not syntax-highlighted in Vim, until I had used “<?php”.

The current version of the script is rather short, so it might serve as a 
PHP (5.4+) learning exercise (it certainly did for me – who would have 
thought that you can use libxml to parse borked HTML, and not only apply 
XPath to the result, but get the .innerHTML of elements this easily [I have 
used several approaches from examples in the PHP manual and answers on Stack 
Overflow – along with the user comments in the manual a virtual treasure 
trove of ideas]):

#!/usr/bin/env php5
<?php

$page = 1;
$dict_template = 'http://wayback.archive.org/web/20150317193733/' .
  'http://home.comcast.net/~markg61/gv-eng%s.htm';
$libxml_options = (LIBXML_COMPACT | LIBXML_NOBLANKS | LIBXML_NOENT
  | LIBXML_NOWARNING);
$ipa_map = [
  'aa' => 'ɑ',
  'g'  => json_decode('"\\u0261"'),
  'l'  => 'l',
];

$d = new DOMDocument();
while ($d->loadHTMLFile(sprintf($dict_template, $page), $libxml_options))
{
  $r = (new DOMXPath($d))->query("//ul");
  echo preg_replace_callback(
    '/<img src="([^.]+).gif">/',
    function ($match) use ($ipa_map) {
      $char = $match[1];
      return @$ipa_map[$char] ? $ipa_map[$char] : $match[0];
    },
    preg_replace('/<\\/?font[^>]*>|<br>(?:\r|$)?/', '',
      $d->saveHTML($r[7]->firstChild))
  );

  ++$page;
}

(Suggestions for improvement are welcome.  I can foresee one suggestion 
already: Use output buffering :))

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#15835

On 10/30/2015 2:44 AM, Matthew Carter wrote:
> Erwin Moller <erwinmollerusenet@xs4all.nl> writes:
>
>> On 10/28/2015 4:29 AM, Jerry Stuckle wrote:
>>>
>>> YOU don't see any problem.  Good programmers do.
>>>
>>> Just wait until you run into a problem because of it.  Your tune will
>>> change.  And I'm not the only one who feels this way.
>>>
>>
>> Seconded.
>> Always use the closing tag.
>>
>> <opinionated>
>> If you get into trouble because you produce output after the closing
>> tag, get another job.
>> If that is over your head, you should change jobs, not the programming
>> language (or usage of it).
>> It isn't that hard.
>> This advice from php.net is ridiculous.
>>
>> This reminds me a lot of the curly bracket in conditional statements.
>> Some seem to think omitting them is alright for single statements.
>> It is, of course, not alright to omit them.
>> </opinionated>
>>
>> Regards,
>> Erwin Moller
>
> Other than a feeling of self righteousness, what is gained again?

A fair question.

To name a few:
- Estatics.
- No violation of the reasonable expectation that an opening tag should 
be accompanied by a closing tag.
- Slightly better readable code.
- Resistance to pop-culture programming (!).

But being self-righteous is enough reason in itself, for me.
(However, that was not the reason I jumped into this thread.)


>
> Tell me, in these two sample files, which is easier to debug if the
> aforementioned use cases occurred that cause an error when the file is
> included by another file making use of header responses:
>
> ------------------File One (no closing tag, misplaced HTML)-----------
> <?php
>
> function add($a, $b) {
>      return $a + $b;
> }
>
> <h1>This is my great page of addition!</h1>
>
> ------------------File Two (closing tag, extra space)-----------------
> <?php
>
> function add($a, $b) {
>      return $a + $b;
> }
>
> ?>


People who include files and put whitespaces after the closing tag will 
quickly see the infamous "Output created before headers bla bla, etc 
etc." error.

Hmmm, HUGE PROBLEM! Now what?

We have a few choices:
1) Remove the offending whitespace, and tell the programmer NOT to do 
that again.
2) Change the language, violate the logical assumption that each opening 
tag should be accompanied by a closing tag.


It is beyond my understanding how anyone can opt for the second option.
What is even more flabberghasting is the fact many people are willing to 
defend that crazy decision.


>
>
> Assuming both were included/required in another file, which one would
> the majority of programmers have an easier time pinpointing the error
> with?  (hint: the one where the PHP error reporting would tell you
> exactly where the faulty HTML was originating, NOT the file that was
> outputting some whitespace before a header call - that error would send
> you to the header() call line, not the bad file with trailing space).

Yes, you set up this question in such a way I can only agree with your 
precooked assumption. Of course the whitespace in your second example is 
harder to find.
So yes, you are right in this situation.

I DO want to add that if I save a file I have been working on, I test 
the results. If I see that "output created before header blabla etc 
etc", I think I know where to look first.
And that is my point: It isn't hard to find this problem.
And the "solution" you are defending is plain ugly, counter-intuitive, 
and introduces its own set of new possible problems.


On a sidenote: Your example is barely realistic. In each simple IDE 
(well, even Notepad++) your first example will shine out with colors, 
because there is HTML found where PHP is expected.

I hope you understand what I am saying.

And if some programmer REALLY has trouble avoiding whitespaces after the 
closing tag, write some simple bash script, that checks for them.
(I never needed that, but it is easy to write: just match the last ?> 
and see if anything follows)


>
> There have been 0 good reasons for including a closing tag (it's just too
> bad we can't actually have a '.phpdef' file type or something that
> simulates a 100% PHP only file, without dropping in and out of tags and
> just avoids the use of the <?php ?> nonsense entirely).
>

I fail, and keep failing, to see the importance of this.
We programmers have puzzles and problems to be solved daily.
Finding an unintended whitespace isn't really a big part of my daily 
business......

This solves a problem that didn't have to be solved, and it made the 
language uglier.

Regards,
Erwin Moller


-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

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

#15839

Erwin Moller schrieb am 2015-11-02 um 13:51:

> On 10/30/2015 2:44 AM, Matthew Carter wrote:
[...]
>> Tell me, in these two sample files, which is easier to debug if the
>> aforementioned use cases occurred that cause an error when the file is
>> included by another file making use of header responses:
>>
>> ------------------File One (no closing tag, misplaced HTML)-----------
>> <?php
>>
>> function add($a, $b) {
>>      return $a + $b;
>> }
>>
>> <h1>This is my great page of addition!</h1>
>>
>> ------------------File Two (closing tag, extra space)-----------------
>> <?php
>>
>> function add($a, $b) {
>>      return $a + $b;
>> }
>>
>> ?>
> 
> 
> People who include files and put whitespaces after the closing tag will 
> quickly see the infamous "Output created before headers bla bla, etc 
> etc." error.

This will just happen, if a scripts wants to add headers which is not
always the case.


> Hmmm, HUGE PROBLEM! Now what?
> 
> We have a few choices:
> 1) Remove the offending whitespace, and tell the programmer NOT to do 
> that again.

And hope that he will obey this rule. More likely this will happen again
many times.

> 2) Change the language, violate the logical assumption that each opening 
> tag should be accompanied by a closing tag.
> 
> 
> It is beyond my understanding how anyone can opt for the second option.

You will do this, when you first had to spend hours in finding bugs in a
system which consist of hundreds of files and some problem shows up
caused by unintentional whitespaces.

> What is even more flabberghasting is the fact many people are willing to 
> defend that crazy decision.

As already mentioned by T. Lahn:

<http://www.php-fig.org/psr/psr-2/>

Cite:

"The closing ?> tag MUST be omitted from files containing only PHP."


[...]
> And if some programmer REALLY has trouble avoiding whitespaces after the 
> closing tag, write some simple bash script, that checks for them.
> (I never needed that, but it is easy to write: just match the last ?> 
> and see if anything follows)

Before I create a script to check other scripts I would just omit the
closing tag - then I don't need any "check scripts" at all ;-).


>> There have been 0 good reasons for including a closing tag (it's just too
>> bad we can't actually have a '.phpdef' file type or something that
>> simulates a 100% PHP only file, without dropping in and out of tags and
>> just avoids the use of the <?php ?> nonsense entirely).
>>
> 
> I fail, and keep failing, to see the importance of this.
> We programmers have puzzles and problems to be solved daily.
> Finding an unintended whitespace isn't really a big part of my daily 
> business......
> 
> This solves a problem that didn't have to be solved, and it made the 
> language uglier.

PHP is already ugly in many places.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#15852

On 11/2/2015 6:57 PM, Arno Welzel wrote:
 > Erwin Moller schrieb am 2015-11-02 um 13:51:

<snip>

 >> People who include files and put whitespaces after the closing tag 
 >> will quickly see the infamous "Output created before headers bla
 >> bla, etc etc." error.
 >
 > This will just happen, if a scripts wants to add headers which is not
 > always the case.
 >
 >
 >> Hmmm, HUGE PROBLEM! Now what?
 >>
 >> We have a few choices:
 >> 1) Remove the offending whitespace, and tell the programmer NOT to do
 >> that again.
 >
 > And hope that he will obey this rule. More likely this will happen
 > again many times.


Is it really that hard?
And why accept it when "programmers" make this mistake, and refuse to 
improve their act?


 >
 >> 2) Change the language, violate the logical assumption that each
 >> opening tag should be accompanied by a closing tag.
 >>
 >>
 >> It is beyond my understanding how anyone can opt for the second
 >> option.
 >
 > You will do this, when you first had to spend hours in finding bugs
 > in a system which consist of hundreds of files and some problem shows
 > up caused by unintentional whitespaces.

No, that would not change my mind.
I know how hard it can be to find bugs, especially on a huge codebase.
I feel your pain.
But cure is worse than the pain.

The reason I make such a fuzz about this is this:
Where does this kind of "improvements" end?

Do you think it is acceptable if all calls to a method or function that 
cannot be found will be replaced (by the language) by the one that 
closely resembles the spelling used in the code because sometimes people 
mistype the name of the function, or are confused by camelCase/CamelCase?

Do you think it is acceptable if programmers leave out the closing curly 
bracket in conditional statement, because they "forget sometimes" to 
close it, and you have spend hours finding the problem?


Really, sometimes you just have to draw a line, and demand a certain 
mastery of the job. If people cannot deliver, they should go elsewhere.


 >
 >> What is even more flabberghasting is the fact many people are willing to
 >> defend that crazy decision.
 >
 > As already mentioned by T. Lahn:
 >
 > <http://www.php-fig.org/psr/psr-2/>
 >
 > Cite:
 >
 > "The closing ?> tag MUST be omitted from files containing only PHP."
 >

I choose to respond with:

https://yourlogicalfallacyis.com/appeal-to-authority

And Thomas Pointedears Lahn replaced critical thinking with following 
guidelines to the letter, a long time ago.
My advice: Don't follow him there.

Regards,
Erwin Moller


-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

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

#15854

Erwin Moller <erwinmollerusenet@xs4all.nl> writes:

> On 11/2/2015 6:57 PM, Arno Welzel wrote:
>> Erwin Moller schrieb am 2015-11-02 um 13:51:
>
> <snip>
>
>>> People who include files and put whitespaces after the closing tag
>>> will quickly see the infamous "Output created before headers bla
>>> bla, etc etc." error.
>>
>> This will just happen, if a scripts wants to add headers which is not
>> always the case.
>>
>>
>>> Hmmm, HUGE PROBLEM! Now what?
>>>
>>> We have a few choices:
>>> 1) Remove the offending whitespace, and tell the programmer NOT to do
>>> that again.
>>
>> And hope that he will obey this rule. More likely this will happen
>> again many times.
>
>
> Is it really that hard?
> And why accept it when "programmers" make this mistake, and refuse to
> improve their act?
>
>
>>
>>> 2) Change the language, violate the logical assumption that each
>>> opening tag should be accompanied by a closing tag.
>>>
>>>
>>> It is beyond my understanding how anyone can opt for the second
>>> option.
>>
>> You will do this, when you first had to spend hours in finding bugs
>> in a system which consist of hundreds of files and some problem shows
>> up caused by unintentional whitespaces.
>
> No, that would not change my mind.
> I know how hard it can be to find bugs, especially on a huge codebase.
> I feel your pain.
> But cure is worse than the pain.
>
> The reason I make such a fuzz about this is this:
> Where does this kind of "improvements" end?
>
> Do you think it is acceptable if all calls to a method or function
> that cannot be found will be replaced (by the language) by the one
> that closely resembles the spelling used in the code because sometimes
> people mistype the name of the function, or are confused by
> camelCase/CamelCase?
>
> Do you think it is acceptable if programmers leave out the closing
> curly bracket in conditional statement, because they "forget
> sometimes" to close it, and you have spend hours finding the problem?
>
>
> Really, sometimes you just have to draw a line, and demand a certain
> mastery of the job. If people cannot deliver, they should go
> elsewhere.
>
>
>>
>>> What is even more flabberghasting is the fact many people are willing to
>>> defend that crazy decision.
>>
>> As already mentioned by T. Lahn:
>>
>> <http://www.php-fig.org/psr/psr-2/>
>>
>> Cite:
>>
>> "The closing ?> tag MUST be omitted from files containing only PHP."
>>
>
> I choose to respond with:
>
> https://yourlogicalfallacyis.com/appeal-to-authority
>
> And Thomas Pointedears Lahn replaced critical thinking with following
> guidelines to the letter, a long time ago.
> My advice: Don't follow him there.
>
> Regards,
> Erwin Moller

Symfony 2 framework already provides suggestions if you mispell a word
in the error output above the stack trace (did you mean XYZ instead of
XWZ? type of thing).

Although in PHP camelCase will never get you in functions/methods, as
they're all case insensitive :)

<?php

function blub() {
  echo 1;
}

BLUB();

class foo
{
  public function bar()
  {
    echo 2;
  }
}

$f = new foo();
$f->BAR();


-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

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

#15855

Erwin Moller schrieb am 2015-11-04 um 15:18:

> On 11/2/2015 6:57 PM, Arno Welzel wrote:
>  > Erwin Moller schrieb am 2015-11-02 um 13:51:
[...]
>  >> 2) Change the language, violate the logical assumption that each
>  >> opening tag should be accompanied by a closing tag.
>  >>
>  >>
>  >> It is beyond my understanding how anyone can opt for the second
>  >> option.
>  >
>  > You will do this, when you first had to spend hours in finding bugs
>  > in a system which consist of hundreds of files and some problem shows
>  > up caused by unintentional whitespaces.
> 
> No, that would not change my mind.
> I know how hard it can be to find bugs, especially on a huge codebase.
> I feel your pain.
> But cure is worse than the pain.

No - the cure is an official recommendation, as already mentioned
several times:

<http://php.net/manual/en/language.basic-syntax.phptags.php>

> The reason I make such a fuzz about this is this:
> Where does this kind of "improvements" end?

It is not an "improvement" - it's just part of the language PHP and
totally valid.

> Do you think it is acceptable if all calls to a method or function that 
> cannot be found will be replaced (by the language) by the one that 
> closely resembles the spelling used in the code because sometimes people 
> mistype the name of the function, or are confused by camelCase/CamelCase?

No. And you start to mix up things which have nothing to do with each other.

> Do you think it is acceptable if programmers leave out the closing curly 
> bracket in conditional statement, because they "forget sometimes" to 
> close it, and you have spend hours finding the problem?

No. And this also has nothing to do with the topic.

And as you introduced it - that's my response for this ;-)

<https://yourlogicalfallacyis.com/slippery-slope>

> Really, sometimes you just have to draw a line, and demand a certain 
> mastery of the job. If people cannot deliver, they should go elsewhere.

I don't think this applies here.

>  >> What is even more flabberghasting is the fact many people are willing to
>  >> defend that crazy decision.
>  >
>  > As already mentioned by T. Lahn:
>  >
>  > <http://www.php-fig.org/psr/psr-2/>
>  >
>  > Cite:
>  >
>  > "The closing ?> tag MUST be omitted from files containing only PHP."
>  >
> 
> I choose to respond with:
> 
> https://yourlogicalfallacyis.com/appeal-to-authority

Wrong.

I explained why I believe that it makes sense to omit closing tags in
PHP scripts to avoid an unintentional whitespace without - and my
argument was NOT that one should do just it, because some authority says
to do so! But since some people say that omitting a closing tag at the
end of a PHP script is just a dirty workaround I referred to
<http://php.net/manual/en/language.basic-syntax.phptags.php> and
<http://www.php-fig.org/psr/psr-2/> to show that *others* recommend this
as well - including the staff of PHP itself.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#15813

Jerry Stuckle schrieb am 2015-10-27 um 15:41:

> On 10/27/2015 10:19 AM, J�rn Andersen wrote:
>> On Tue, 27 Oct 2015 09:25:31 -0400, Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>>
>>> On 10/27/2015 9:10 AM, Arno Welzel wrote:
>> <snip> 
>>>> JFTR: PHP scripts can not only output text and additional white space at
>>>> the end may invalidate the output. Omitting the closing tag does not
>>>> cause any harm but will avoid this for sure.
>>
>>> Good programming will avoid this problem, for sure.  Crappy programmers
>>> need crappy workarounds.
>>
>> php.net recommends not using the PHP closing tag “if a file is pure
>> PHP code”.
>> http://php.net/manual/en/language.basic-syntax.phptags.php
>>
>>> Omitting a closing tag will cause harm if someone tries to add html at
>>> the end of the page.
>>
>>
> 
> First of all, that is a big "if".  Second, this is an opinion of one (or
> a small group of) programmers which violates good coding practices which
> have worked for decades.  But then I have never been that impressed with
> the programmers there.

We all know that you are only impressed by yourself.

JFTR: PHP does not exist for "decades" - the first usable version 3.0 is
from 1997. Most other languages don't know the concept of "closing tags"
at all (C, C++, Java, Fortran, Cobol, Assembler, shell scripts for
sh/bash etc.). Therefore it can not be a "good coding practice" to add
closing tag to a script.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#15816

On 10/30/2015 3:04 PM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-10-27 um 15:41:
> 
>> On 10/27/2015 10:19 AM, J�rn Andersen wrote:
>>> On Tue, 27 Oct 2015 09:25:31 -0400, Jerry Stuckle
>>> <jstucklex@attglobal.net> wrote:
>>>
>>>> On 10/27/2015 9:10 AM, Arno Welzel wrote:
>>> <snip> 
>>>>> JFTR: PHP scripts can not only output text and additional white space at
>>>>> the end may invalidate the output. Omitting the closing tag does not
>>>>> cause any harm but will avoid this for sure.
>>>
>>>> Good programming will avoid this problem, for sure.  Crappy programmers
>>>> need crappy workarounds.
>>>
>>> php.net recommends not using the PHP closing tag “if a file is pure
>>> PHP code”.
>>> http://php.net/manual/en/language.basic-syntax.phptags.php
>>>
>>>> Omitting a closing tag will cause harm if someone tries to add html at
>>>> the end of the page.
>>>
>>>
>>
>> First of all, that is a big "if".  Second, this is an opinion of one (or
>> a small group of) programmers which violates good coding practices which
>> have worked for decades.  But then I have never been that impressed with
>> the programmers there.
> 
> We all know that you are only impressed by yourself.
> 
> JFTR: PHP does not exist for "decades" - the first usable version 3.0 is
> from 1997. Most other languages don't know the concept of "closing tags"
> at all (C, C++, Java, Fortran, Cobol, Assembler, shell scripts for
> sh/bash etc.). Therefore it can not be a "good coding practice" to add
> closing tag to a script.
> 
> 

I sure am not impressed with you!  You can't even read English.  I
didn't say PHP existed for decades; I said the good programming
practices have existed for decades.  And PHP is not only NOT the only
language with closing tags - it is far from the first language with
closing tags.

But trolls don't understand that.  They're too full of themselves to learn.



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

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

#15821

Jerry Stuckle schrieb am 2015-10-30 um 21:24:
> On 10/30/2015 3:04 PM, Arno Welzel wrote:
>> Jerry Stuckle schrieb am 2015-10-27 um 15:41:
>>
>>> On 10/27/2015 10:19 AM, J�rn Andersen wrote:
>>>> On Tue, 27 Oct 2015 09:25:31 -0400, Jerry Stuckle
>>>> <jstucklex@attglobal.net> wrote:
>>>>
>>>>> On 10/27/2015 9:10 AM, Arno Welzel wrote:
>>>> <snip> 
>>>>>> JFTR: PHP scripts can not only output text and additional white space at
>>>>>> the end may invalidate the output. Omitting the closing tag does not
>>>>>> cause any harm but will avoid this for sure.
>>>>
>>>>> Good programming will avoid this problem, for sure.  Crappy programmers
>>>>> need crappy workarounds.
>>>>
>>>> php.net recommends not using the PHP closing tag “if a file is pure
>>>> PHP code”.
>>>> http://php.net/manual/en/language.basic-syntax.phptags.php
>>>>
>>>>> Omitting a closing tag will cause harm if someone tries to add html at
>>>>> the end of the page.
>>>>
>>>>
>>>
>>> First of all, that is a big "if".  Second, this is an opinion of one (or
>>> a small group of) programmers which violates good coding practices which
>>> have worked for decades.  But then I have never been that impressed with
>>> the programmers there.
>>
>> We all know that you are only impressed by yourself.
>>
>> JFTR: PHP does not exist for "decades" - the first usable version 3.0 is
>> from 1997. Most other languages don't know the concept of "closing tags"
>> at all (C, C++, Java, Fortran, Cobol, Assembler, shell scripts for
>> sh/bash etc.). Therefore it can not be a "good coding practice" to add
>> closing tag to a script.
>>
>>
> 
> I sure am not impressed with you!  You can't even read English.  I

You just don't understand what I'm talking about.

> didn't say PHP existed for decades; I said the good programming
> practices have existed for decades.  And PHP is not only NOT the only
> language with closing tags - it is far from the first language with
> closing tags.

That's what I try to say: some practices for OTHER languages which may
exist for decades are NOT relevant for a spepcific feature in PHP! It
seems you have problems understanding me.

BTW: Show languages except PHP which need closing tags at the end of a
file. Oh and to clarify this - I don't talk about brackets for code
blocks. Neither C, C++, C#, Python, Pascal, Fortran, Cobol, Pascal need
closing tags - since the don't need opening tags at the beginning of a
source file either.

> But trolls don't understand that.  They're too full of themselves to learn.

As you show here over and over again. Even if the PHP manual recommends
something you argue with.

And your whole whay of insulting other people just because the question
was "is it ok to omit closing tags in PHP?". Don't you have better
things to do than calling all people trolls, idiots and ignorant just
because they don't share your opinion? Your life seems to be very
frustrating for you.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#15824

On 11/1/2015 6:06 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-10-30 um 21:24:
>> On 10/30/2015 3:04 PM, Arno Welzel wrote:
>>> Jerry Stuckle schrieb am 2015-10-27 um 15:41:
>>>
>>>> On 10/27/2015 10:19 AM, J�rn Andersen wrote:
>>>>> On Tue, 27 Oct 2015 09:25:31 -0400, Jerry Stuckle
>>>>> <jstucklex@attglobal.net> wrote:
>>>>>
>>>>>> On 10/27/2015 9:10 AM, Arno Welzel wrote:
>>>>> <snip> 
>>>>>>> JFTR: PHP scripts can not only output text and additional white space at
>>>>>>> the end may invalidate the output. Omitting the closing tag does not
>>>>>>> cause any harm but will avoid this for sure.
>>>>>
>>>>>> Good programming will avoid this problem, for sure.  Crappy programmers
>>>>>> need crappy workarounds.
>>>>>
>>>>> php.net recommends not using the PHP closing tag “if a file is pure
>>>>> PHP code”.
>>>>> http://php.net/manual/en/language.basic-syntax.phptags.php
>>>>>
>>>>>> Omitting a closing tag will cause harm if someone tries to add html at
>>>>>> the end of the page.
>>>>>
>>>>>
>>>>
>>>> First of all, that is a big "if".  Second, this is an opinion of one (or
>>>> a small group of) programmers which violates good coding practices which
>>>> have worked for decades.  But then I have never been that impressed with
>>>> the programmers there.
>>>
>>> We all know that you are only impressed by yourself.
>>>
>>> JFTR: PHP does not exist for "decades" - the first usable version 3.0 is
>>> from 1997. Most other languages don't know the concept of "closing tags"
>>> at all (C, C++, Java, Fortran, Cobol, Assembler, shell scripts for
>>> sh/bash etc.). Therefore it can not be a "good coding practice" to add
>>> closing tag to a script.
>>>
>>>
>>
>> I sure am not impressed with you!  You can't even read English.  I
> 
> You just don't understand what I'm talking about.
>

Oh, I understood, quite well.  And it's obvious YOU didn't.

>> didn't say PHP existed for decades; I said the good programming
>> practices have existed for decades.  And PHP is not only NOT the only
>> language with closing tags - it is far from the first language with
>> closing tags.
> 
> That's what I try to say: some practices for OTHER languages which may
> exist for decades are NOT relevant for a spepcific feature in PHP! It
> seems you have problems understanding me.
> 

Good practices are language independent.

> BTW: Show languages except PHP which need closing tags at the end of a
> file. Oh and to clarify this - I don't talk about brackets for code
> blocks. Neither C, C++, C#, Python, Pascal, Fortran, Cobol, Pascal need
> closing tags - since the don't need opening tags at the beginning of a
> source file either.
> 

You go find out.  I don't waste my time trying to teach trolls.  It's
like trying to teach a pig to sing.

>> But trolls don't understand that.  They're too full of themselves to learn.
> 
> As you show here over and over again. Even if the PHP manual recommends
> something you argue with.
> 

Which is, once again, just the opinion of a few programmers - ones I
have little respect for.

> And your whole whay of insulting other people just because the question
> was "is it ok to omit closing tags in PHP?". Don't you have better
> things to do than calling all people trolls, idiots and ignorant just
> because they don't share your opinion? Your life seems to be very
> frustrating for you.
> 
> 

No, I call trolls what they are.  And you have repeatedly shown you are
nothing more than a troll.

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

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

#15827

Jerry Stuckle schrieb am 2015-11-01 um 14:30:

> On 11/1/2015 6:06 AM, Arno Welzel wrote:
[...]
>> As you show here over and over again. Even if the PHP manual recommends
>> something you argue with.
>>
> 
> Which is, once again, just the opinion of a few programmers - ones I
> have little respect for.

I can't see anything in
<http://php.net/manual/en/language.basic-syntax.phptags.php> which marks
this as a personal opinion by anyone. It's an official part of the PHP
manual.



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#15829

On 11/1/2015 8:39 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-11-01 um 14:30:
> 
>> On 11/1/2015 6:06 AM, Arno Welzel wrote:
> [...]
>>> As you show here over and over again. Even if the PHP manual recommends
>>> something you argue with.
>>>
>>
>> Which is, once again, just the opinion of a few programmers - ones I
>> have little respect for.
> 
> I can't see anything in
> <http://php.net/manual/en/language.basic-syntax.phptags.php> which marks
> this as a personal opinion by anyone. It's an official part of the PHP
> manual.
> 

And where do you think that "official part of the PHP manual" came from?
 It is nothing more than the personal opinion of a few programmers -
ones I have little respect for.

But you've never written a manual, so you wouldn't understand what goes
into creating a manual.

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

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

#15831

Jerry Stuckle schrieb am 2015-11-01 um 15:07:

> On 11/1/2015 8:39 AM, Arno Welzel wrote:
>> Jerry Stuckle schrieb am 2015-11-01 um 14:30:
>>
>>> On 11/1/2015 6:06 AM, Arno Welzel wrote:
>> [...]
>>>> As you show here over and over again. Even if the PHP manual recommends
>>>> something you argue with.
>>>>
>>>
>>> Which is, once again, just the opinion of a few programmers - ones I
>>> have little respect for.
>>
>> I can't see anything in
>> <http://php.net/manual/en/language.basic-syntax.phptags.php> which marks
>> this as a personal opinion by anyone. It's an official part of the PHP
>> manual.
>>
> 
> And where do you think that "official part of the PHP manual" came from?

Irrelevant. It is part of the official technical documentation of PHP.

>  It is nothing more than the personal opinion of a few programmers -
> ones I have little respect for.

So you have little respect for the developers of PHP itself? Why do you
use the language it then? Did you also tell exactly this to the
maintainers of the PHP manual?

> But you've never written a manual, so you wouldn't understand what goes
> into creating a manual.

Don't worry - I have written manuals and know very well what I'm talking
about.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#15832

On 11/1/2015 10:58 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-11-01 um 15:07:
> 
>> On 11/1/2015 8:39 AM, Arno Welzel wrote:
>>> Jerry Stuckle schrieb am 2015-11-01 um 14:30:
>>>
>>>> On 11/1/2015 6:06 AM, Arno Welzel wrote:
>>> [...]
>>>>> As you show here over and over again. Even if the PHP manual recommends
>>>>> something you argue with.
>>>>>
>>>>
>>>> Which is, once again, just the opinion of a few programmers - ones I
>>>> have little respect for.
>>>
>>> I can't see anything in
>>> <http://php.net/manual/en/language.basic-syntax.phptags.php> which marks
>>> this as a personal opinion by anyone. It's an official part of the PHP
>>> manual.
>>>
>>
>> And where do you think that "official part of the PHP manual" came from?
> 
> Irrelevant. It is part of the official technical documentation of PHP.
>

So?  That does not mean it is good programming practices.

>>  It is nothing more than the personal opinion of a few programmers -
>> ones I have little respect for.
> 
> So you have little respect for the developers of PHP itself? Why do you
> use the language it then? Did you also tell exactly this to the
> maintainers of the PHP manual?
> 

Both.  And why I use it is none of your business.

>> But you've never written a manual, so you wouldn't understand what goes
>> into creating a manual.
> 
> Don't worry - I have written manuals and know very well what I'm talking
> about.
> 
> 

Ah, yes - "The Dummies Guide to Trolling".  If forgot about that one!

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

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

#15834

Jerry Stuckle schrieb am 2015-11-01 um 17:05:

> On 11/1/2015 10:58 AM, Arno Welzel wrote:
[...]
>> So you have little respect for the developers of PHP itself? Why do you
>> use the language it then? Did you also tell exactly this to the
>> maintainers of the PHP manual?
>>
> 
> Both.  And why I use it is none of your business.

I see - you have little respect for the developers of PHP itself and you
see recommendations in their manual as a bad programming practice.

And you really think your advises about *any* PHP related topic here
should be taken seriously? Really?


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#15836

On 11/2/2015 2:14 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-11-01 um 17:05:
> 
>> On 11/1/2015 10:58 AM, Arno Welzel wrote:
> [...]
>>> So you have little respect for the developers of PHP itself? Why do you
>>> use the language it then? Did you also tell exactly this to the
>>> maintainers of the PHP manual?
>>>
>>
>> Both.  And why I use it is none of your business.
> 
> I see - you have little respect for the developers of PHP itself and you
> see recommendations in their manual as a bad programming practice.
>

No, I have little respect for the developers of PHP BECAUSE they make
recommendations that violate long-standing good programming practices.

> And you really think your advises about *any* PHP related topic here
> should be taken seriously? Really?
> 
> 

Much more than anything a troll like YOU suggests should be taken seriously.

And it's "advice", not "advises".  Point in fact.


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

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

#15837

Jerry Stuckle schrieb am 2015-11-02 um 16:01:

[...]
> Much more than anything a troll like YOU suggests should be taken seriously.
> 
> And it's "advice", not "advises".  Point in fact.

Wenn Du jemals Deutsch schreibst, werde ich Dich dann auch auf jeden
Rechtschreibfehler hinweisen - Danke.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

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

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

csiph-web