Let me say that I've been following this thread for some time now and what I'm
seeing is a lot of poorly communicated ideas with very little thought
and a lot of
snappy retort.

> We can walk and chew gum at the same time.  Just because more immediate
> concerns exist doesn't mean that looking at longer-term issues (keep in
> mind that people are suggesting this for PHP 6, which is quite a ways off)
> doesn't mean it's invalid.  Likewise, the fact that some people might not
> think this is important doesn't mean that discussing it because some people
> do think it is important is a waste of time.
>
> People bring up issues on this list all the time that I don't think are
> important, but I have enough respect for them not to derisively post that
> their issue isn't imporant or that they're wasting everyone's time.  I
> don't think it's unreasonable to expect that such respect would be
> reciprocated.
>

First, I see people saying this idea is a not a good idea for X, Y,
and Z reasons.
I don't really see a lot of objective responses as to why it's a good idea as
opposed to it being a bad idea. So the response here should not be one of
a straw man fallacy. I doubt anyone is really trying to disrespect you just for
your suggestions. I think it's more to the fact that the suggestion is poorly
supported as being something worth implementing.

>
> Please refer to my previous posts on the matter.  For me at least, this
> isn't about saving a 5-byte tag.  It's about making it easier to structure
> your code with a stronger separation between design and backend function.
>
>

As to this point it doesn't fall in line with what PHP is. PHP is meant to be
embed-able. It's meant to be easy. It's meant to make the development
process fast and simple.

It isn't meant to be difficult or painful. It isn't meant to create impenetrable
separation between code and design. That won't make anything easier on
the user. If anything you've just created a border they now have to figure out
how to cross over. Why are you insisting that this separation isn't already
easy enough to achieve with PHP? Because to me it always has been easy.
I've been doing it for 6 years. I haven't found anyone that thinks the process
is incredibly difficult or hasn't been able to achieve it in reasonable time.


>
> I think you guys are stressing-out about the file extension idea a little
> too much, and here's why:  What I'm proposing with regard to the .phpp
> extension is a convention, nothing more.  The actual differentiation will
> be in the form of a separate handler that's essentially identical to the
> current one except for the few minor changes outlined in the RFC.  In other
> words, the .phpp extension is NOT mandatory.  Just as .php is a convention,
> so is this.  If you want to give it an entirely differnet extension in the
> webserver configuration, you can do so.  The .phpp is just what the
> convention calls for, but in actuality what matters is that it's just a
> different extension than what you're using for regular PHP scripts.
>
> So I would urge everyone to calm down on this point, because I'm not
> proposing anything new in terms of how file extensions are used.  I would
> liken it to the difference between .php and .phps.  You can give them
> whatever extension you want, so long as they're different.  Make sense?
>

I would urge that if you're going to make a suggestion you address in
an objective
manner what the pros and cons of said suggestion are and not take a biased view
by weighing both sides of the facts evenly.

I believe for the most part a lot of voices have weighed in on the
cons of this idea
as well as the pros and the cons seem to be clearly outweigh any of the pros.

The supporting argument for that fact being that I'm seeing this RFC
being rewritten
as regularly as I take my morning coffee.

I respect everyone's right to their opinion and I'm willing to hear
anyone out that is
willing to consider both sides of the situation objectively and without biased.

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

Reply via email to