[PHP-DEV] PHP class files without <?php at the top

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

I'm +1 on this.

<?php isn't a *huge* issue, but it is a bit of an annoyance. 'phpc' would help fix that up IMO.


On Saturday, 7 April 2012 at 11:26 PM, Tom Boutell wrote:

> 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 (http://punkave.com)
> window.punkave.com (http://window.punkave.com)
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

On Sat, Apr 07, 2012 at 09:26:01AM -0400, Tom Boutell wrote:
> 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 ?>.

Why ? What is the benefit ? You don't have to put <?php at the start of a php
file, so you save a few bytes...

Today PHP does not look at file extensions - so why change that behaviour ?
Extra complication with no real benefit.

Thanks for the idea - but no thanks.

> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330

What country would that be ? On a list like this numbers should start +

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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
>
>

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
>>
>



--
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

On 7 Apr 2012, at 14: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 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 (:

If accidental newlines above the <?php are your only issue surely it makes more sense to have PHP ignore any whitespace before an initial <?php in the file, just like it ignores a carriage return after ?>.

-Stuart

--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

<?php is a simple and effective way to enter "php mode". File
extensions are really irrelevant.

This isn't a sensible idea.

On Sat, Apr 7, 2012 at 2:44 PM, Reindl Harald <[email protected]> wrote:
> 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
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Am 07.04.2012 15:43, schrieb Stuart Dallas:
> On 7 Apr 2012, at 14: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 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 (:
>
> If accidental newlines above the <?php are your only issue surely it makes more sense to have PHP ignore any whitespace before an initial <?php in the file, just like it ignores a carriage return after ?>.

the main question is why making them and where should php start
and where better stop to hold users hands?

what is the next? making ; optional and change the interpreter
to a gambling-machine because someone comes out whining it does
not work if he makes syntax errors?

April 1st is over so please stop this useless discussion

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 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 (:

That "silly annoyance" doesn't seem to bother anyone who writes command 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 not affirmatively indicate the file type or whether or not it can be executed.

Also, from a CLI perspective, you don't want extensions in the names of 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

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.

On Sat, Apr 7, 2012 at 9:50 AM, John Bafford <[email protected]> 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 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 (:
>
> That "silly annoyance" doesn't seem to bother anyone who writes command 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 not affirmatively indicate the file type or whether or not it can be executed.
>
> Also, from a CLI perspective, you don't want extensions in the names of 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

Am 07.04.2012 16:00, schrieb Tom Boutell:
> 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.

would you please leave this world in peace?

what do you think happens with hundret thousands of existing
include-files out there which are containing only HTML?

why do you simply not realize that you have way too few knowledge
and tchnical education to partly understand the side effects
small changes in a general behavior are having and that the
benefit has to be a REAL LARGE ONE for everybody to accept
the possible damage - which is not the case here

where are your proposals for bash and other unix shells
hwo they have to work if there is a whitespace before
#!/bin/sh? what have you got as answer there?

again: please leave the world in peace with your poorly
thought proposals - and yes this is a really polite answer
compared with the thoughts running through my mind
while reading your stuff

On Sat, 7 Apr 2012, Reindl Harald wrote:

> and no the world is not turning around you or even around PHP

I will once more suggest you tune down your language on the
mailinglists. It's often rude and offensive. Let this be your last
warning.

cheers,
Derick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Apr 07, 2012 at 04:06:17PM +0200, Reindl Harald wrote:
>
>
> Am 07.04.2012 16:00, schrieb Tom Boutell:
> > 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.
>
> would you please leave this world in peace?
> ...

You may not agree with his proposal (neither do I) but please remain kind &
polite to him. He is not trolling.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Apr 7, 2012 at 10:06 AM, Reindl Harald <[email protected]> wrote:
>
>
> would you please leave this world in peace?
>
> what do you think happens with hundret thousands of existing
> include-files out there which are containing only HTML?

Nothing happens to them whatsoever. They work exactly the way they did
before. I am introducing separate keywords in this proposal precisely
to avoid creating problems for you. Please read the email you just
replied to.

> why do you simply not realize that you have way too few knowledge
> and tchnical education to partly understand the side effects
> small changes in a general behavior are having

*Sigh*

See this?

http://php.net/manual/en/book.image.php

That's my doing, fella. I am the original author of the gd library
functions described there and the originator of the PNG file format
project as well. You have probably been using my work in your PHP code
for years, if you have done much image manipulation with PHP (although
there are some fine alternatives as well of course). I also wrote the
original WWW FAQ (circa '94) and have helped promote the open web ever
since.

And do you know how much that matters? Not one little bit. if this
proposal stinks, then it should be politely rejected. But not just
because somebody can't be civil (:

There are no side effects in the new proposal in the latest email you
are replying to, at least not that you have accurately identified yet.
The .phpc extension has completely vanished from use cases like yours
in that proposal. Pay attention to what I wrote and respond
thoughtfully.

> benefit has to be a REAL LARGE ONE for everybody to accept
> the possible damage - which is not the case here
>
> where are your proposals for bash and other unix shells
> hwo they have to work if there is a whitespace before
> #!/bin/sh? what have you got as answer there?
>
> again: please leave the world in peace with your poorly
> thought proposals - and yes this is a really polite answer
> compared with the thoughts running through my mind
> while reading your stuff
>



--
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

Am 07.04.2012 16:07, schrieb Derick Rethans:
> On Sat, 7 Apr 2012, Reindl Harald wrote:
>
>> and no the world is not turning around you or even around PHP
>
> I will once more suggest you tune down your language on the
> mailinglists. It's often rude and offensive. Let this be your last
> warning

and what is there exactly rude?

this is simply the truth
or do you believe the world is turning around one person or PHP?

if someone brings proposals which are so less thight
what would you giev as answer? wait until enough people
not care enough abut the impacts start to implement
changes and then wait how to live with them?

i was there too often and nobody gives me back the wasted
lifetime for modify things after changes with zero benefit
and large impact - and what you lear after enough such
changes is that a "in my opinion not so a good idea" will
be ignored if someone loves to make changes

On 07/04/12 16:06, Reindl Harald wrote:
> Am 07.04.2012 16:00, schrieb Tom Boutell:
>> 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.
> would you please leave this world in peace?

This is a much better proposal than magic-extensions,
and a backwards-compatible one.
You may not like it (I'm not convinced about it), but your
criticism here is wrong.

> what do you think happens with hundret thousands of existing
> include-files out there which are containing only HTML?
They would obviously continue working as they would be using
the old require code.
Moreover, including a HTML files is bad coding, readfile() works
much better.


> why do you simply not realize that you have way too few knowledge
> and tchnical education to partly understand the side effects
> small changes in a general behavior are having and that the
> benefit has to be a REAL LARGE ONE for everybody to accept
> the possible damage - which is not the case here
This is a backwards compatible change.
The benefit of not typing '<?php' may not be worth adding those
new require types, they would also break new scripts on old engines.
But it wouldn't have those catastrophic effects that you seem to foresee.
Care to enlighten us poor myopic souls?


> where are your proposals for bash and other unix shells
> hwo they have to work if there is a whitespace before
> #!/bin/sh? what have you got as answer there?
He is only doing a proposal for php, not for bash.

> again: please leave the world in peace with your poorly
> thought proposals - and yes this is a really polite answer
> compared with the thoughts running through my mind
> while reading your stuff
Please keep trying, it can still be improved.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

> From: Tom Boutell [mailto:[email protected]]
>
> 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.
>

I don't like this, but it's closer. I hate the idea of adding a whole mess of one-off functions just to support a single coding style feature that doesn't seem to have very much support. There are a variety of other ideas that have been floating around that request changes to how the parser handles specific code (different short tags, sandboxing, auto-escaping, etc.).

What if you have just ONE function with a variety of options? Something like:

execute_file('path/to/foo.php', array(
'require'=>true,
'once'=>true,
'begin_code'=>'<?php ',
'shorttags'=>array('<?=','?>'),
'autoescape'=>function($str){return htmlentities($str, ENT_QUOTES | ENT_HTML5, 'UTF-8');},
...
));

This would provide a single consistent hook for any further DSL like features without impacting the behavior of any existing code. Some other options that might make sense:

lint (like command line)
end_code (similar to command line, corresponds with begin_code (also command line))
args (also command line)
Any PHP_INI_ALL directives

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Apr 7, 2012, at 10:00, Tom Boutell 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.

Those might be nice functions to have, but ...

> .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."

… I think this isn't quite as simple as you make it out to be. Any autoloader that cared about bc would have to have code like

if(file_exists(.phpc)) require_code() else if(file_exists(.php)) require() else HCF()

There's a reason everyone settled around a single extension, and not the plethora we used to have (php, phtml, php3/php4, others?). Even in the rainbows-and-unicorns world where everyone always has an opcode cache and suitably tuned stat cache, that extra call to file_exists that will likely happen while waiting for files to be renamed and tested still isn't free. Also, I'm willing to bet that in the unlikely event you chose to drop out of PHP mode to dump a block of HTML, the awkwardness of a sudden ?> without a leading <?php would make the discussions about whether or not to have a trailing ?> at the end of files look like hyper-civilized discourse in comparison. (Though, it might be an interesting discussion regarding making the hypothetical require_code only (directly) include files that are pure code, with no <?php ?> tags allowed.)

Personally, I think the cognitive overhead the <?php ?> tags impose is pretty tiny. Yeah, you get weird errors sometimes, but once you understand what's going on, it's easy to fix (and generally easy to spot, if you're using version control). I really can't recall the last time it's happened to me and it took more than ten seconds to identify and fix. It's just one of the weird things about php. Every language has its rough edges, and in comparison, I really don't think this one even ranks in the top ten. There are plenty other parts of PHP that are far more awkward that could use addressing first (but won't, because of the bc break involved; haystack, meet needle).

You could also view <?php at the top of the file as a sort of magic number indicating the file type (such as used in many binary file formats: gifs always start with GIF87a/GIF89a, java class files with 0xCAFEBABE, etc). It's unlikely a file that starts with <?php is anything but.

-John

> 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.
>
> On Sat, Apr 7, 2012 at 9:50 AM, John Bafford <[email protected]> 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 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 (:
>>
>> That "silly annoyance" doesn't seem to bother anyone who writes command 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 not affirmatively indicate the file type or whether or not it can be executed.
>>
>> Also, from a CLI perspective, you don't want extensions in the names of 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
>

--
John Bafford
http://bafford.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Am 07.04.2012 16:23, schrieb Tom Boutell:
> On Sat, Apr 7, 2012 at 10:06 AM, Reindl Harald <[email protected]> wrote:
>> why do you simply not realize that you have way too few knowledge
>> and tchnical education to partly understand the side effects
>> small changes in a general behavior are having
>
> *Sigh*
>
> See this?
>
> http://php.net/manual/en/book.image.php
>
> That's my doing, fella. I am the original author of the gd library
> functions described there and the originator of the PNG file format
> project as well. You have probably been using my work in your PHP code
> for years, if you have done much image manipulation with PHP (although
> there are some fine alternatives as well of course). I also wrote the
> original WWW FAQ (circa '94) and have helped promote the open web ever

that leaves the question open what terrible happened in
your life between all that and the proposals last night
which sounded naive like from a child?

don't get me wrong and with all respect for the work
you have done - that's not an excuse for bring out
proposals like you did or even makes them more worse
as if they are coming from a completly newcomer because
you should know it better

said that: writing good libraries and books makes you not
automatically to a good designer for a programming language

On Sat, 7 Apr 2012, Reindl Harald wrote:

> Am 07.04.2012 16:07, schrieb Derick Rethans:
> > On Sat, 7 Apr 2012, Reindl Harald wrote:
> >
> >> and no the world is not turning around you or even around PHP
> >
> > I will once more suggest you tune down your language on the
> > mailinglists. It's often rude and offensive. Let this be your last
> > warning
>
> and what is there exactly rude?
>
> this is simply the truth
> or do you believe the world is turning around one person or PHP?

But it is certainly also not resolving around you.

You repeatly call people stupid, or "like a child" or "what terrible
happened in your life" and that is *not* allowed behaviour here. If you
(or anyone else for that matter) can't refrain from that, you have no
place on this list.

Derick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Apr 7, 2012, at 10:53, John Crenshaw wrote:

> I don't like this, but it's closer. I hate the idea of adding a whole mess of one-off functions just to support a single coding style feature that doesn't seem to have very much support. There are a variety of other ideas that have been floating around that request changes to how the parser handles specific code (different short tags, sandboxing, auto-escaping, etc.).
>
> What if you have just ONE function with a variety of options? Something like:
>
> execute_file('path/to/foo.php', array(
> 'require'=>true,
> 'once'=>true,
> 'begin_code'=>'<?php ',
> 'shorttags'=>array('<?=','?>'),
> 'autoescape'=>function($str){return htmlentities($str, ENT_QUOTES | ENT_HTML5, 'UTF-8');},
> ...
> ));

While there's some elegance with your execute_file (there'd definitely be benefits to one function instead of the four we have now), the extra options would spawn so much Daily WTF material it wouldn't be funny, and I think most people would just stick with include/require/*_once because there'd be a lot less effort in the common case.

> This would provide a single consistent hook for any further DSL like features without impacting the behavior of any existing code. Some other options that might make sense:
>
> lint (like command line)

Actually, it'd be pretty cool to be able to lint a file without having to include runkit (there is a runkit_lint($code)) or make an external call to php -l.

> end_code (similar to command line, corresponds with begin_code (also command line))
> args (also command line)
> Any PHP_INI_ALL directives
>
> John Crenshaw
> Priacta, Inc.


-John

--
John Bafford
http://bafford.com/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

> that leaves the question open what terrible happened in your life between all that and the proposals last night which sounded naive like from a child?

> Don't get me wrong and with all respect for the work you have done - that's not an excuse for bring out proposals like you did or even makes them more worse as if they are coming from a completly newcomer because you should know it better

> said that: writing good libraries and books makes you not automatically to a good designer for a programming language

Every single reply from this guy in the last 24 hours has been childishly insulting and immature, and only one has contained anything more than personal attacks. Who moderates this list and enforces the rules? Can we please boot this guy, at least temporarily? He's contributing nothing to the discussion and appears to be truly incapable (both in action and by his own admission) of communicating in a civil way. We don't need this here. There have been multiple requests for him to stop from multiple people and it's not getting any better.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Apr 7, 2012 at 4:22 PM, Derick Rethans <[email protected]> wrote:

> You repeatly call people stupid, or "like a child" or "what terrible
> happened in your life" and that is *not* allowed behaviour here. If you
> (or anyone else for that matter) can't refrain from that, you have no
> place on this list.
>
> Derick
>

Couldn't agree more. The behavior exhibited by some people on this list is
disgraceful. This is just the latest example IMO.

Thanks,
Kiall

He's done.

On 04/07/2012 08:27 AM, Kiall Mac Innes wrote:
> On Sat, Apr 7, 2012 at 4:22 PM, Derick Rethans <[email protected]> wrote:
>
>> You repeatly call people stupid, or "like a child" or "what terrible
>> happened in your life" and that is *not* allowed behaviour here. If you
>> (or anyone else for that matter) can't refrain from that, you have no
>> place on this list.
>>
>> Derick
>>
>
> Couldn't agree more. The behavior exhibited by some people on this list is
> disgraceful. This is just the latest example IMO.
>
> Thanks,
> Kiall
>


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Apr 7, 2012, at 7:00 AM, Tom Boutell <[email protected]> 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 <[email protected]> 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 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 (:
>>
>> That "silly annoyance" doesn't seem to bother anyone who writes command 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 not affirmatively indicate the file type or whether or not it can be executed.
>>
>> Also, from a CLI perspective, you don't want extensions in the names of 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

On Apr 7, 2012, at 7:00 AM, Tom Boutell <[email protected]> wrote:

> That's a good point too.
>
> I think this is a better proposal:
>
> ...

Tom, sorry! For some reason I thought Tony :). On my phone... Not as
intuitive as my desktop...

Luke

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

A thoughtful suggestion. But the trouble with a php.ini setting is that you 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 available. And no one has to type them outside of an auto loader (:

Sent from my iPhone

On Apr 7, 2012, at 11:46 AM, Luke Scott <[email protected]> wrote:

> On Apr 7, 2012, at 7:00 AM, Tom Boutell <[email protected]> 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 <[email protected]> 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 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 (:
>>>
>>> That "silly annoyance" doesn't seem to bother anyone who writes command 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 not affirmatively indicate the file type or whether or not it can be executed.
>>>
>>> Also, from a CLI perspective, you don't want extensions in the names of 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

On Apr 7, 2012, at 9:04 AM, Tom Boutell <[email protected]> wrote:

> A thoughtful suggestion. But the trouble with a php.ini setting is that you 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 available. 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 before:

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 <[email protected]> wrote:
>
>> On Apr 7, 2012, at 7:00 AM, Tom Boutell <[email protected]> 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 <[email protected]> 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 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 (:
>>>>
>>>> That "silly annoyance" doesn't seem to bother anyone who writes command 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 not affirmatively indicate the file type or whether or not it can be executed.
>>>>
>>>> Also, from a CLI perspective, you don't want extensions in the names of 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
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

hi Tom,


On Sat, Apr 7, 2012 at 3:26 PM, Tom Boutell <[email protected]> wrote:
> 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:

Please put that in a RFC.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php