Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59425
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain cywh.com from 209.85.212.42 cause and error)
References: <CAORXhGLk8=bJ2TEo0OCzQCacjtGG=ZWYNuXf8Uu8oMNEm2WQ1A@mail.gmail.com>
 <CAGU04mLu9pniaDw3jAOR7YiX6n3Bk7sMk7T1=4PAvG5QvAZNvw@mail.gmail.com>
 <CAORXhGLq3ZyShNkqBsPwdabi6SkTqiE00jETiWeXK2T7Lm3gEQ@mail.gmail.com>
 <03FFDCA3-90B2-48CA-B102-7562E0E9CA45@zort.net> <CAORXhGK0-UCpQgsniM2=k+nK9UsAyjL5PD2ecmTB-EPxFGNKRw@mail.gmail.com>
 <7019423255875772333@unknownmsgid> <93A21C4E-C811-4D2A-9304-6DDF1E8994FB@punkave.com>
In-Reply-To: <93A21C4E-C811-4D2A-9304-6DDF1E8994FB@punkave.com>
Mime-Version: 1.0 (1.0)
Date: Sat, 7 Apr 2012 09:20:34 -0700
Message-ID: <-1019802484564133356@unknownmsgid>
To: Tom Boutell <tom@punkave.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP class files without <?php at the top
From: luke@cywh.com (Luke Scott)

On Apr 7, 2012, at 9:04 AM, Tom Boutell <tom@punkave.com> wrote:

> A thoughtful suggestion. But the trouble with a php.ini setting is that y=
ou can't tell if it is enabled when writing your class file. That makes it =
impossible to write portable libraries. The keywords would always be availa=
ble. And no one has to type them outside of an auto loader (:
>
> Sent from my iPhone

Why would you need to? With it on or off <?php would work like it did befor=
e:

With it off (how it is now):

- Text before <?php would be printed to the output buffer.

- ?> ends php code and prints text between it and the next <?php tag
or the end of the file.

With it on:

- <?php is optional and must be first in the file. White spaces before
<?php are ignored and text before throws an error (perhaps white space
should through an error). The shebang line for the cli sapi is the
only exception.

- ?> is explicitly forbidden.

If classes start with <?php and leave out the ending ?> this should be
fine. Most classes written with PHP 5+ comparability do this anyway.

The only way I see this not working is for PHP short tags where PHP is
used as a template language. A lot of people decide to use other
template engines though, like Twig. I personally avoid short tags on
large projects and use them only on small quick and dirty projects.

Luke

(Sorry, I keep forgetting to hit reply all)

>
> On Apr 7, 2012, at 11:46 AM, Luke Scott <luke@cywh.com> wrote:
>
>> On Apr 7, 2012, at 7:00 AM, Tom Boutell <tom@punkave.com> wrote:
>>
>>> That's a good point too.
>>>
>>> I think this is a better proposal:
>>>
>>> include_code, require_code, and require_code_once would work just like
>>> include, require and require_once, except that the parser would start
>>> out in PHP mode.
>>>
>>> .phpc is then just a convention for naming PHP files that start out
>>> with code - a convention that autoloaders should respect, just as they
>>> now respect the .php convention. "The user asked for the Monkey class,
>>> and I see Monkey.phpc is out there; I'll grab that with
>>> require_code_once."
>>>
>>> Putting this decision on the autoloader makes more sense because
>>> autoloaders already contain assumptions about file extensions. They
>>> have to in order to do their job of translating a class name to a
>>> particular path somewhere.
>>>
>>> Folks who did not care for this functionality could then choose to
>>> entirely ignore it. Class library developers who liked it would make
>>> autoloaders available that honored it, freeing end-user developers
>>> from thinking about it. It becomes self-contained, and people who are
>>> writing old-school .php standalone scripts or pages are entirely
>>> unaffected.
>>
>> Tony I think your idea has some merit. If it were up to me I'd remove
>> <?php all together. It really is bad practice to mix HTML into code.
>>
>> But I feel that adding new keywords is not the way to do it.
>> Personally I'd like to see a php.ini setting to disallow the ending ?>
>> tag and assume .php files just have PHP code. The starting <?php tag
>> would be optional. White space would be ignored and non-white space
>> characters before <?php would throw a fatal error.
>>
>> Doing it this way would disallow bad practices but still make existing
>> PHP scripts compatible.
>>
>> I think that doing that would be quite reasonable. Those who complain
>> about it likely ignore industry best practices anyway. This option
>> could be turned off by default at first, made default later, and then
>> ?> be deprecated all together.
>>
>> So with this option enabled ?> is forbidden, <?php is optional, and
>> the text before <?php is handled differently - white spaces ignored,
>> text before throws an error (unless it's a shebang line in cli mode).
>>
>> Hopefully that made sense. Does this sound good to you?
>>
>> I'm sorry you had to endure such a nasty troll. I am so sick of self
>> righteous bullies who think they know it all.
>>
>> Luke
>>
>>>
>>> On Sat, Apr 7, 2012 at 9:50 AM, John Bafford <dshadow@zort.net> wrote:
>>>>
>>>> On Apr 7, 2012, at 09:39, Tom Boutell wrote:
>>>>
>>>>>> From the viewpoint of someone writing reusable classes, the need to
>>>>> start with <?php and reprimand anybody who accidentally puts a newlin=
e
>>>>> above it is a silly annoyance they don't experience with other tools.
>>>>>
>>>>> That said, you are making valid points, I'm not convinced myself that
>>>>> "file extensions" necessarily should or could be determined in every
>>>>> context. But it seems the most viable way of addressing the issue - i=
f
>>>>> a viable way even exists. Partly I want to convince myself that this
>>>>> either can or can't ever be improved, and move on either way (:
>>>>
>>>> That "silly annoyance" doesn't seem to bother anyone who writes comman=
d line tools, which require the #! line specifying the command interpreter =
to be the first bytes in the file, with no leading white space whatsoever. =
Especially on unix systems (but also on the Mac), the file extension does n=
ot affirmatively indicate the file type or whether or not it can be execute=
d.
>>>>
>>>> Also, from a CLI perspective, you don't want extensions in the names o=
f your scripts, because then it causes problems/confusion/extra work if you=
 later decide to change the language the script is written in.
>>>>
>>>> -John
>>>>
>>>> --
>>>> John Bafford
>>>> http://bafford.com/
>>>>
>>>>
>>>> --
>>>> PHP Internals - PHP Runtime Development Mailing List
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>>
>>>
>>>
>>> --
>>> Tom Boutell
>>> P'unk Avenue
>>> 215 755 1330
>>> punkave.com
>>> window.punkave.com
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>