Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Matthew Carter <m@ahungry.com>
Newsgroups: comp.lang.php
Subject: Re: Check for military time
Date: Wed, 04 Nov 2015 21:18:43 -0500
Organization: Ahungry (http://ahungry.com)
Lines: 120
Message-ID: <87fv0ljiik.fsf@ahungry.com>
References: <d8nh4uFgdr2U1@mid.individual.net> <h5tmfc-678.ln1@none.inv> <1874827.QbCUPLQBcH@PointedEars.de> <n0ard5$937$1@dont-email.me> <562F77B7.1050001@arnowelzel.de> <n0ntrp$kpq$1@dont-email.me> <ut1v2b5bkvm5378ldg5ucojj4r1k8o8vnf@4ax.com> <n0o2as$69i$1@dont-email.me> <8737wvd78w.fsf@ahungry.com> <n0pfa8$ckm$1@dont-email.me> <5631e20e$0$23743$e4fe514c@news.xs4all.nl> <87y4elb05f.fsf@ahungry.com> <56375c5b$0$23788$e4fe514c@news.xs4all.nl> <5637A403.5030200@arnowelzel.de> <563a13ba$0$23779$e4fe514c@news.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="7c986cd4736462de309a749b207746fe"; logging-data="6410"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/0e1TZzqjNBLvLG04E5t99"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Cancel-Lock: sha1:+PT5S18rMwXBfeKzkHTjnlV/eoU= sha1:FeklfNgdHwTiBNiZTqzTI3AA5nk=
Xref: csiph.com comp.lang.php: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