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.
>
> 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 (:
>
> On Sat, Apr 7, 2012 at 9:35 AM, Crocodile <[email protected]> wrote:
>> Hello, Tom...
>>
>> Are you seriously that bothered with '<?php' at the top of your classes? Are
>> you serious when talking changing reguire/include behaviour just to satisfy
>> 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 <[email protected]>
>>>
>>> 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 PHP
>>> 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
>>>
>>
>
>
>
--
Mit besten Grüßen, Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 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
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc