Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59401
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thelounge.net designates 91.118.73.15 as permitted sender)
Message-ID: <4F8044C4.8050100@thelounge.net>
Date: Sat, 07 Apr 2012 15:44:36 +0200
Organization: the lounge interactive design
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAORXhGLk8=bJ2TEo0OCzQCacjtGG=ZWYNuXf8Uu8oMNEm2WQ1A@mail.gmail.com> <CAGU04mLu9pniaDw3jAOR7YiX6n3Bk7sMk7T1=4PAvG5QvAZNvw@mail.gmail.com> <CAORXhGLq3ZyShNkqBsPwdabi6SkTqiE00jETiWeXK2T7Lm3gEQ@mail.gmail.com>
In-Reply-To: <CAORXhGLq3ZyShNkqBsPwdabi6SkTqiE00jETiWeXK2T7Lm3gEQ@mail.gmail.com>
OpenPGP: id=7F780279;
	url=http://arrakis.thelounge.net/gpg/h.reindl_thelounge.net.pub.txt
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigBC6931125A99CEE89BE6FCA8"
Subject: Re: [PHP-DEV] PHP class files without <?php at the top
From: h.reindl@thelounge.net (Reindl Harald)

--------------enigBC6931125A99CEE89BE6FCA8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

you are not making valid points
you are proposing DANGEROUS changes!

what happens if PHP 5.4.x will follow your wishes
(what never will happen) and your file without
<?php will be called on a machine with a lower
php-version?

what you also do not realize is that the world is not turning
around your windows machine - in the unix world extensions
are meaningless - the sheabing and execute permissions are
the only things controlling if a zexzfile is executeable
and with which interpreter this happens

and no the world is not turning around you or even around PHP
this is how unix-systems and shells are working and there
is no place for funny execptions in this world


Am 07.04.2012 15:39, schrieb Tom Boutell:
> From the viewpoint of someone writing reusable classes, the need to
> start with <?php and reprimand anybody who accidentally puts a newline
> above it is a silly annoyance they don't experience with other tools.
>=20
> 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 - if
> 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 (:
>=20
> On Sat, Apr 7, 2012 at 9:35 AM, Crocodile <crocodile2u@gmail.com> wrote=
:
>> Hello, Tom...
>>
>> Are you seriously that bothered with '<?php' at the top of your classe=
s? Are
>> you serious when talking changing reguire/include behaviour just to sa=
tisfy
>> your wish?
>>
>> To be also serious, I would mention the possibility of including URLs.=
 There
>> is no such thing as file name extension in URLs. Thus your idea should=
 be
>> forgot. Personally, I really think 1st of April is like continuing in =
the
>> internals mailing list...
>>
>> 2012/4/7 Tom Boutell <tom@punkave.com>
>>>
>>> Now that the flamewar has died down a little I'd like to try to have =
a
>>> civil discussion about this idea - *without* my admittedly
>>> inflammatory suggestion to kill <?php altogether.
>>>
>>> So here is what I am seriously suggesting:
>>>
>>> * The default behavior doesn't change. The parser starts out in HTML =
mode.
>>>
>>> * If the CLI sees a .phpc file extension, the parser starts out in PH=
P
>>> mode (no opening <?php is required). It is still possible to shift
>>> into HTML mode after that with ?>.
>>>
>>> * If a require/include statement sees a .phpc file extension, the
>>> parser starts out in PHP mode.
>>>
>>> * If mod_php and FPM are able to see the path (I'm honestly not sure
>>> if they can or not), they look for .phpc as their indication to start=

>>> out in PHP mode. If that's not possible then new options are defined
>>> to allow Apache to be configured to tell mod_php and/or FPM to do the=

>>> right thing based on mime types etc.
>>>
>>> This way .php continues to behave exactly as it does today, and can
>>> interoperate smoothly with code that uses .phpc. .phpc can require
>>> .php and vice versa. They are friends.
>>>
>>> Thoughts?
>>>
>>> --
>>> 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
>>>
>>
>=20
>=20
>=20

--=20

Mit besten Gr=FC=DFen, Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofm=FChlgasse 17
CTO / software-development / cms-solutions
p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40
icq: 154546673, http://www.thelounge.net/

http://www.thelounge.net/signature.asc.what.htm


--------------enigBC6931125A99CEE89BE6FCA8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ARMQACgkQhmBjz394AnmmwACcCusfgDr3RGk7DG55tVZTLiNl
F2oAnjINq6P5J40VqD8leoGAc/YKT8nu
=Vwo+
-----END PGP SIGNATURE-----

--------------enigBC6931125A99CEE89BE6FCA8--