On Sun, Apr 15, 2012 at 2:30 AM, Lester Caine <les...@lsces.co.uk> wrote:
> Kris Craig wrote: > >> I object significantly to a few points here. One is the concept of a >>> > magic file extension. Why should a file behave differently just >>> > because of a different extension? In general, extensions are human >>> > readable clues to what's in the file. Yes, they are usually used for >>> > mime type hints, but relying upon them feels dirty. And especially >>> > baking in the reliance into the language really makes me feel dirty... >>> > I'm not saying not to do it, but it's not exactly the cleanest >>> > solution. >>> > >>> >> Anthony, *please read the thread before responding to it!! *I JUST >> >> addressed this a couple emails ago! There is no "magic" file extension. >> It's only a convention. Nothing more, nothing less. It is no different >> than how .php and .phps are handled. The convention dictates those >> extensions, but they're identified by the actual handler, as this would >> be. >> >> Understand? >> > > The problem with 'conventions' is that people use them ... just as now > many frameworks and libraries drop the ?> ... That is not forced on us, and > I'll be honest - I put them back! - I am free to do that. But if libraries > start moving to YOUR preferred method of working, then where do *I* stand. > I'm not allowed to put the ?> back, and I can't easily identify php files > because the <? is missing - yes I deliberately missed off the php simply > because the application that pays MY bills still uses short tags! Even that > simple change would be a considerable amount of work just because every > site has it's own much modified set of files ... all php with embedded html > ... which have evolved locally over 10 years. THAT is the real strength of > php ... I don't have to compile anything and changes to one 'function' on > the browser don't affect other pages. I now have all of the 'variant's' > archived on an hg DVCS but building a 'pure' copy of every one and testing > it would take weeks. This is why back tracking to PHP5.2.x is SO attractive > ... even if I have to maintain my own 'security' updates. All these > 'little' changes build into a situation where even PHP5.2 code simply does > not run easily ... > > A separate 'thorn' is that while *I* feel I spend a lot of my time > contributing to PHP via other open source projects that we use with php, I > don't contribute in a way that actually allows me a vote on this, and I'm > sure there are others who are in the same boat :( > Whether frameworks adopt rules to use that standard or not is of course out of our control. I suspect that different frameworks will have different internal debates on this and decide what's best for them and their users. Also, working within that separation is far less scary than people who aren't accustomed to it seem to think. I was intimidated by it at first when I found myself working for an employer that required it, but I quickly fell in love with the approach as it makes things SO much easier! =) But at any rate, PHP won't lose its embedded strengths. PHP 6 will, by definition, be significantly different from PHP 5, so either way there's going to be some normal growing pains involved, though I really don't think this will be nearly as problematic as you fear. Also, if we do go with a third per-file type in addition to the per-stack type, while I personally don't see any real value in doing it that way, that should at least alleviate your concerns regarding framework adoption. I would suggest we turn our focus on that for the moment and see what ideas emerge. --Kris > > ( AND lets trim some of the reams of quoting - I gave up reading the over > night posts after 20 minutes! I don't have the time ... ) > > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - > http://lsces.co.uk/wiki/?page=**contact<http://lsces.co.uk/wiki/?page=contact> > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - > http://www.firebirdsql.org/**index.php<http://www.firebirdsql.org/index.php> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
