Re: [PHP-DEV] Re: internals Digest 13 Apr 2012 01:23:19 -0000 Issue 2650

[Kris Craig]

On Sat, Apr 14, 2012 at 10:16 PM, Anthony Ferrara wrote:

> Kris,
>
> > As discussed on other threads, PHPP files that are called directly from
> the
> > webserver are handled by the SAPI handler and thus don't need any special
> > identification.
>
> Except that they do.  Right now, SAPI handlers just invoke PHP.  So
> there would need to be some way of communicating the difference over
> the SAPI.  And in most of the SAPIs, that's not really practical.  So
> for most SAPIs, it would require running two instances for each site,
> one for "regular" php, and one for the new phpp.  Given the problems
> that this can ensue, I think that there's an issue with that concept.
>

I'm not convinced of that, but again the technical specifics of how that
would be handled are still up in the air.  If you have a better idea
regarding how to implement that, please share it.  It would be illogical to
suggest that all viable approaches have been discounted since no real
brainstorming on this has happened yet; just people crossing their arms and
saying, "No that won't work, go away."

I appreciate your skepticism, but if you really want to be helpful, please
try to offer some suggestions of your own so we have more to brainstorm
with.


> So again, we're back to configuration...
>
> > If they are called as includes, this would be handled
> > either through a new keyword or a  file.
> >  The latter approach is my preferred choice but I'm keeping an open mind
> on
> > this question since there have been some differing opinions on that.
>
> Now I'm even more confused.  So instead of making a  entirely (just source), you're just making a new syntax which
> disallows ?>???
>

Again, please catch-up on the conversation that has taken place up till
now.  You're basically turning the clock back on things that have already
been discussed.  Some of them are still open-ended, so right now you're
really not helping.  Also, keep in mind that this is why the RFC doesn't
specify these things yet, because they're still being brainstormed and
debated.


>
> > I didn't mention this in the RFC because I wanted to see if we could
> reach
> > some sort of consensus on that point here first, but instead the
> > conversation has drifted onto wild tangents.  These other threads were
> > discussed literally just hours before this one so I just naturally
> assumed
> > that people who commented on this had followed them as well and knew
> this.
> >  But in hindsight I can see how somebody seeing the RFC without having
> > kept-up on recent Internals discussions could be confused by that, so
> I'll
> > go ahead and amend the RFC to clarify this point.  But no, the file
> > extension itself is not what determines how it's parsed.  ;)
>
> Ok, let me ask for something then.  Please demote this RFC to draft
> status.  Under discussion indicates (to me at least) that we're
> discussing a particular technical solution prior to a vote.  But if
> there's no technical solution, and it's still changing (or supposed to
> change), it should be in draft.  Otherwise you're communicating that
> it's ready to be considered when it's really not...
>

I disagree with that interpretation.  To me, "In Draft" means that the core
of the RFC is not complete and is thus not ready to be discussed.  Once it
is ready to be discussed, the status should be updated accordingly.  The
brainstorming phase regarding specific "how"s is part of that discussion in
many cases.  You'll notice that the status message is, "In Discussion,"
not, "In Debate."

I would be open to creating a new status, perhaps "Planning Discussion" or
something to that effect, but I do not believe the "In Draft" status would
be appropriate for an RFC that already communicates the concept/idea being
proposed, even if key details are still yet to be determined.


> > Did you just read the first sentence of that paragraph then ignore the
> > rest?!  Because everything after "per se" answers your question already.
>
> Actually, it doesn't.  The "problem" you identified isn't solvable by
> this method.  We already proved that.  So my original question stands.
>  What is the problem that you're trying to solve.  The rest of that
> paragraph tried to defend the usefulness of the addition.  That's not
> a problem to solve.  By clarifying this into a clear and concise
> problem statement, you may be better results with the RFC...
>

You may disagree with the answer, but it is an answer nonetheless.  If you
don't believe it's something that is worth solving, that's your opinion,
but my answer is what it is whether you choose to accept it or not.  My
original answer stands.  I have no intention of repeating myself.

If you want to learn more, please refer to recent discussions on Internals
where this has been explored much more in depth.


>
> > I think you misinterpreted the "problem."  The problem isn't output being
> > sent to the browser via PHP commands/functions.  The problem is raw HTML
> > code being sent to the b

Re: [PHP-DEV] Re: internals Digest 13 Apr 2012 01:23:19 -0000 Issue 2650

[Kris Craig]

On Sat, Apr 14, 2012 at 8:40 PM, Anthony Ferrara wrote:

> Kris,
>
> > You do realize you just proved my point, right?  I said that, because
> only a
> > small few people were actually participating in this thread, it would be
> > completely disingenuous for one side or the other to claim to represent
> the
> > majority opinion.  The fact that you stepped in does not change that,
> though
> > I'm glad more people are starting to share their opinions.
>
> All I'll comment on this is that it works both ways.  Just because
> there appears to be vocal support for this, doesn't mean that the
> majority of developers support it.  That's what a vote is supposed to
> solve.  So let's get past the "number of people who want feature x"
> argument, and look at the technical details of the proposal only
> (which is what this discussion phase is supposed to be)...
>

True.  Of course, I've never claimed that a majority supports it.  A number
of people do want "feature x" as you put it and that's the reason I created
this RFC.  What the majority thinks, your guess is as good as mine.  I'm
content to let the RFC process handle all that.


>
> > 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.
>
> Actually, I did read the emails.  And if I'm not mistaken, you said
> this (and I quote):
>
> >  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, if it's not a configuration setting, how is the parser supposed to
> determine which way it should handle an include call?  How should it
> determine how a request should be handled?  Realistically, the only
> way this can work in the real world is with a configuration setting.
> And I say the real world, because it would need to work at the PHP
> entry point, not at the server itself.  Otherwise, we'd be coupling
> the application instance to the server configuration.  Which would
> basically make this feature a non-starter for shared hosts (and hence
> the majority of PHP users).  So, in practice, the only way it could be
> implemented is as a configuration setting.
>
> If you see another way of it working, please elaborate.  Because at
> this point, I haven't seen any technical aspects of the RFC that
> clarify it any further.  If you do clarify it, please by all means
> let's discuss that.  But as of now, I can only go on what I see and
> read, and that points to a config setting.
>

As discussed on other threads, PHPP files that are called directly from the
webserver are handled by the SAPI handler and thus don't need any special
identification.  If they are called as includes, this would be handled
either through a new keyword or a 
> > I'm sorry if I'm being a bit testy on this point, but it's REALLY
> annoying
> > when people post patently false claims about what the proposal says.
>
> That's part of the problem here.  The proposal doesn't say much.
> Sure, it points out a theoretical solution, but no technical one.
> Without the details of how it would be technically implemented, I'm
> not sure what you're expecting the discussion to be based on...
>

The technical details will be added as the conversation progresses.  We
were making some good progress on other threads, but then this one just
dived into a tailspin and became dominated with "this will destroy PHP!"
nonsense.  I'll see about adding some additional details to get the
conversation back on track, but I don't want to get too specific on points
where people are still debating the best approach.

The primary characteristic of this RFC is the fact that this occurs on a
per-stack basis and is not dependent on INI settings or other ad hoc
solutions, though some of the specifics on that are still pending (keep in
mind I only drafted this RFC a couple days ago).  It might have helped to
include links to the related RFCs to give people context, but I didn't want
to risk people getting them confused (even though that seems to have
happened anyway lol).


>
> > I don't necessarily see the current behavior as a "problem," per se.
>  But I
> > do believe that having the ability to create a pur

Re: [PHP-DEV] Re: internals Digest 13 Apr 2012 01:23:19 -0000 Issue 2650

[Kris Craig]

On Sat, Apr 14, 2012 at 8:07 PM, Sherif Ramadan wrote:

> > Please review these things, *then *post a response.  Thank you.
> >
> > --Kris
> >
> >
>
> Alright, perhaps we should address one thing at a time. Since you feel
> you are repeating yourself I will alleviate repetition with manageable
> questions that are fair and concise. I start reading your RFC and the
> very first thing I come across is the title:
>

If you had started reading the RFC before posting several times about it, I
would never have had to repeat myself in the first place lol.  But I'm glad
you finally chose to at least look at it.


>
> "Request for Comments: New File Type for Pure-Code PHP Scripts"
>
> My very first indication of what I'm about to read is that you are
> proposing a "New File Type" for PHP, which you seem to contrarily
> refute that you are doing. Yet, your title is clearly stating as much.
> Now, I continue on reading the "Abstract" of your RFC. Which is
> supposedly going to give me some fair and over-all indication of just
> what it is you are requesting comments for...
>

When I asked that you read before posting, that didn't somehow translate
into, "Please nit-pick over meaningless semantics like the RFC title."


>
> "This RFC proposes the creation of a new .phpp file type. This file
> type will be parsed by the webserver as 100% PHP code; that is, all
> code will be executed without  tags. No raw HTML output
> would be allowed in these scripts using ?>, though echo/print and
> other output statements will continue to work in those scripts without
> any restriction."
>
> Everything that abstract states me seems to be completely contrary to
> everything you're stating in this thread. So clearly the need for you
> to repeat yourself is only due to the fact that you aren't
> communicating your efforts clearly. Not that other people aren't
> reading what you're writing.
>

How so?  The RFC proposes the creation of a new .phpp file convention.
 Where in the RFC does it state that the current PHP configuration that
uses SAPI handlers will be abolished in favor of string-matching file
extensions instead?


>
> Please change your RFC to reflect the true nature of your proposal and
> what you actually intend to propose. That way we won't have this
> unnecessary repetition in the list and this frustration you're getting
> from having to go back and forth.
>

See above.  You're just taking the fact that the RFC proposes the new file
extension convention and re-defining that to mean that handlers will be
abolished.


>
> Until I can clearly understand what it is you are proposing just from
> the very first few lines of your RFC I honestly don't see anything
> else worth arguing over since your entire abstract seems to contradict
> every word you're saying.
>

Ok, so let's recap what your last email basically said thus far:


   1. I will now read your RFC for the first time, even though I've been
   criticizing it for awhile already.
   2. The title of the RFC sucks.
   3. The RFC proposes creating a new file extension convention; therefore,
   it proposes to eliminate SAPI handlers.
   4. You should rewrite the RFC to say that you want to eliminate SAPI
   handlers so that it will match my characterization of it.
   5. Until you rewrite your RFC to match my criticisms, I see no reason to
   read it any further.
   6. I will now go back to just criticizing it without actually being
   informed.



> Author: Kris Craig kriscr...@php.net
>
> I'm reading the correct RFC, am I not? This is *your* RFC? I'm not
> confusing this with anyone else's am I?
>

No, you're not.  You're completely redefinining it, in fact.  See above.

You did get the author part right, at least.


>
> Please modify your RFC title and abstract to tell me in a few short
> and concise sentences precisely what you're proposing that doesn't
> contradict everything you're telling us in the mailing list and I will
> be glad to give it further consideration. :) Thanks
>

See above.  You're just twisting the meaning in a rather peculiar way to
fit what you've been saying.  The RFC does NOT propose eliminating SAPI
handlers.  Your contention that proposing a new filename convention is the
equivalent to eliminating SAPI handlers is, well, insane.  If you want to
explain that odd premise, be my guest.

If your criticism was simply that the wording should be clearer to minimize
confusion, I wouldn't have any problem with that.  Instead, you gave it a
wildly ridiculous interpretation and then used that as a basis for
essentially accusing me of lying and condemning the RFC as some sort of
diabolical effo

Re: [PHP-DEV] Re: internals Digest 13 Apr 2012 01:23:19 -0000 Issue 2650

[Kris Craig]

On Sat, Apr 14, 2012 at 5:04 PM, Anthony Ferrara wrote:

> Kris,
>
> > It's worth noting that there are already two other similar RFCs that have
> > been proposed and other people have expressed interest in this idea.
>  Most
> > of the opposition on this thread has come from 2 people, one of whom has
> > been mostly posting hyperbolic claims and scare tactics.  There hasn't
> been
> > much substance for me to actually respond to.
>
> Yes, that's true.  However, there have been a lot of people who have
> stayed out of the conversation completely.  I have been one of those
> people.
>

You do realize you just proved my point, right?  I said that, because only
a small few people were actually participating in this thread, it would be
completely disingenuous for one side or the other to claim to represent the
majority opinion.  The fact that you stepped in does not change that,
though I'm glad more people are starting to share their opinions.


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

I'm sorry if I'm being a bit testy on this point, but it's REALLY annoying
when people post patently false claims about what the proposal says.
 Seriously, what do you want me to do here? Argue in favor of something
that my proposal doesn't seek to do in the first place?!  Or agree that the
proposal is bad because changing PHP to be parsed based on file extension
is bad, even though my proposal *does not propose that*?!

I welcome criticism, but please let that criticism at least actually *apply* to
the proposal I'm making!  You're literally attacking a completely
fictitious idea that is not a part of this proposal.  The .phpp extension
is a convention; you can name it whatever the hell you want, though, so
long as you've got the right handler set.  Just like with .php and .phps.

Seriously, *please don't make me repeat myself again on this*, ok?  As you
might have noticed from all the bold letters in the last few paragraphs,
that tends to be a pet peeve of mine lol.  =)


> However, please not another feature that is dependent upon
> configuration.  The past usages of the php.ini file have lead to
> really difficult problems to solve, tons of boilerplate code and
> inconsistent behavior.  Over the past few versions of PHP, those
> offending ini settings have been slowly phased out.  That's not saying
> ini won't effect behavior, but it won't effect runtime behavior.
> Sure, you can disable extensions, but you don't change how files are
> executed (like register_globals and magic_quotes did).  Yes, you can
> effect internal behavior (like session settings), but that isn't
> exposed to PHP for the majority of usages.  Please don't introduce new
> behavioral settings.
>

*sigh*

Again, that's not what this proposes.  In fact, this RFC doesn't even
mention php.ini.  I think there is a separate RFC that does, but it's in a
different thread and is not in any way affiliated with this one, though
they do share a similar topic.

So far, you and I are in complete agreement.  I've already spoken out as to
why the .ini approach is troubling to me.  I've also made it clear that the
file extension isn't literally what's determining the type, but is rather
just a convention.  Are a lot of you confused on this point?  If so, I
suppose I could clarify the wording of the RFC to eliminate confusion.  To
reiterate, both of these things you've criticized are NOT a part of this
RFC.


>
> And the extension being ini dependent (as you said in this very email
> I'm replying to) would very much fall into that realm...
>
> While I'm replying, I might as well reply on the whole RFC:
>
> As far as the "problem" indicated, I don't see that as a problem that
> PHP itself needs to solve.  I see that as more of a lint problem.  And
> in fact, PHPCS (CodeSniffer) includes rules that allow you to check
> for this exact sort of thing.  So if you're concerned with people
> abusing `?>` in files, just add a rule, and you're done.  And if
> you're just complaining about typing 5 characters ` of files, I think that's a bit short sighted.  It's a major language
> change, and introducing inconsistent behavior to save typing 5
> characters...
>

Re: [PHP-DEV] Re: internals Digest 13 Apr 2012 01:23:19 -0000 Issue 2650

[Kris Craig]

On Sat, Apr 14, 2012 at 4:28 PM, Lester Caine  wrote:

> Kris Craig wrote:
>
>> Please review these things, *then *post a response.  Thank you.
>>
> If you want this SO badly, just fork a copy of PHP and implement it how
> you want it. That is at least the good thing to come out of moving the code
> management yet again ... if others want it as well they can clone from your
> copy, or from the other versions being proposed. The advantage of DVCS is
> that all of these ideas can be played with in parallel.
>

 Are you familiar with Godwin's Law?  It states that the probability of
somebody making a Hitler comparison approaches 1 as an online debate
progresses and is often interpreted to mean that the first person who
invokes such a comparison in an online argument automatically loses said
argument.

I think we should consider adopting a similar law on the Internals list for
people who respond to RFCs with, "If you don't like (the suggestion | the
way PHP currently behaves), why don't you just (create your own fork | find
another language)?"

It has been my observation that this point almost inevitably winds up being
made if a debate regarding any sort of change goes on long enough.
 Sometimes it's used to attack a new idea, other times it might be used to
attack someone who opposes a new idea.  In both instances, it amounts to
little more than a clumsy, heavy-handed way of declaring, "I represent true
PHP and you don't, so shut up and go away."  It doesn't actually add any
constructive substance to the debate and typically just serves to anger the
receiving party, as it essentially comes across as arrogant and dismissive.

So no, I will not dignify your forking demand with a direct response.  You
don't "speak for" PHP any more than I do, so you don't get to declare what
gets "forked" and what doesn't.  That's a main reason why we now have an
RFC process.  Whether or not it passes will come down to the vote.  So in
the meantime, let's stick to discussing the issue on its merits, ok?

Oh and if anybody has any suggestions on what to call this new "law" I
conjured-up, I'd love to hear them!  Super bonus points go to funny and/or
ridiculous names.  =)


> I have yet to be convinced there is any merit in forcing this on everybody
> else, so something that can be loaded just by those who want it seems the
> logical way forward. If it does get included in the general distribution,
> then I WILL be branching my own copy of PHP and leaving it off!


Umm since when does creating/discussing a proposal that is ultimately voted
on by the community constitute "forcing [it] on everybody else?!"  This is
another example of the hyperbolic rhetoric I've been referring to.  The
community will decide by a majority vote whether or not this should be a
feature in PHP 6.0.

By threatening to branch your own competing version of PHP if everybody
doesn't vote your way, isn't it *you* who's trying to force your agenda on
everybody else?

--Kris


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

Re: [PHP-DEV] Re: internals Digest 13 Apr 2012 01:23:19 -0000 Issue 2650

[Kris Craig]

On Sat, Apr 14, 2012 at 3:25 PM, Sherif Ramadan wrote:

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

It's worth noting that there are already two other similar RFCs that have
been proposed and other people have expressed interest in this idea.  Most
of the opposition on this thread has come from 2 people, one of whom has
been mostly posting hyperbolic claims and scare tactics.  There hasn't been
much substance for me to actually respond to.

Regarding the specific comment, it was in response to a far-overused cliche
on this list whenever new ideas are posted; "That's not important, we
should be working on other things."  It always annoys me when people post
that, because it doesn't amount to any specific criticism and it assumes
that talking about one thing prevents us from working on another.


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

This RFC doesn't change any of that.


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

PHP has evolved over the years and its usage has evolved.  I would
encourage you to read the background section of the RFC, as I've already
addressed this.

The reason why I'm not responding to certain points is because I've already
addressed them in the RFC and, as a general rule, I try not to be dragged
in to arguments where I'm essentially just repeating myself over and over
again.  If somebody can't be troubled to read the RFC and my posts before
responding to them, then why should I assume they'll read it if I repeat it
x number of times?  To me, THAT is what would actually constitute a waste
of 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

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Sat, Apr 14, 2012 at 11:29 AM, John Crenshaw wrote:

> Sent: Friday, April 13, 2012 3:39 PM
> > On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw <
> johncrens...@priacta.com> wrote:
> > > > >
> > > > > On top of this, there's an argument that you're not addressing:
> most
> > > > > template engines in PHP either directly consume PHP template
> files...
> > > > > or "compile" templates into... PHP template files. As such, sooner
> or
> > > > > later, you'll have a class that includes a PHP template file, and
> > > > > that's where things break for me in this proposal.
> > > > >
> > > >
> > > > They don't break because nobody in their right mind would ever try to
> > > > include a .phpp file in a framework like that.  If its stack is so
> entangled,
> > > > the very notion of a pure PHP stack is just incompatible.  So your
> best bet
> > > > on a framework like that would be to stick with .php.
> > > Um, so if you aren't using any form of template engine whatsoever,
> what are you
> > > proposing? You're saying we should all go back to the good ol' C days
> of trying
> > > to put together valid markup using string concatenation? (Or worse,
> manipulation
> > > of DOM classes?) No thanks. IMO this is a bit like blowing up London
> to stop a
> > > jaywalker.
> >
> > That's a logical fallacy; i.e. your contention relies on the premise
> that, if this
> > doesn't work with every single framework known to exist, then it doesn't
> work with
> > any template engine whatsoever.  That's just patently ridiculous and
> could not be
> > further from the truth.
>
> I think you missed the problem entirely. All but a tiny handful of
> template engines (and ALL of the template engines that are fast and
> powerful enough to use as the view component for a site) compile into PHP
> templates. Once something is included in the way you propose there is no
> longer ANY viable view option. The only way to output anything at that
> point is with strings and echos. The entire reason PHP became popular in
> the first place is because it was a first class template language. Web
> development is, at the end of the day, metaprogramming.
>

As I said, this is NOT an inherent conflict.  What it comes down to is
*how* this
"compilation", as you put it, is taking place.


>
> > > After a lot of thought I've decided that I'm strongly opposed to the
> nature of
> > > this proposal at a fundamental level. It isn't that I just wouldn't
> use it. This
> > > proposal is inherently destructive to the PHP development community.
> This
> > > effectively attempts to split PHP into two languages. Current PHP
> isn't really
> > > compatible with the proposed ".phpp" version of PHP, in the sense that
> you can't
> > > safely use both in the same code base. Unfortunately this will not be
> clear to
> > > anybody at first, which will lead to mass proliferation of .phpp
> libraries which
> > > are like poison to any unsuspecting PHP user foolish enough to try to
> use one.
> > > This isn't just a BC thing, it is really a permanent language fork.
> >
> > A few points:
> > 1. How exactly will this single-handedly "destroy the PHP community"?  I
> will give
> > you bonus points for creative hyperbole, though.
>
> That's not what I said. I said it is "inherently destructive to the PHP
> development community." I stand by that. It segregates the community and
> effectively divides PHP into two languages that both seem (on the surface)
> to be the same thing. Problem is they're not really compatible. If they are
> used together one will eventually cause the other to break in confusing
> ways.
>

No, it doesn't.  I've already explained how your claim that it creates "2
languages" is inaccurate.  Simply repeating a false claim won't make it any
more true.  That, too, is a logical fallacy.

Also, if you claim that something is "inherently destructive to the PHP
development community," you're essentially saying that it will
single-handedly destroy the PHP community, which is an utterly ridiculous
statement no matter how you look at it.  That's what I mean when I refer to
cheap scare tactics.


> In this thread we've had people suggest that library developers should use
> this .phpp stuff. That's EXACTLY the problem I'm worried about. All it
> takes is one callback, one event, one autoloader, one error handler, one
> anything, and the entire application system falls apart because one library
> decided that it didn't need template mode.
>

And?  That same argument could be made to argue that the header() function
should be eliminated.  As we've seen in the separate threads about LFI, the
developer has to take some responsibility for not writing bad code.  The
problem you mention is *easily *avoidable.  If you're mixing your
autoloaders/handlers/etc in such an ad hoc fashion, then using that with
.phpp would not be a good idea.

Also, I've repeatedly offered a third solution that would alleviate
concerns raised about these specific cases, but you two have yet to even

Re: [PHP-DEV] Re: internals Digest 13 Apr 2012 01:23:19 -0000 Issue 2650

[Kris Craig]

On Sat, Apr 14, 2012 at 1:35 PM, Rasmus Schultz  wrote:

> > From: Arvids Godjuks 
> > To: Kris Craig 
> > Cc: PHP internals list , Yasuo Ohgaki <
> yohg...@ohgaki.net>
> > Date: Fri, 13 Apr 2012 03:26:16 +0300
> > Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP
> Scripts
> > Well, I just don't know how i can appeal to common sence to some people
> on
> > the list anymore. First the type hinting threads, now this.
>
> That was my reaction as well. Why someone would spend this much time
> and documentation on such a trivial issue, I'm at a loss. Don't we
> have bigger fish to fry?
>

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.


>
> > The world does not work only on one web server and there are different
> type
> > ls of them out there. I for once use nginx and i configure how to run
> > scripts by locations, not by file types. I just pass the params to
> fastcgi
> > server thet runs a php binary. And it does not.care about the extension.
> I
> > can use any extension.l for my code. Yes, i use .php, others use. phtml
> or
> > other variants. Extensions are just a convension, nothing more. You can
> > give a file any or none extension at all and it will not change a
> thing.Ok,
> > in windows you will not be able to open the file in a program by double
> > click, but through the open dialog in the app - be my guest. To PHP,
> > fastcgi and the web server it does not matter. It just matters to people
> so
> > they can distingush between a php file, js file and a css file.
>
> This is what I was thinking, plus this: the closing tag isn't even
> required to begin with, so you can really think of " file-header.
>

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.


> I don't see how getting rid of the file-type, and relying on
> file-extension instead, is in any way a good thing. For one, IDEs
> would need updates, because they use the opening tag to enable
> syntax-highlighting.
>
> If anyone should learn from this, it's the other way around - perhaps
> other scripting languages should use a small header to declare the
> language/file-type...
>

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?


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

[PHP-DEV] Outdated Central Repos == Security Vulerabilities, New Study Finds

[Kris Craig]

http://www.esecurityplanet.com/open-source-security/study-warns-of-security-flaws-in-open-source-components.html


This is EXACTLY why the prevailing mindset about central repositories needs
to change!  Keeping it at PHP 5.1 doesn't provide more "stable" and
"reliable" code.  It just keeps it vulnerable to things that were fixed
years ago.

--Kris

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Fri, Apr 13, 2012 at 1:02 PM, Matthew Weier O'Phinney <
weierophin...@php.net> wrote:

> On 2012-04-13, Kris Craig  wrote:
> > --f46d04447f47ae95ec04bd949e5f
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw <
> johncrens...@priacta.com> wrote:
> >
> > > > >
> > > > > On top of this, there's an argument that you're not addressing:
> most
> > > > > template engines in PHP either directly consume PHP template
> files...
> > > > > or "compile" templates into... PHP template files. As such, sooner
> or
> > > > > later, you'll have a class that includes a PHP template file, and
> > > > > that's where things break for me in this proposal.
> > > > >
> > > >
> > > > They don't break because nobody in their right mind would ever try to
> > > > include a .phpp file in a framework like that.  If its stack is so
> > > entangled,
> > > > the very notion of a pure PHP stack is just incompatible.  So your
> best
> > > bet
> > > > on a framework like that would be to stick with .php.
> > >
> > > Um, so if you aren't using any form of template engine whatsoever, what
> > > are you proposing? You're saying we should all go back to the good ol'
> C
> > > days of trying to put together valid markup using string
> concatenation? (Or
> > > worse, manipulation of DOM classes?) No thanks. IMO this is a bit like
> > > blowing up London to stop a jaywalker.
> > >
> >
> > That's a logical fallacy; i.e. your contention relies on the premise
> that,
> > if this doesn't work with every single framework known to exist, then it
> > doesn't work with any template engine whatsoever.  That's just patently
> > ridiculous and could not be further from the truth.
>
> Then point to ONE widely used, OSS templating engine or MVC framework
> that will be able to operate as pure PHP. (My mustache library does not
> count.)
>
> I'll give you time to look for one.
>
> Hint: I don't think you'll find any.
>

Why would I want to prove a point that I was never trying to make in the
first place?

I've never contended that there are frameworks that are 100% pure PHP
code.  That's not a requirement for .phpp anyway.  So I'm not sure why
you're introducing that idea all of a sudden.


>
> Most PHP template engines compile templates to HTML with embedded PHP.
> This does NOT mean that including such a PHP file immediately spits out
> output -- on the contrary: every PHP templating engine I've seen by
> default will use output buffering to allow capturing the output to a
> variable, which you _later_ spit out.
>

See above.


>
> This is one reason I'm very uncertain about your assertion that
> including an embedded PHP file taints the class including it, as well as
> any up the stack. The code itself is never really operating in "mixed"
> or "embed" mode -- only the template file itself is. If you insist on
> the tainting aspect, I honestly do not see this proposal gaining ground;
> few if any exising frameworks or template engines will gain anything by
> it, much less be able to take advantage of it, and the work necessary to
> make it possible makes it undesirable, except as an achievement ("look!
> I did it!").
>
> Finally, you're constantly dismissing the arguments that specifying a
> specific suffix is a bad idea -- but without making a reasonable
> argument as to why suffixes are okay.


That's false.  Please refer to my previous messages from today.  I
explained in detail why a filename extension is preferable to new
keywords.  Rather than forcing me to repeat myself, please read what I've
already posted on the matter.


> I personally write a lot of CLI
> scripts in PHP -- and typically do not give them extensions. Under your
> proposal, even those these do not operate in embed mode, because they do
> not have the "blessed" extension, they cannot omit the  is limiting, and goes against the idea of portability.
>
> I'm not going to go as far as John and claim it's an attack on existing
> users or anything -- but I will argue that you're ignoring very, very
> common use cases and patterns used in PHP, and over-estimating how
> likely people will want to use the feature as proposed knowing the
> limitations.
>

I think you're the one who is ignoring what's being said.  I offered a
compromise solution that addresses your concerns and neither of you have
even acknowledged it, let alone responded to it.  If you're not willing to
actually read my posts and look for common ground, then there's no reason
for me to say anything further.


>
> --
> Matthew Weier O'Phinney
> Project Lead| matt...@zend.com
> Zend Framework  | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw wrote:

> > >
> > > On top of this, there's an argument that you're not addressing: most
> > > template engines in PHP either directly consume PHP template files...
> > > or "compile" templates into... PHP template files. As such, sooner or
> > > later, you'll have a class that includes a PHP template file, and
> > > that's where things break for me in this proposal.
> > >
> >
> > They don't break because nobody in their right mind would ever try to
> > include a .phpp file in a framework like that.  If its stack is so
> entangled,
> > the very notion of a pure PHP stack is just incompatible.  So your best
> bet
> > on a framework like that would be to stick with .php.
>
> Um, so if you aren't using any form of template engine whatsoever, what
> are you proposing? You're saying we should all go back to the good ol' C
> days of trying to put together valid markup using string concatenation? (Or
> worse, manipulation of DOM classes?) No thanks. IMO this is a bit like
> blowing up London to stop a jaywalker.
>

That's a logical fallacy; i.e. your contention relies on the premise that,
if this doesn't work with every single framework known to exist, then it
doesn't work with any template engine whatsoever.  That's just patently
ridiculous and could not be further from the truth.

>
> After a lot of thought I've decided that I'm strongly opposed to the
> nature of this proposal at a fundamental level. It isn't that I just
> wouldn't use it. This proposal is inherently destructive to the PHP
> development community. This effectively attempts to split PHP into two
> languages. Current PHP isn't really compatible with the proposed ".phpp"
> version of PHP, in the sense that you can't safely use both in the same
> code base. Unfortunately this will not be clear to anybody at first, which
> will lead to mass proliferation of .phpp libraries which are like poison to
> any unsuspecting PHP user foolish enough to try to use one. This isn't just
> a BC thing, it is really a permanent language fork.
>

A few points:


   1. How exactly will this single-handedly "destroy the PHP community"?  I
   will give you bonus points for creative hyperbole, though.
   2. This does NOT split PHP into two languages.  In fact, there are no
   changes to the language in this RFC.  The only difference is a new file
   type that parses PHP without the need for a  raw HTML
   code not being permitted within that file type's stack.  Again, bonus
   points for wild hyperbole
   3. Current PHP is perfectly compatible with this, as would be many if
   not most implementations (some might require more work than others).  And
   those that aren't aren't being forced to use this new file type in their
   projects anyway.  I think what's at issue is the particular framework that
   *you* are accustomed to working with would not mesh well with this.  But
   that's a very narrow subset of PHP.  The language itself and probably most
   implementations of it would have no problem incorporating this if they
   chose to do so. The "all or nothing" mindset you're expressing is not
   logical.
   4. For the gazillionth time, *there is no BC break in this RFC!*  The
   language is not being redefined as you're characterizing it and .php files
   will continue to behave *exactly* as they do now.
   5. Using cheap fear tactics like "any unsuspecting PHP user foolish
   enough" and "poison" only serves to cheapen this discussion and erode your
   own credibility.


--Kris


> John Crenshaw
> Priacta, Inc.
>
>
> --
> I am using the free version of SPAMfighter.
> We are a community of 7 million users fighting spam.
> SPAMfighter has removed 839 of my spam emails to date.
> Get the free SPAMfighter here: http://www.spamfighter.com/len
>
> The Professional version does not have this message
>
>

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Fri, Apr 13, 2012 at 7:15 AM, Matthew Weier O'Phinney <
weierophin...@php.net> wrote:

> On 2012-04-13, Kris Craig  wrote:
> > On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur 
> wrote:
> > > //a controller, maybe a class, maybe just a set of functions, but in a
> > > .phpp file
> > > function getLoginPage()
> > > {
> > > //set up some data
> > > //some people like to use plain .php for templates
> > > include 'templates/loginPage.php';
> > > //other people like to use a View library
> > > $view->render('loginPage.tpl');
> > > }
> > >
> > > In the case of using a view object, your controller can be a .phpp
> file.
> > > In the case of the include, it cannot. Now consider the case of the
> > > implementation of the render() method:
> > >
> > > function render($template)
> > > {
> > > $compiledTemplate = $this->compile($template);
> > > include $compiledTemplate;
> > > }
> > >
> > > Now your render method cannot be in a .phpp file.
> >
> > Again, the controller should NOT be a .phpp file.  Likewise, your model
> > should NOT be hooking directly to the view.  The controller hooks to the
> > model.  The controller then sanitizes that and returns it to the view.
> > Alternatively, if you're not conforming to a pure MVC standard,
>
> Sorry, this is where you lose me. There's no "pure" MVC standard,
> particularly when it comes to MVC implementation on the web. There are
> many, many, many interpretations of how MVC works, and some generally
> accepted understanding around separation of concerns, but if you look at
> the ecosystem of MVC frameworks in PHP alone, you'll see that none of
> the frameworks do things the same way.
>

Yeah I went a bit overboard on the whole "MVC purity" soapbox.  I do
believe that this way is the correct approach, but deriding all other
architectures as "broken" was a bit much.


>
> On top of this, there's an argument that you're not addressing: most
> template engines in PHP either directly consume PHP template files...
> or "compile" templates into... PHP template files. As such, sooner or
> later, you'll have a class that includes a PHP template file, and that's
> where things break for me in this proposal.
>

They don't break because nobody in their right mind would ever try to
include a .phpp file in a framework like that.  If its stack is so
entangled, the very notion of a pure PHP stack is just incompatible.  So
your best bet on a framework like that would be to stick with .php.


>
> I think the "pure PHP" vs "embedded PHP" has to be determined in a
> file-by-file basis, if at all -- NOT based on whether or not a file is
> consuming a file that has embedded PHP. Once you go down that rabbit
> hole, as soon as you have one file with embedded PHP (and most likely,
> you will), you'll have to assume the entire project is. At that point,
> there's zero benefit at all to making a distinction.
>

I believe the exact opposite to be true.  If you expect a file you're
including to output *only* pure PHP code, but then it outputs a bunch of
HTML code, it shouldn't matter whether that code came from the file itself
or an included file.  The result is the same either way.  If that doesn't
treat them both the same, that lack of consistency basically makes the
whole point of including a pure PHP stack useless.

Alternatively, I suppose we could create a third type; one that goes on a
per-file basis instead of per-stack.  While I personally don't see any
value to this, a few of you are expressing a desire for that, so I'd be
willing to meet you halfway on this and add that to the RFC.


>
> The proposals to use a flag with include, or to provide a separate
> "script()" function for switching between pure PHP/embedded PHP make
> sense to me. These make it easy for a framework/project to provide
> autoloaders that choose the appropriate flag/function necessary to load
> the class, and to select the appropriate flag/function when including
> embedded artifacts. They also make auditing code easy -- you can grep
> for one or the other.
>

The problem with that is you're basically creating two separate methods for
parsing the same file.  Inherently, one of those methods will always work,
and the other method will always break.  That makes no sense to me.  If a
PHP script doesn't contain a  content, the only keyword
that would work is include()/require().  So that completely defeats the
whole purpose of having separate keywords, sin

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Fri, Apr 13, 2012 at 5:45 AM, John LeSueur wrote:

>
>
> On Thu, Apr 12, 2012 at 11:13 PM, Kris Craig  wrote:
>
>>
>>
>> On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur wrote:
>>
>>>
>>> On Thu, Apr 12, 2012 at 9:00 PM, Kris Craig wrote:
>>>
>>>>
>>>>
>>>> On Thu, Apr 12, 2012 at 7:51 PM, John LeSueur 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Apr 12, 2012 at 7:49 PM, Kris Craig wrote:
>>>>>
>>>>>> On Thu, Apr 12, 2012 at 6:35 PM, David Muir 
>>>>>> wrote:
>>>>>>
>>>>>> >  On 13/04/12 11:03, Kris Craig wrote:
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Apr 12, 2012 at 5:46 PM, David Muir 
>>>>>> wrote:
>>>>>> >
>>>>>> >>   On 13/04/12 10:04, Kris Craig wrote:
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On Thu, Apr 12, 2012 at 4:46 PM, David Muir 
>>>>>> wrote:
>>>>>> >>
>>>>>> >>>  On 13/04/12 09:38, Yasuo Ohgaki wrote:
>>>>>> >>> > Hi,
>>>>>> >>> >
>>>>>> >>> > 2012/4/13 Kris Craig :
>>>>>> >>> >> Per recent discussions, I have drafted an RFC for this.  This
>>>>>> proposal
>>>>>> >>> >> offers what I believe to be a more sane and realistic approach
>>>>>> to
>>>>>> >>> >> addressing the question of incorporating a new breed of
>>>>>> tag-less PHP
>>>>>> >>> >> scripts.
>>>>>> >>> >>
>>>>>> >>> >> https://wiki.php.net/rfc/phpp
>>>>>> >>> > This may work for LFI issue for new codes.
>>>>>> >>> > Few questions.
>>>>>> >>> >
>>>>>> >>> > CLI may use .phpp as PHP script always. (i.e. execute w/o >>>>> or
>>>>>> >>> else)
>>>>>> >>> > It's like DOS, though.
>>>>>> >>> >
>>>>>> >>> > How do you enforce .phpp as script only for Web?
>>>>>> >>> > Is it a rule for configuration? or .phpp just never supposed to
>>>>>> locate
>>>>>> >>> > under docroot?
>>>>>> >>> > It relates previous question. How about bootstrap script for
>>>>>> >>> frameworks?
>>>>>> >>> >
>>>>>> >>> >> A regular .php script cannot be included from a .phpp script.
>>>>>> An
>>>>>> >>> E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR
>>>>>> will be
>>>>>> >>> thrown for require; in both instances, the included file will be
>>>>>> ignored.
>>>>>> >>> > Some people may try to make .phpp handled by web.
>>>>>> >>> > I cannot tell if this setting is going to be popular, but if it
>>>>>> >>> > does, isn't it the end of embedded PHP?
>>>>>> >>> > It might be good if PHP is more tolerant for this usage.
>>>>>> >>> >
>>>>>> >>> > Regards,
>>>>>> >>> >
>>>>>> >>> > --
>>>>>> >>> > Yasuo Ohgaki
>>>>>> >>> > yohg...@ohgaki.net
>>>>>> >>> >
>>>>>> >>>
>>>>>> >>>  That's a huge WTF that a templating library can't be written as
>>>>>> .phpp,
>>>>>> >>> because it then won't be able to load a template.
>>>>>> >>>
>>>>>> >>
>>>>>> >> That's actually not true.  Please refer to the diagram embedded in
>>>>>> the
>>>>>> >> RFC.
>>>>>> >>
>>>>>> >> Basically, you can load a template just fine-- you just can't do it
>>>>>> >> directly from a .phpp file, which

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Fri, Apr 13, 2012 at 1:00 AM, Arvids Godjuks wrote:

> Kris.
>
> I can give you a real world example where that straight MVC with the. pphp
> if not breaks, then definetly becomes an ugly mess.
> I use Yii framework as my tool, it has some very nice tools for templating
> like widgets. Widgets provide a container to put functionalit required by
> multiple pages and it contains a controller like code and a template. It
> can and most times will use models and other library stuff to do its work.
> And all that code is loaded via an autoloader (only templates are loaded
> localy in a controller method).
>
> As i see it, i will spend a lot of time figuring out if i need to make a
> .php or a .pphp file. After a few days i will just say to my self "f***
> this sh**" and just stick with the .php. My coleague will just stick with
> .php - he values his time and to him this will be just noise that he
> ignores because it gives no real benifit, IDE's and editors will ajust in
> time and reformatting a whole project is just a waste of time. Not to
> mention frameworks will not follow for a long time because of the BC and
> big WTF factor.
>
As I said, if that is the case, then you shouldn't be using a .phpp file.
This new file type is NOT intended to replace .php, not even partially.
Most of your work will likely still be done in .php scripts.  This new
.phpp type is for specialized instances when you know you won't be using
raw HTML output.  This happens a lot, but it may not happen in your
application.  If it doesn't, then don't worry about it.  There's no "WTF
factor" to it and there's DEFINITELY *no BC breakage, period!*

If your application doesn't have a need for pure PHP code, then don't use
it.  I'm not sure why you think the mere existence of this file type will
somehow magically break all your .php files.

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Thu, Apr 12, 2012 at 11:37 PM, David Muir  wrote:

> On 13/04/12 15:13, Kris Craig wrote:
> > Again, the controller should NOT be a .phpp file.  Likewise, your model
> > should NOT be hooking directly to the view.  The controller hooks to the
> > model.  The controller then sanitizes that and returns it to the view.
> >  Alternatively, if you're not conforming to a pure MVC standard, the
> > controller can also hook to a regular .php file in the model and pass the
> > data to that.  Either way, it all passes through the controller.  The
> model
> > and view should never be interacting directly.  MVC or not, that's just
> bad
> > architecture and there are zero advantages to using such an ad hoc
> approach.
> >
> > If a developer insists on using such a broken model, however, they're
> more
>
> MVC is a broken model/bad architecture?
>

Arrooo?  Not sure where you got *that* from, as it's basically the exact
opposite of what I said


>
> > than welcome to!  That's what people love (and hate) about PHP.  It's
> > flexible.  They just won't be able to use a .phpp file upstream from
> that,
> > as it is by its very nature inherently incompatible with such a broken
> > model.  The only way to force it to be compatible would be to make the
> > .phpp file essentially meaningless.
> >
> > So if you're writing good code structure, a .phpp file will help you make
> > it even better.  If you're writing bad architecture, then just keep doing
> > what you're already doing and don't worry about using a .phpp file!  This
> > will in no way stop you from being able to do what you can already do in
> > PHP.  You're just insisting on wanting to use a pure code file for
> > something that it's not intended to be used for.  Just like having object
> > orientation added in PHP 5 didn't stop you from writing procedural code
> if
> > you want to, introducing this in PHP 6 won't stop you from writing
> > disorganized code if you still want to.  What this will do is provide a
> > valuable option for people who do feel that writing clean,
> role-segregated
> > code is important.
>
> So basically, the only parts that might be ok to write as .phpp are some
> model and utility classes?
>

Essentially, yes.  Despite your implication, often times these components
make up the vast majority of a modern PHP application.


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

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur wrote:

>
> On Thu, Apr 12, 2012 at 9:00 PM, Kris Craig  wrote:
>
>>
>>
>> On Thu, Apr 12, 2012 at 7:51 PM, John LeSueur wrote:
>>
>>>
>>>
>>> On Thu, Apr 12, 2012 at 7:49 PM, Kris Craig wrote:
>>>
>>>> On Thu, Apr 12, 2012 at 6:35 PM, David Muir 
>>>> wrote:
>>>>
>>>> >  On 13/04/12 11:03, Kris Craig wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Thu, Apr 12, 2012 at 5:46 PM, David Muir 
>>>> wrote:
>>>> >
>>>> >>   On 13/04/12 10:04, Kris Craig wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Thu, Apr 12, 2012 at 4:46 PM, David Muir 
>>>> wrote:
>>>> >>
>>>> >>>  On 13/04/12 09:38, Yasuo Ohgaki wrote:
>>>> >>> > Hi,
>>>> >>> >
>>>> >>> > 2012/4/13 Kris Craig :
>>>> >>> >> Per recent discussions, I have drafted an RFC for this.  This
>>>> proposal
>>>> >>> >> offers what I believe to be a more sane and realistic approach to
>>>> >>> >> addressing the question of incorporating a new breed of tag-less
>>>> PHP
>>>> >>> >> scripts.
>>>> >>> >>
>>>> >>> >> https://wiki.php.net/rfc/phpp
>>>> >>> > This may work for LFI issue for new codes.
>>>> >>> > Few questions.
>>>> >>> >
>>>> >>> > CLI may use .phpp as PHP script always. (i.e. execute w/o >>> >>> else)
>>>> >>> > It's like DOS, though.
>>>> >>> >
>>>> >>> > How do you enforce .phpp as script only for Web?
>>>> >>> > Is it a rule for configuration? or .phpp just never supposed to
>>>> locate
>>>> >>> > under docroot?
>>>> >>> > It relates previous question. How about bootstrap script for
>>>> >>> frameworks?
>>>> >>> >
>>>> >>> >> A regular .php script cannot be included from a .phpp script. An
>>>> >>> E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR
>>>> will be
>>>> >>> thrown for require; in both instances, the included file will be
>>>> ignored.
>>>> >>> > Some people may try to make .phpp handled by web.
>>>> >>> > I cannot tell if this setting is going to be popular, but if it
>>>> >>> > does, isn't it the end of embedded PHP?
>>>> >>> > It might be good if PHP is more tolerant for this usage.
>>>> >>> >
>>>> >>> > Regards,
>>>> >>> >
>>>> >>> > --
>>>> >>> > Yasuo Ohgaki
>>>> >>> > yohg...@ohgaki.net
>>>> >>> >
>>>> >>>
>>>> >>>  That's a huge WTF that a templating library can't be written as
>>>> .phpp,
>>>> >>> because it then won't be able to load a template.
>>>> >>>
>>>> >>
>>>> >> That's actually not true.  Please refer to the diagram embedded in
>>>> the
>>>> >> RFC.
>>>> >>
>>>> >> Basically, you can load a template just fine-- you just can't do it
>>>> >> directly from a .phpp file, which you shouldn't be doing, anyway.
>>>>  The
>>>> >> .phpp file is, at least for the most part, intended to be included
>>>> from a
>>>> >> regular .php file, which also would include whatever you're using
>>>> for your
>>>> >> templates.  In other words, they can interact just fine; you just
>>>> can't put
>>>> >> the template upstream from a .phpp file in the include stack-- which,
>>>> >> again, you really shouldn't be doing, anyway, as it's just bad
>>>> architecture.
>>>> >>
>>>> >>
>>>> >>
>>>> >>  How is this bad architecture? Every framework I've seen that has
>>>> some
>>>> >> kind of templating layer that handles the scope 

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Thu, Apr 12, 2012 at 6:35 PM, David Muir  wrote:

>  On 13/04/12 11:03, Kris Craig wrote:
>
>
>
> On Thu, Apr 12, 2012 at 5:46 PM, David Muir  wrote:
>
>>   On 13/04/12 10:04, Kris Craig wrote:
>>
>>
>>
>> On Thu, Apr 12, 2012 at 4:46 PM, David Muir  wrote:
>>
>>>  On 13/04/12 09:38, Yasuo Ohgaki wrote:
>>> > Hi,
>>> >
>>> > 2012/4/13 Kris Craig :
>>> >> Per recent discussions, I have drafted an RFC for this.  This proposal
>>> >> offers what I believe to be a more sane and realistic approach to
>>> >> addressing the question of incorporating a new breed of tag-less PHP
>>> >> scripts.
>>> >>
>>> >> https://wiki.php.net/rfc/phpp
>>> > This may work for LFI issue for new codes.
>>> > Few questions.
>>> >
>>> > CLI may use .phpp as PHP script always. (i.e. execute w/o >> else)
>>> > It's like DOS, though.
>>> >
>>> > How do you enforce .phpp as script only for Web?
>>> > Is it a rule for configuration? or .phpp just never supposed to locate
>>> > under docroot?
>>> > It relates previous question. How about bootstrap script for
>>> frameworks?
>>> >
>>> >> A regular .php script cannot be included from a .phpp script. An
>>> E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
>>> thrown for require; in both instances, the included file will be ignored.
>>> > Some people may try to make .phpp handled by web.
>>> > I cannot tell if this setting is going to be popular, but if it
>>> > does, isn't it the end of embedded PHP?
>>> > It might be good if PHP is more tolerant for this usage.
>>> >
>>> > Regards,
>>> >
>>> > --
>>> > Yasuo Ohgaki
>>> > yohg...@ohgaki.net
>>> >
>>>
>>>  That's a huge WTF that a templating library can't be written as .phpp,
>>> because it then won't be able to load a template.
>>>
>>
>> That's actually not true.  Please refer to the diagram embedded in the
>> RFC.
>>
>> Basically, you can load a template just fine-- you just can't do it
>> directly from a .phpp file, which you shouldn't be doing, anyway.  The
>> .phpp file is, at least for the most part, intended to be included from a
>> regular .php file, which also would include whatever you're using for your
>> templates.  In other words, they can interact just fine; you just can't put
>> the template upstream from a .phpp file in the include stack-- which,
>> again, you really shouldn't be doing, anyway, as it's just bad architecture.
>>
>>
>>
>>  How is this bad architecture? Every framework I've seen that has some
>> kind of templating layer that handles the scope and inclusion of the
>> template, and it happens further down the chain from the controlling code.
>>
>> Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
>> otherwise they wouldn't be able to render the templates.
>>
>> In the case of Zend Framwork, which I'm most familiar with, the
>> application, front controller, dispatcher, and action controllers, and some
>> services would have to remain as .php so that templates could be executed.
>>
>> Oh, and the autoloader can't be .phpp either. But then if it's .php, then
>> the autoloader can't be called from .phpp files to include .php files.
>>
>> Cheers,
>> David
>>
>
> It's been awhile since I've used Smarty, but unless my memory is failing
> me, I'm pretty sure it's not restricted to being several points removed
> upstream as you described.  I'm not familiar with Zend_View or Twig so I
> can't comment on those.
>
> Thing is, there's no reason why you can't hook any framework into this.
> Worst-case scenario, if the library you're hooking into has a rigid
> structure, just write a simple controller class layer to operate on top of
> it, then use that same controller class to interface with the .phpp stack.
> Problem solved.  It's really not as complicated or confusing as you're
> making it out to be.
>
> --Kris
>
>
> Both Smarty and Twig compile your template files down to php templates.
> Zend_View, Aura.View, and Symfony's php view include php files directly
> without a compilation phase.
>
> I don't get how I would write a "simple controller class l

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Thu, Apr 12, 2012 at 6:26 PM, Arvids Godjuks wrote:

> Well, i can say that any template engine that is not a pure php extension
> does template inclusion via an include of a file with html and embedded php
> code. Because to make things fast you have to convert your templates from
> tags and pseudo code to that state and cache the result so not to make
> parsing on every request.
>
> And right now there is a standard for autoloading the libraries and
> frameworks that most big players agreed on, that will make loading of 3rd
> party stuff easy. Untill one converts to pphp and other does not.
> Autoloadijg will just break because of mixed approaches.
>
The autoloading standard is still more or less in its infancy IMHO; the MVC
standard, on the other hand, has been around for awhile and is widely
accepted.  I haven't done any detailed work with the autoloading standard,
but I'll look into it.  I can't imagine though that it would be so
inflexible as to make it completely incompatible with existing MVC
standards.  If that was the case, then I can't imagine ever wanting to use
that, anyway.


> Hm, you wrote that you have configured php only with IIS and Apache (any
> *nix expirience?). Try nginx, see for yourself how different it is.
>
You are aware that Apache runs on both Windows and Linux, right?  It's the
"A" in "LAMP", after all.  ;P


> 13.04.2012 3:05 пользователь "Kris Craig"  написал:
>
> On Thu, Apr 12, 2012 at 5:46 PM, David Muir  wrote:
>>
>> >  On 13/04/12 10:04, Kris Craig wrote:
>> >
>> >
>> >
>> > On Thu, Apr 12, 2012 at 4:46 PM, David Muir 
>> wrote:
>> >
>> >>  On 13/04/12 09:38, Yasuo Ohgaki wrote:
>> >> > Hi,
>> >> >
>> >> > 2012/4/13 Kris Craig :
>> >> >> Per recent discussions, I have drafted an RFC for this.  This
>> proposal
>> >> >> offers what I believe to be a more sane and realistic approach to
>> >> >> addressing the question of incorporating a new breed of tag-less PHP
>> >> >> scripts.
>> >> >>
>> >> >> https://wiki.php.net/rfc/phpp
>> >> > This may work for LFI issue for new codes.
>> >> > Few questions.
>> >> >
>> >> > CLI may use .phpp as PHP script always. (i.e. execute w/o > else)
>> >> > It's like DOS, though.
>> >> >
>> >> > How do you enforce .phpp as script only for Web?
>> >> > Is it a rule for configuration? or .phpp just never supposed to
>> locate
>> >> > under docroot?
>> >> > It relates previous question. How about bootstrap script for
>> frameworks?
>> >> >
>> >> >> A regular .php script cannot be included from a .phpp script. An
>> >> E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
>> >> thrown for require; in both instances, the included file will be
>> ignored.
>> >> > Some people may try to make .phpp handled by web.
>> >> > I cannot tell if this setting is going to be popular, but if it
>> >> > does, isn't it the end of embedded PHP?
>> >> > It might be good if PHP is more tolerant for this usage.
>> >> >
>> >> > Regards,
>> >> >
>> >> > --
>> >> > Yasuo Ohgaki
>> >> > yohg...@ohgaki.net
>> >> >
>> >>
>> >>  That's a huge WTF that a templating library can't be written as .phpp,
>> >> because it then won't be able to load a template.
>> >>
>> >
>> > That's actually not true.  Please refer to the diagram embedded in the
>> RFC.
>> >
>> > Basically, you can load a template just fine-- you just can't do it
>> > directly from a .phpp file, which you shouldn't be doing, anyway.  The
>> > .phpp file is, at least for the most part, intended to be included from
>> a
>> > regular .php file, which also would include whatever you're using for
>> your
>> > templates.  In other words, they can interact just fine; you just can't
>> put
>> > the template upstream from a .phpp file in the include stack-- which,
>> > again, you really shouldn't be doing, anyway, as it's just bad
>> architecture.
>> >
>> >
>> >
>> > How is this bad architecture? Every framework I've seen that has some
>> kind
>> > of templating layer that handles the scope and inc

Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options

[Kris Craig]

On Thu, Apr 12, 2012 at 5:55 PM, Arvids Godjuks wrote:

> I should point out that if you make you mind about a feature - you will
> twist and turn it like hell, but you can't be convinced that it may make
> more damage than good, or is just plain pointless because out there in the
> wild the world actually is wild. And peoe do things differently for a
> reason.
>
> I'm not trying to offend you or shame you, but you just ignore half valid
> arguments. I personaly get a feeling that you don't do PHP development on a
> regular basis, because for me, as a userland php developer, some things you
> write are ridicilous and i would expect them from a beginer, a person
> coming from a different language, but sure not from a serious seasoned PHP
> developer.
>
I think a big part of the problem you're having stems from that mindset.
I've been developing PHP for over 10 years now and it is my primary
language.  I've deployed more PHP applications and environments than I can
count over the years on both Linux and Windows.  I'd say probably 95% of
the coding I do at work is PHP, about 99% of the work I do at home is PHP.

I'm not claiming to be better or worse at PHP than anywayone else (my
resume notwithstanding lol).  The point is, you're assuming that, because
my perspective and my ideas differ from what you believe to be acceptable,
I therefore must be ignorant or otherwise unqualified.  That's a very
dangerous mindset to have in any endeavor and I would strongly encourage
you to do some serious soul-searching on that, because you're only hurting
yourself when you think that way.

As for me ignoring arguments, I think you should go back through some of
these threads.  I've gone to a lot of trouble to respond to individual
points.  I'm sure I've probably missed a couple here and there amidst the
sheer volume, but for the most part I think I've done pretty well.
However, I think you're confusing failure to *hear* an argument with
failure to *agree* with an argument.  If I disprove or even just counter
somebody else's argument, that doesn't mean I'm "ignoring" it.  Quite the
opposite, in fact.  ;P


> This hassle with the php tags, special extensions, optional php.ini
> options will make my life harder. Why? Because two hosters will be able to
> configure their envoirments differently. Who suffers? I suffer the
> conciquences of that by working at 3am saturday morning and probably
> getting into a fight with my wife about that. And getting fired if i refuse
> to fix issues.
>
> I understand the concerns about the LFI or how it is called, but as many
> people mentioned, its how the code is written. And if code is.written badly
> - you can't do anything about it on the language level without restricting
> writing the code in the first place.
>
You seem to be grouping me in with some other people, because a lot of what
you just describe hasn't been proposed or even supported by me.  For
example, you stated that, "as many people have mentioned," LFI security
comes down to how the code is written.  Yeah, I know, because I'm one of
those people who stated that.  Right here.  On Internals.  I took a little
bit of heat for it, too.  I believe I summed-up the principle as, "A
programming language can only be as smart as the person using it."

That said, you'll notice that I didn't lodge any personal attacks at the
person who suggested it.  But I was nonetheless assertive and forceful in
my arguments against it.  That's where the difference lies.  You can reduce
somebody else's argument to a pile of dust without ever having to even hint
at a personal attack; I do it all the time lol.


> Those people that went for th include modification with the second
> optional param are on the right track - you give the people the ability and
> they will use it (i will).
>
> If someone could take all the energy wasted here and put to work on
> drasticly improving PDO - that would be a real benifit to every one. Cause
> right now pdo just sucks, a lot.
> 13.04.2012 2:07 пользователь "Kris Craig"  написал:
>
>
>>
>> On Thu, Apr 12, 2012 at 5:02 PM, Arvids Godjuks > > wrote:
>>
>>> You all know where the short_tags, register_globals, magic_quotes and
>>> other
>>> stuff like that took the language and the problems it made.
>>> Doesn`t history teach us a lesson? I see that it did not for some active
>>> members of this list.
>>> Many are still cleaning up the mess of thouse optional php.ini
>>> directives,
>>> Ibhad to clean up myself one project, took me 2 months to properly fix it
>>> and make to run on PHP 5, anyway we ended up rewriting the whole thing
>>&g

Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options

[Kris Craig]

On Thu, Apr 12, 2012 at 6:04 PM, Arvids Godjuks wrote:

> I will not write something like that any more, but you should understand
> that Criss is writing to the list tons of e-mails and his attitude to other
> people ideas and arguments is getting on people nerves. Remember thecphrase
> from the Mythbusters "I reject your reality and substitute my own!". It
> feels just that way with Criss.
>

It's "Kris," btw.  ;P

Everyone is entitled to their opinions, including me.  I do convey my
points with confidence and conviction, and I understand that can be
intimidating for some.  But the fact that I'm very sure of myself, perhaps
excessively so at times, does not justify resorting to personal attacks.
Just match my assertiveness with assertiveness of your own; aggression is
not necessary.  I always won all the debates in school and that can
definitely be frustrating when you're on the other end of that.  But again,
try not to take it so personally.  If everyone puts forth the best logic
and avoids the temptation to get emotional, the debate will inevitably lead
to increased clarity on all sides of an issue that would otherwise not have
been possible.  That's why it's important that you try to let go of your
resentment and follow the cool, even, unending center line of logic.  If
you can master that, these discussions will be far less frustrating for
you.  =)


>
> I'm sorry if I crossed any lines, I made my case. I would like to believe
> that my arguments about the topic are valid and would be taken into
> account.
>

Your arguments are no less valid than mine or anyone else's.  We're just
asking that you tone down the personal attacks.



> 13.04.2012 2:53 пользователь "Stas Malyshev" 
> написал:
>
> > Hi!
> >
> > > Common sence is allien to some people on this list or what?
> >
> > While I think you make a good point, I also think we could do without
> > personal (or multi-personal) attacks. It is fine to discuss and
> > criticize ideas, but let's avoid attacks on personal level and
> > disparaging personal qualities of people. Intelligent people can have
> > different points of view and disagree completely on some subjects. Even
> > if you think somebody's idea is very bad, please let's say "I think your
> > idea is bad", not "You are a crazy moron".
> > --
> > Stanislav Malyshev, Software Architect
> > SugarCRM: http://www.sugarcrm.com/
> > (408)454-6900 ext. 227
> >
>

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Thu, Apr 12, 2012 at 6:03 PM, Yasuo Ohgaki  wrote:

> Hi,
>
> If we aren't going to consider saving current code risk, then
> we could use both new include and file name convention.
>
> Introduce application/x-httpd-php-script, then we could
>
> AddHandler php5-script .php
> AddType text/html .php
> AddType application/x-httpd-php-source .phps
> AddType application/x-httpd-php-script   .ph // .phpp .phpc .phpscript
> whatever extension here
>

Yeah that's more or less what I had in mind, actually.  There'd be work
involved, no question, but there's no reason why it shouldn't be doable.


>
> We may need ENV vars for other SAPIs.
>

I'm only familiar with installing PHP on Apache and IIS, so I honestly have
no idea how it would work with other webservers.  I'd wager that it's
possible enough, but as for the "how," I'll have to defer to those who have
experience working with said webserver(s).


>
> script/script_once for PHP only script includes.
>

Would the new "script" keyword behave like include or require?  I'm very
wary of the idea of having a special include to treat .php files the same
as .phpp files, simply because it would seem to add a lot of complexity and
potential for confusion, but I won't necessarily rule it out altogether,
either.  Right now I'm just working on reassuring those who are afraid this
will cause every single framework on the internet to spontaneously combust
lol.


>
> How about this?
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Thu, Apr 12, 2012 at 5:46 PM, David Muir  wrote:

>  On 13/04/12 10:04, Kris Craig wrote:
>
>
>
> On Thu, Apr 12, 2012 at 4:46 PM, David Muir  wrote:
>
>>  On 13/04/12 09:38, Yasuo Ohgaki wrote:
>> > Hi,
>> >
>> > 2012/4/13 Kris Craig :
>> >> Per recent discussions, I have drafted an RFC for this.  This proposal
>> >> offers what I believe to be a more sane and realistic approach to
>> >> addressing the question of incorporating a new breed of tag-less PHP
>> >> scripts.
>> >>
>> >> https://wiki.php.net/rfc/phpp
>> > This may work for LFI issue for new codes.
>> > Few questions.
>> >
>> > CLI may use .phpp as PHP script always. (i.e. execute w/o > > It's like DOS, though.
>> >
>> > How do you enforce .phpp as script only for Web?
>> > Is it a rule for configuration? or .phpp just never supposed to locate
>> > under docroot?
>> > It relates previous question. How about bootstrap script for frameworks?
>> >
>> >> A regular .php script cannot be included from a .phpp script. An
>> E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
>> thrown for require; in both instances, the included file will be ignored.
>> > Some people may try to make .phpp handled by web.
>> > I cannot tell if this setting is going to be popular, but if it
>> > does, isn't it the end of embedded PHP?
>> > It might be good if PHP is more tolerant for this usage.
>> >
>> > Regards,
>> >
>> > --
>> > Yasuo Ohgaki
>> > yohg...@ohgaki.net
>> >
>>
>>  That's a huge WTF that a templating library can't be written as .phpp,
>> because it then won't be able to load a template.
>>
>
> That's actually not true.  Please refer to the diagram embedded in the RFC.
>
> Basically, you can load a template just fine-- you just can't do it
> directly from a .phpp file, which you shouldn't be doing, anyway.  The
> .phpp file is, at least for the most part, intended to be included from a
> regular .php file, which also would include whatever you're using for your
> templates.  In other words, they can interact just fine; you just can't put
> the template upstream from a .phpp file in the include stack-- which,
> again, you really shouldn't be doing, anyway, as it's just bad architecture.
>
>
>
> How is this bad architecture? Every framework I've seen that has some kind
> of templating layer that handles the scope and inclusion of the template,
> and it happens further down the chain from the controlling code.
>
> Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
> otherwise they wouldn't be able to render the templates.
>
> In the case of Zend Framwork, which I'm most familiar with, the
> application, front controller, dispatcher, and action controllers, and some
> services would have to remain as .php so that templates could be executed.
>
> Oh, and the autoloader can't be .phpp either. But then if it's .php, then
> the autoloader can't be called from .phpp files to include .php files.
>
> Cheers,
> David
>

It's been awhile since I've used Smarty, but unless my memory is failing
me, I'm pretty sure it's not restricted to being several points removed
upstream as you described.  I'm not familiar with Zend_View or Twig so I
can't comment on those.

Thing is, there's no reason why you can't hook any framework into this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on top of
it, then use that same controller class to interface with the .phpp stack.
Problem solved.  It's really not as complicated or confusing as you're
making it out to be.

--Kris

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Thu, Apr 12, 2012 at 5:26 PM, Arvids Godjuks wrote:

> Well, I just don't know how i can appeal to common sence to some people on
> the list anymore. First the type hinting threads, now this.
>

With all due respect, Arvids, get over it.  People are going to propose
ideas you don't like.  I'm going to propose ideas you don't like.  You can
either handle it like a mature adult or you can alienate the very people
you're trying to persuade.  I've seen a disturbing pattern of hostile
behavior bordering on abusiveness from you on a number of threads and I
would ask you to take a deep breath and tone it down.  If you don't think
you can post a response without engaging in personal attacks and hyperbole,
walk away and come back to it later when you've had a chance to get the
initial emotion out of your system.  Spraying the list with insults
whenever someone disagrees with you is not an acceptable way of working
with others IMHO.  So please try to work on that.


> The world does not work only on one web server and there are different
> type ls of them out there. I for once use nginx and i configure how to run
> scripts by locations, not by file types. I just pass the params to fastcgi
> server thet runs a php binary. And it does not.care about the extension. I
> can use any extension.l for my code. Yes, i use .php, others use. phtml or
> other variants. Extensions are just a convension, nothing more. You can
> give a file any or none extension at all and it will not change a thing.Ok,
> in windows you will not be able to open the file in a program by double
> click, but through the open dialog in the app - be my guest. To PHP,
> fastcgi and the web server it does not matter. It just matters to people so
> they can distingush between a php file, js file and a css file.
>
I'd prefer to avoid getting into a heated argument over something that
amounts to little more than semantics.  Yes, file extensions are a
convention by their very nature.  And yes, there would need to be some
changes in order to add support for a second parsing type.  But you'll
notice that's why I listed the target PHP version as 6.0.  A major release
such as that is where one would expect these sorts of fundamental
improvements to be made, plus it gives us a long time to sort out the
technical details since 6.0 won't be coming for at least another few years.

--Kris

13.04.2012 2:01 пользователь "Kris Craig"  написал:
>
>
>>
>> On Thu, Apr 12, 2012 at 4:44 PM, Arvids Godjuks > > wrote:
>>
>>> So ok, i write my code in files without extension, what happens?
>>>
>>> As it was said before, interpreter will not distinguish by the file
>>> extension, ever. It is os dependant and so on.
>>>
>>> Why are you poluting the mailing list with things that are clearly said
>>> will never happen?
>>>
>> You might want to consider using less inflammatory, disrespectful
>> language if you want people to respond favorably to your questions.  I.e.
>> accusing someone of "poluting [sic] the mailing list" because they posted
>> an idea you don't like is neither constructive nor necessary.
>>
>> That being said, the .php file extension is not, as far as I know,
>> determined by the operating system.  It's determined by the webserver
>> configuration.  So if you have two different extensions, each with a
>> separate SAPI handler to differentiate between them, there's no reason why
>> this wouldn't work just fine.  After all, the internet didn't explode when
>> we dropped the .php3 extension.  ;P
>>
>>

Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options

[Kris Craig]

On Thu, Apr 12, 2012 at 5:02 PM, Arvids Godjuks wrote:

> You all know where the short_tags, register_globals, magic_quotes and other
> stuff like that took the language and the problems it made.
> Doesn`t history teach us a lesson? I see that it did not for some active
> members of this list.
> Many are still cleaning up the mess of thouse optional php.ini directives,
> Ibhad to clean up myself one project, took me 2 months to properly fix it
> and make to run on PHP 5, anyway we ended up rewriting the whole thing from
> scratch, a year of day to day work.
> Now i write my stuff E_ALL, including strict stuff and I know for a fact
> that there is no php.ini switch that could screw up my applications on
> different hosting platforms (yes, some minor things can happen in specific
> situations, but any properly configured PHP 5.3/5.4 will run smooth). And
> now you purpose to add a switch that in one line can disable the
> application for good (and get it's sources spit out all over the place).
> And even if i write it in the right way - i have to convert every damn
> external library. Ok, i upload it to the host and guess what - it spews the
> code out because it is configured for the 
> It will never get adopted, too many legacy stuff, to many external tools.
> And php native templates? I dont neet any twig, smarty or any other stuff.
> And guess what - most template engines cache compiled templates, and they
> are - ta-daa - PHP EMBEDDED IN HTML CODE!
>
> Common sence is allien to some people on this list or what?
>

As is civility and basic mutual respect, it would seem.

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Thu, Apr 12, 2012 at 4:46 PM, David Muir  wrote:

> On 13/04/12 09:38, Yasuo Ohgaki wrote:
> > Hi,
> >
> > 2012/4/13 Kris Craig :
> >> Per recent discussions, I have drafted an RFC for this.  This proposal
> >> offers what I believe to be a more sane and realistic approach to
> >> addressing the question of incorporating a new breed of tag-less PHP
> >> scripts.
> >>
> >> https://wiki.php.net/rfc/phpp
> > This may work for LFI issue for new codes.
> > Few questions.
> >
> > CLI may use .phpp as PHP script always. (i.e. execute w/o  > It's like DOS, though.
> >
> > How do you enforce .phpp as script only for Web?
> > Is it a rule for configuration? or .phpp just never supposed to locate
> > under docroot?
> > It relates previous question. How about bootstrap script for frameworks?
> >
> >> A regular .php script cannot be included from a .phpp script. An
> E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
> thrown for require; in both instances, the included file will be ignored.
> > Some people may try to make .phpp handled by web.
> > I cannot tell if this setting is going to be popular, but if it
> > does, isn't it the end of embedded PHP?
> > It might be good if PHP is more tolerant for this usage.
> >
> > Regards,
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
> >
>
> That's a huge WTF that a templating library can't be written as .phpp,
> because it then won't be able to load a template.
>

That's actually not true.  Please refer to the diagram embedded in the RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway.  The
.phpp file is, at least for the most part, intended to be included from a
regular .php file, which also would include whatever you're using for your
templates.  In other words, they can interact just fine; you just can't put
the template upstream from a .phpp file in the include stack-- which,
again, you really shouldn't be doing, anyway, as it's just bad architecture.


>
> David
>

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Thu, Apr 12, 2012 at 4:44 PM, Arvids Godjuks wrote:

> So ok, i write my code in files without extension, what happens?
>
> As it was said before, interpreter will not distinguish by the file
> extension, ever. It is os dependant and so on.
>
> Why are you poluting the mailing list with things that are clearly said
> will never happen?
>
You might want to consider using less inflammatory, disrespectful language
if you want people to respond favorably to your questions.  I.e. accusing
someone of "poluting [sic] the mailing list" because they posted an idea
you don't like is neither constructive nor necessary.

That being said, the .php file extension is not, as far as I know,
determined by the operating system.  It's determined by the webserver
configuration.  So if you have two different extensions, each with a
separate SAPI handler to differentiate between them, there's no reason why
this wouldn't work just fine.  After all, the internet didn't explode when
we dropped the .php3 extension.  ;P

Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

On Thu, Apr 12, 2012 at 4:38 PM, Yasuo Ohgaki  wrote:

> Hi,
>
> 2012/4/13 Kris Craig :
> > Per recent discussions, I have drafted an RFC for this.  This proposal
> > offers what I believe to be a more sane and realistic approach to
> > addressing the question of incorporating a new breed of tag-less PHP
> > scripts.
> >
> > https://wiki.php.net/rfc/phpp
>
> This may work for LFI issue for new codes.
> Few questions.
>
> CLI may use .phpp as PHP script always. (i.e. execute w/o  It's like DOS, though.
>
> How do you enforce .phpp as script only for Web?
> Is it a rule for configuration? or .phpp just never supposed to locate
> under docroot?
> It relates previous question. How about bootstrap script for frameworks?
>

I'm not sure what the best SAPI configuration would be, but if I had to
throw out an educated guess, I'd say the .phpp extension would just go
through a separate handler.  All the code in the file would then be parsed
as PHP, with the added error conditions as described in the RFC.  So I
don't anticipate there being any problems once the webserver has been
configured to recognize the new file extension.  The files can be included
or accessed directly via HTTP (though in most cases I wouldn't recommend
that from an architectural standpoint, AJAX notwithstanding of course).


>
> > A regular .php script cannot be included from a .phpp script. An
> E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
> thrown for require; in both instances, the included file will be ignored.
>
> Some people may try to make .phpp handled by web.
>

Though not necessarily required, my thinking is that that should be ok, so
long as the webserver is configured to know what to do with it of course.
It's conceivable that certain AJAX calls might want to take advantage of
pure scripts, for example.


> I cannot tell if this setting is going to be popular, but if it
> does, isn't it the end of embedded PHP?
>

I see no reason why it should be.  Embedded PHP will still be there exactly
as it is now; the .php file extension will not be changed by this RFC
whatsoever.  As far as whether people will continue using embedded PHP, I
have no idea and I'm guessing there'd probably strong opinions on both
sides of that.  This RFC doesn't attempt to address that question, though.
The future of embedded PHP is a separate topic entirely.  But my gut
feeling is, so long as there are developers who continue to want it, it'll
still be there for them.

It might be good if PHP is more tolerant for this usage.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

[PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

[Kris Craig]

Per recent discussions, I have drafted an RFC for this.  This proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

https://wiki.php.net/rfc/phpp

--Kris

Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options

[Kris Craig]

On Wed, Apr 11, 2012 at 1:48 PM, Yasuo Ohgaki  wrote:

> Hi,
>
> 2012/4/12 Chris Stockton :
> > Hello,
> >
> > On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig 
> wrote:
> >> I can't help but question whether we should even be worrying about
> LFI/RFI
> >> to begin with.  Personally, I would *never* check-off on code that in
> any
> >> way used $_GET or $_POST directly in an include/require statement!  It's
> >> just plain lazy.  There's just no excuse for doing that.  Use some sort
> of
> >> dispatch or translation table.  Sure, it might seem less "magical," but
> >> it'll also protect you from some asshole hitting you with something
> like,
> >> "?file=http://hacksite.com/injectedcode.php?";.  The individual code
> >> developer has to take *some* responsibility for their code.  If this is
> >> such a problem, I would think the solution would be to update our docs
> to
> >> better warn people about this type of attack and educate them on how
> not to
> >> write code that's vulnerable to it.
> >>
> >> We can make the language secure; but, in the end, a language is only as
> >> smart as the person using it.
> >>
> >
> >
> > I really have a hard time understanding how this is even being
> > discussed, there is no real problem here. Making sure user input is
> > validated is a core concept of application development. How on earth
> > can you say "if you don't validate the users input, it's a security
> > problem, so php must fix it", it's the most ridiculousness argument I
> > have read on here in ages.
>
> It is the same as saying that canary protection for stack smashing
> or ASLR is useless if programmer write correct code.
>
> Don't you appreciate that compilers/OSes have additional mitigation
> factor, do you? Or would you like to disable all of these mitigation
> features from your compilers/OSes? I guess not.
>
> C language is prone to be weak for buffer overflows, hence it is
> weak to code execution and/or massive information disclosure.
> (Like private key disclosure demonstrated by MoPB)
>
> Embedded language is prone to be weak for LFI. It also leads
> to code execution and/or massive information disclosure.
>
> These weaknesses are the nature of how languages are made.
> PHP is pure embedded language and there are people trying to
> change it. If we are going to change that, it is reasonable to
> change PHP so that LFI weakness will be closed.
>
> Not closing LFI issue is sound like "We have created Java language
> which is free from memory management, but stack smashing and
> various overflow issues still remains."
>
> >
> > _IF_ you absolutely must accept arbitrary user urls from users, which
> > we all have to do at some point, you use socket functions, file
> > functions, HTTP extension, whatever you want. If you are using INCLUDE
> > you are using the WRONG TOOL. You are WRONG.
>
> Decent programmers knew the most important mitigation factor
> is input control. It is top listed as monster mitigation in SANS CWE
> TOP 25 also. I guess nobody would argue that here.
>
> >
> > _IF_ you are needing to display downloaded user data onto a page, a
> > image for example, you need to use file functions, fpassthru,
> > something of the source. If you are using INCLUDE to do this, you are
> > using the WRONG TOOL. You are WRONG.
> >
> > _IF_ you for some reason must accept LOCAL PATHS from a user, and you
> > do not want to pass that input through a validation layer, you are
> > WRONG.
> >
> > It boils down to you either use the right tools and the right
> > validation methods or I promise this is only one of unlimited possible
> > security concerns Yasuo.
>
> We are discussing PHP being stronger against LFI, if we
> are going to adopt non-ebmed mode for PHP.
>
> PHP  is good language for novice. Do we want them to learn
> details of LFI which is described in my RFC? How dangerous it is,
> how it could be exploited, etc. I believe it's just not worth it if we
> made PHP could work in non-embedded mode.
>
> By the way, how many people knew all the exploitation methods that
> I've written in the RFC? It's a real risk, but I guess many of us
> don't even think about or care. How we could expect novice or
> even average PHP programmer care about these risks?
>
> It's better that close window as much as possible where it is
> applicable.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

But you're bas

Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening

[Kris Craig]

On Wed, Apr 11, 2012 at 5:07 AM, Tom Boutell  wrote:

> I had no goal of making sure code "remains pure" in this rfc, only the
> goal of being allowed to write pure code (no opening  establishing a way to encourage pure code in the scope of individual class
> files (disallowing ?> in individual pure mode files). I think an easy,
> obvious bc mechanism is essential, making it harder to use legacy code is
> not something people would vote for, and more pure code is better than no
> pure code. You feel differently. I'm not sure our positions can be
> reconciled. Perhaps this point will just have to be settled when the rfc is
> voted on.
>

Indeed.  Looks like I'll just have to draft an RFC of my own then.  So now
that will make 3 competing RFCs on this subject  *grumble*


>
> Sent from my iPhone
>
> On Apr 11, 2012, at 1:16 AM, Kris Craig  wrote:
>
> >
> >
> > On Tue, Apr 10, 2012 at 8:35 PM, Tom Boutell  wrote:
> > On Tue, Apr 10, 2012 at 10:10 PM, Kris Craig 
> wrote:
> > > This shouldn't be used to load libraries that dump raw HTML output!
>  That
> > > literally defeats the entire purpose.  You're also assuming that all
> PHP
> > > developers do 100% of their coding through pre-existing frameworks.
> >
> > Consider a .phpp file that includes a .php template file when it sees
> > fit, in a render() method. How is this different from an echo()
> > statement? It's not. It's just a convenient form in some situations.
> > By punting these out to .php files we achieve better separation of
> > concerns while still respecting PHP's history as a template language
> > (and possible future if it improves in that area, which it may).
> >
> > Again, this can easily be made to work using a simple MVC architecture.
>  I.e. the "view" layer calls controller::render(), which then includes
> model.phpp and funnels the call to model::render().  Again, this is just
> basic segregation of model (i.e. "pure") code from view (i.e. template)
> code.  This is already widely considered best practices, so having this
> conform to that is not a bad thing.  On the other hand, your approach makes
> it impossible to determine absolutely that the model code will remain pure,
> thus rendering this whole RFC completely and utterly useless IMHO.
> >
> >
> > All I want is to stop typing  > screwups above  > interoperable and which people might be able to vote for if they have
> > a nontrivial amount of legacy code in their life, like everybody I
> > work with (:
> >
> > I know.  But unfortunately, for reasons already discussed ad nauseum,
> the only way to truly accomplish that without weighing other factors would
> be to massively break all PHP scripts that currently exist.  You may want
> to just have a simple removal of  should probably adjust your expectations accordingly.
> >
> >
> > As many have pointed out, plain php template files work for some
> > projects. A viable RFC that people might actually vote for should
> > respect that. It neither picks my pocket nor breaks my leg if someone
> > wants to include .php template files from a .phpp file. I don't have
> > to do it.
> >
> > Again, if you're concerned about that, then you have no business
> including them within a .phpp file to begin with.  It's basically like
> turning on the shower but then covering the nozzle with a stopper so that
> no water will come out, allowing you to "take a shower" while still
> remaining dirty.  If you want to stay covered in dirt, then don't take a
> shower!  If you do take a shower, then you have no business doing so if
> your goal isn't to get clean.  That would just make no sense.
> >
> >
> > When you consider that I would be completely unable to use an existing
> > .php library of nontrival code like Amazon's S3 SDK under your
> > proposal without a convoluted workaround it is pretty much a certainty
> > that I would have to vote no if the RFC read that way.
> >
> > That's a logical fallacy because it's based on a faulty premise.  I.e.
> "I would be completely unable to use  without a convoluted
> workaround"
> >
> > That statement is inaccurate because there is no "workaround,"
> convoluted or otherwise.  It's just standard MVC architecture, which is
> neither convoluted nor uncommon.  If somebody wanted to be able to write a
> script containing class instantiation but keep the code 100% procedural,
> most people would tell that person to rethink that idea.  He could say that
> having to define a class i

Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options

[Kris Craig]

On Wed, Apr 11, 2012 at 10:38 AM, John Crenshaw wrote:

> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> > I guess he is saying that it prevents:
> >
> >Random bytes
> >
> >More random bytes
> >
> > Where random bytes might be an image file so finfo_file() might identify
> it as a valid image
>
> Right, but anyone can trivially construct a fully valid bitmap with a
> starting byte sequence of `42 4D 3B 2F 2A`, which resolves to `BM;/*`. PHP
> will decide that BM meant 'BM', effectively skipping it, then the open
> comment will slide the PHP interpreter past any remaining header stuff. You
> can close the comment and place the actual code payload anywhere in the
> image data. The early bytes in other image formats are similarly
> exploitable. As far as I can tell there is really no security win here.
>
> > 4. Only protecting against mid-script injections and not top-of-script
> injections is a somewhat subtle concept when the real problem is the
> vulnerable include $_GET['filename'] hole. If this really is a prevalent
> problem, maybe instead of trying to mitigate the symptoms, why don't we try
> to attack the actual cause of the problem. I would love to hear some ideas
> along those lines that don't fundamentally change the nature of PHP for
> somewhat cloudy benefits.
> >
> > -Rasmus
>
> It's disturbingly common. Probably 90% of the automated attacks I see in
> the 404 error logs are trying to exploit various inclusion vulnerabilities.
>
> One idea that comes to mind immediately is the old taint RFC:
> https://wiki.php.net/rfc/taint. This doesn't actually prevent LFI, but it
> (optionally) warns the developer that they did something very bad,
> regardless of whether it actually caused a problem with the specific input
> data. I'd really love to see that one finalized and implemented.
>
> Another wild alternative could be to have a non-trivial string format
> internally, where PHP strings are actually a set of distinct blocks which
> each contain encoding information. This would make it possible to
> concatenate strings just as always, but since the attributes of each block
> are known the entire string contents could be manipulated to an arbitrary
> final encoding, (or rejected as impossible to safely convert) when the
> string is actually used. In the include case this isn't really very
> different from taint, because safe conversion is impossible, but for things
> like XSS and SQL injection it could actually *fix* the otherwise vulnerable
> code. A simplified example of how this might work:
>
> http://example.com?name=%3Cscript%3Exss()%3B%3C%2Fscript%3E
>
> // $_GET['name'] === [text&user&utf8('xss();')];
> $name = $_GET['name'];
>
> $welcome = html("Welcome $name!"); // $welcome === [html('Welcome
> '), text&user&utf8('xss();'), html('!')];
>
> echo $_GET['name']; // assuming the current output format is text/html,
> the output will be "Welcome  !"
>
> Obviously this second idea is probably a prohibitively large change, there
> is some BC break (especially where an input was known to be HTML but
> secured via something like HTMLPurifier), and there are huge open questions
> (like how to handle string comparison). Still, I think it is interesting
> because it actually divines the real meaning. The intent of the above code
> is obvious to a developer, and something like this could bring that
> understanding to the final result. This specific concept has issues, but
> maybe it gives someone else a more practical idea.
>
> John Crenshaw
> Priacta, Inc.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I can't help but question whether we should even be worrying about LFI/RFI
to begin with.  Personally, I would *never* check-off on code that in any
way used $_GET or $_POST directly in an include/require statement!  It's
just plain lazy.  There's just no excuse for doing that.  Use some sort of
dispatch or translation table.  Sure, it might seem less "magical," but
it'll also protect you from some asshole hitting you with something like,
"?file=http://hacksite.com/injectedcode.php?";.  The individual code
developer has to take *some* responsibility for their code.  If this is
such a problem, I would think the solution would be to update our docs to
better warn people about this type of attack and educate them on how not to
write code that's vulnerable to it.

We can make the language secure; but, in the end, a language is only as
smart as the person using it.

--Kris

Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options

[Kris Craig]

On Wed, Apr 11, 2012 at 8:45 AM, Rasmus Lerdorf  wrote:

> On 04/11/2012 08:12 AM, Luke Scott wrote:
> > Tom has a "similar" RFC that has two modes:
> >
> > - Template mode - how it is now
> > - Code (or pure code) mode -  > optional. ?> is disallowed.
> >
> > Tom's RFC calls for template mode to remain the default, but allow you
> > to add a flag to require/include to interpret the script in "pure
> > mode". Allowing an optional starting  > backwards compatibility with most classes.
>
> And my objection to that is similar. An optional templating mode is the
> same as optional short_tags. it discourages template mode the same way
> short_tags are discouraged. For short_tags that discouragement makes
> sense. For templating it doesn't.
>

I have some objections to that RFC as well, but one question that comes to
my mind is, does allowing a "pure code" PHP mode really *discourage* use of
templating mode; and, if so, how?  From an MVC architectural standpoint, I
can actually see some benefit in having a type of code-only PHP file,
though Tom's current RFC negates that by allowing HTML bits to be included
upstream so I'll probably be voting it down anyway.  But conceptually, at
least, I think the idea has some merit IMHO.

--Kris


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

Re: [PHP-DEV] release process with git

[Kris Craig]

Pierre,

On Tue, Apr 10, 2012 at 10:42 PM, Pierre Joye  wrote:

> Kris,
>
> On Wed, Apr 11, 2012 at 1:13 AM, Kris Craig  wrote:
>
> > Given the number of RCs we've seen in the past, I remain skeptical that
> > your approach will prove sustainable.  But I'd say let's just try it and
> > see how it goes.
>
> Saying that is totally ignoring the main point in the new way: Very
> limited amount of changes allowed after the 1st RCs, or between two
> releases.
>
> The insane amount of changes is what made impossible to release
> quickly in the past, like in 5.3 now.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>

True true.  But old patterns have a funny way of reasserting themselves.  I
hope you and Stas are right; but, as they say, I'll believe it when I see
it.  ;)

--Kris

Re: [PHP-DEV] Allow non-variable arguments to empty()

[Kris Craig]

On Tue, Apr 10, 2012 at 10:31 PM, Pierre Joye  wrote:

> hi Kris,
>
> On Wed, Apr 11, 2012 at 7:26 AM, Kris Craig  wrote:
>
> > I must've missed that part.  Who was it that said this would be a
> separate
> > forked project?  If so, then yeah obviously it's not up to us one way or
> > another.  And if he's just committing changes locally and/or pushing to
> an
> > unmerged branch, then there's no harm because it's not actually touching
> > the trunk.  What I'm saying is that, before such changes are merged into
> > the actual PHP 5.4 branch, the idea needs to be voted on through the RFC
> > process.
>
> All that was asked here is to provide a pull request and a RFC so we
> can evaluate this change. Nobody ever mentioned that this change will
> be merged into any of our stable branches. Everything's fine and is
> done as it should be.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>

Alrighty.  So long as we're not merging any new features or behavioral
changes into the stable branches without an RFC, I'm happy.  =)

--Kris

Re: [PHP-DEV] Allow non-variable arguments to empty()

[Kris Craig]

On Tue, Apr 10, 2012 at 10:12 PM, Stas Malyshev wrote:

> Hi!
>
> > Well, technically it's discussion /and/ vote.  I know we've been wanting
> > to get out of the habit of "push first, ask later," which is precisely
> > what RFC helps us avoid.  Personally, I think any commits for a
>
> Nobody's pushing anything. We're talking about implementing it in a
> fork, it's completely different thing.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

I must've missed that part.  Who was it that said this would be a separate
forked project?  If so, then yeah obviously it's not up to us one way or
another.  And if he's just committing changes locally and/or pushing to an
unmerged branch, then there's no harm because it's not actually touching
the trunk.  What I'm saying is that, before such changes are merged into
the actual PHP 5.4 branch, the idea needs to be voted on through the RFC
process.

Besides, it's a better idea to wait anyway because the simple act of
drafting the RFC helps the author to clarify exactly what s/he wants to do
before jumping into the code.  Furthermore, subsequent input from users may
change the direction, forcing the author to rewrite code, which wastes
time.  And if the proposal is rejected, that person would've written all
that code for nothing.

So either way you look at it, it seems to me at least that drafting the RFC
is the logical first step.

--Kris

Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening

[Kris Craig]

On Tue, Apr 10, 2012 at 8:35 PM, Tom Boutell  wrote:

> On Tue, Apr 10, 2012 at 10:10 PM, Kris Craig  wrote:
> > This shouldn't be used to load libraries that dump raw HTML output!  That
> > literally defeats the entire purpose.  You're also assuming that all PHP
> > developers do 100% of their coding through pre-existing frameworks.
>
> Consider a .phpp file that includes a .php template file when it sees
> fit, in a render() method. How is this different from an echo()
> statement? It's not. It's just a convenient form in some situations.
> By punting these out to .php files we achieve better separation of
> concerns while still respecting PHP's history as a template language
> (and possible future if it improves in that area, which it may).
>

Again, this can easily be made to work using a simple MVC architecture.
 I.e. the "view" layer calls controller::render(), which then includes
model.phpp and funnels the call to model::render().  Again, this is just
basic segregation of model (i.e. "pure") code from view (i.e. template)
code.  This is already widely considered best practices, so having this
conform to that is not a bad thing.  On the other hand, your approach makes
it impossible to determine absolutely that the model code will remain pure,
thus rendering this whole RFC completely and utterly useless IMHO.


> All I want is to stop typing  screwups above  interoperable and which people might be able to vote for if they have
> a nontrivial amount of legacy code in their life, like everybody I
> work with (:
>

I know.  But unfortunately, for reasons already discussed ad nauseum, the
only way to truly accomplish that without weighing other factors would be
to massively break all PHP scripts that currently exist.  You may want to
just have a simple removal of 
> As many have pointed out, plain php template files work for some
> projects. A viable RFC that people might actually vote for should
> respect that. It neither picks my pocket nor breaks my leg if someone
> wants to include .php template files from a .phpp file. I don't have
> to do it.
>

Again, if you're concerned about that, then you have no business including
them within a .phpp file to begin with.  It's basically like turning on the
shower but then covering the nozzle with a stopper so that no water will
come out, allowing you to "take a shower" while still remaining dirty.  If
you want to stay covered in dirt, then don't take a shower!  If you do take
a shower, then you have no business doing so if your goal isn't to get
clean.  That would just make no sense.


> When you consider that I would be completely unable to use an existing
> .php library of nontrival code like Amazon's S3 SDK under your
> proposal without a convoluted workaround it is pretty much a certainty
> that I would have to vote no if the RFC read that way.
>

That's a logical fallacy because it's based on a faulty premise.  I.e.
"I would be completely unable to use  without a convoluted
workaround"

That statement is inaccurate because there is no "workaround," convoluted
or otherwise.  It's just standard MVC architecture, which is neither
convoluted nor uncommon.  If somebody wanted to be able to write a script
containing class instantiation but keep the code 100% procedural, most
people would tell that person to rethink that idea.  He could say that
having to define a class is a "convoluted workaround," but it's not.

Instead of having your .phpp script call a script containing HTML, and thus
essentially having your .phpp file contain HTML and thus be no different on
a practical level than a regular .php file, just have a regular .php script
that calls both the .phpp file and the .php library.  That's not
complicated.  In fact, it's insultingly simple.  If you want it to be pure
PHP, then it needs to be pure PHP throughout its stack (i.e. includes).
 Either way, it needs to be consistent.  Your approach would add far too
much complexity/confusion without any practical gain, whatsoever (aside
from not having to type that 5-character 
> > (Main Script)
> >  |
> >  |
> >  [Included .php/HTML Script]
> >  |   |
> >  |   |
> > {Included .phpp Script}  [Included .php/HTML Script from
> > Framework/Library]
>
> This is convoluted and forces me to write a .php frontend. Surely that
> is not your goal.
>

I think the problem is you're trying to have it both ways.  No, you are not
forced to write a .php frontend.  You can send whatever HTML/template
output you need through echo/print/etc, without ever having to use the ?>
tag.

Furthermore, if 

Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening

[Kris Craig]

On Tue, Apr 10, 2012 at 6:50 PM, Tom Boutell  wrote:

> On Tue, Apr 10, 2012 at 7:59 PM, Kris Craig  wrote:
> > Tom,
> >
> > Much better, though I'm still very troubled by allowing non-pure PHP
> code to
> > be mixed-in with pure PHP (by means of includes).  The problem I have
> with
> > this, as a developer, is that this means I can't really trust that what I
> > will get from a "pure PHP" script will actually be pure PHP, because
> > non-pure scripts lower in the stack might mix-in HTML code that would
> then
> > get passed up through the stack.  These really shouldn't be mixed
> anyway, so
> > I'm just not seeing any value in not keeping this separation consistent.
>
> The approach you suggest would make it impossible to load an existing
> library of perfectly good classes from a newer framework. I don't know
> anyone who would be able to get work done under those circumstances (:
> It would lead to almost no adoption of the new feature.
>

This *shouldn't* be used to load libraries that dump raw HTML output!  That
literally defeats the entire purpose.  You're also assuming that all PHP
developers do 100% of their coding through pre-existing frameworks.

If you're including a library that contains embedded HTML, you should do so
from a regular .php file.  Then you can include the .phpp file at that same
level, thereby avoiding the collision.

For example, here's what you're suggesting:

 -- (Main Script) 
| |
| |
[Included .php/HTML Script] {Included .phpp Script}
  |
  |
[Included .php/HTML Script from Framework/Library]


That approach is bad architecture and simply unnecessary.  If you want to
interface with that library, do it like this instead:

(Main Script)
 |
 |
 [Included .php/HTML Script]
 |   |
 |   |
{Included .phpp Script}  [Included .php/HTML Script from
Framework/Library]


In other words, instead of calling that third-party, HTML-containing
library from the .phpp file, call both it and the .phpp file from a regular
.php file, which will then act as the "controller" and bridge the
functionality between the two.  This would be a far more *sane* architecture,
anyway.  And it allows you to achieve the exact same result, without having
to have included HTML bits polluting the upstream from the pure PHP stack.

Make sense?  I'm just not seeing any value in breaking this model just so
that bad, lazy architecture that shouldn't be used in the first place can
be supported.


> Whereas if we make this feature easy to adopt, and strict within the
> files it does apply to, then over time we would see more and more
> .phpp and less and less .php. Mission accomplished. Sometimes a
> realistic compromise is the long term way to get to a better place.
>
> Think through what will likely happen in the real world under various
> proposals, and not just what would be most pure (:
>

See above.  =)


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

Re: [PHP-DEV] Allow non-variable arguments to empty()

[Kris Craig]

On Tue, Apr 10, 2012 at 5:46 PM, Stas Malyshev wrote:

> Hi!
>
> > Err isn't this something that should go through the RFC process first?
> > I think it's a good idea and I'll probably vote for it, but as I
> > understand the RFC process was created specifically for stuff like this.
>
> One doesn't preclude the other. Pull is code, RFC is discussion, they
> can go in parallel.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

Well, technically it's discussion *and* vote.  I know we've been wanting to
get out of the habit of "push first, ask later," which is precisely what
RFC helps us avoid.  Personally, I think any commits for a non-minor change
(i.e. a new feature) should be branched and left unmerged until it passes
through the RFC voting process.  I'm a big fan of consistency over ad hoc
processes.  ;)

--Kris

Re: [PHP-DEV] Allow non-variable arguments to empty()

[Kris Craig]

On Tue, Apr 10, 2012 at 4:51 PM, Stas Malyshev wrote:

> Hi!
>
> > Currently the empty() language construct only works on variables. You
> > can write if (empty($array)) but not empty if (empty(getSomeArray()).
> >
> > The original reason for this restriction probably is that - in a way -
> > it "doesn't make sense" to pass anything but a variable to empty() as
> > you could just use the ! operator in this case. if
> > (empty(getSomeArray())) is logically equivalent to if
> > (!getSomeArray()).
>
> Don't see any problem with that, looks good. Please add some tests
> (including function calls and some expressions) and make a pull request.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Err isn't this something that should go through the RFC process first?  I
think it's a good idea and I'll probably vote for it, but as I understand
the RFC process was created specifically for stuff like this.

--Kris

Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening

[Kris Craig]

Tom,

On Tue, Apr 10, 2012 at 4:53 PM, Tom Boutell  wrote:

> Please see:
>
> https://wiki.php.net/rfc/source_files_without_opening_tag
>
> After following the discussion I have updated the RFC with the
> following major changes:
>
> * Forbade the use of ?> entirely in "pure PHP" files (without
> restricting it at all in other PHP files)
>
> * Replaced my original new require_path keyword with a second,
> optional parameter to the standard include/require family of keywords
>
> * Replaced an array of options with a bitwise OR of options
>
> * Changed the proposed filename extension from .phpc (which apparently
> is in use somewhere, maybe?) to .phpp ("php pure")
>
> --
> 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
>
>
Much better, though I'm still very troubled by allowing non-pure PHP code
to be mixed-in with pure PHP (by means of includes).  The problem I have
with this, as a developer, is that this means I can't really trust that
what I will get from a "pure PHP" script will actually be pure PHP, because
non-pure scripts lower in the stack might mix-in HTML code that would then
get passed up through the stack.  These really shouldn't be mixed anyway,
so I'm just not seeing any value in not keeping this separation consistent.

I'd be able to support this if that one remaining problem is fixed.  I
still would like to see the ability to add a 

Re: [PHP-DEV] Allow non-variable arguments to empty()

[Kris Craig]

On Tue, Apr 10, 2012 at 4:12 PM, Jelle Zijlstra wrote:

> 2012/4/10 Nikita Popov 
>
> > Hey internals!
> >
> > Currently the empty() language construct only works on variables. You
> > can write if (empty($array)) but not empty if (empty(getSomeArray()).
> >
> > The original reason for this restriction probably is that - in a way -
> > it "doesn't make sense" to pass anything but a variable to empty() as
> > you could just use the ! operator in this case. if
> > (empty(getSomeArray())) is logically equivalent to if
> > (!getSomeArray()).
> >
> > I'd like to propose to change empty() to accept arbitrary expressions.
> >
> > The reason is simple: Even though it is possible to write if
> > (!getSomeArray()) with the same effect, if (empty(getSomeArray()))
> > reads much nicer. !getSomeArray() to me somehow implies that
> > getSomeArray() may return a bool(false) or something like that. On the
> > other hand empty(getSomeArray()) seems naturally fit for checking for
> > empty arrays.
> >
> > Another reason is that currently you get a very obscure error message
> > if you try to use empty() on a function return value: "Can't use
> > function return value in write context". Aha. Where did I try to write
> > to the return value?!
> >
> > So, what do you think?
> >
> >
> I think this is a useful simplification of the language, removing an
> unnecessary exception. Would it also make sense to make empty() into a
> library function instead of a language construct? That would not result in
> any BC break as far as I can see, but would allow some things that are
> currently impossible (e.g., a method called "empty") and further simplify
> the language.
>
>
> > Nikita
> >
> > PS: The patch is trivial: https://gist.github.com/2355274
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

+1 on this.  Could you draft this into an RFC for us?

--Kris

Re: [PHP-DEV] release process with git

[Kris Craig]

On Tue, Apr 10, 2012 at 3:46 PM, Stas Malyshev wrote:

> Hi!
>
> > I think my main point still stands: if the git emails are too obscure to
> > follow, let us know what goes in via email to internals.
> >
> > Do you want to bring the NEWS updating process into this discussion?
>
> Sure, though that would be another discussion IMHO. In this discussion,
> I just wanted to see if there are any objections to this "clean release"
> model.
>
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Given the number of RCs we've seen in the past, I remain skeptical that
your approach will prove sustainable.  But I'd say let's just try it and
see how it goes.

--Kris

Re: [PHP-DEV] [off] PHP: a fractal of bad design

[Kris Craig]

On Tue, Apr 10, 2012 at 11:12 AM, Ralf Lang  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> > It always amuses me when PERL developers go on their little
> > soapboxes about how "real" programmers all think PHP is stupid
> > lol.
>
> It always amuses me PHP people think perl is stupid and vice versa.
> Both languages have their use case, sometimes I even use them side by
> side in the same project. PHP daemons and forking is not exactly what
> I would depend on working reliably.
>

Umm at what point did I say PERL is "stupid?"  PERL is like the duct-tape
of scripting languages; it can be used for just about anything, though
there's almost always a more specialized solution.  It serves a purpose.

But that being said, PERL has tons of flaws and other issues all its own.
That's why it amuses me whenever I see a PERL person get on a soapbox about
PHP.  Hypocrisy is funny.


>
> > Granted, PHP has MANY flaws, some of which are accurately mentioned
> > in the article (though as Pierre pointed out, it doesn't actually
> > raise any new points; and yes I did read the whole thing, including
> > the comments).  There are some things that PERL and "Ruby with
> > [sic?!] Rails" do better.  But that's why we're here.
>
> Exactly. There's a lot to improve and sometimes it can be done with
> little to now bc breaks. (And some breaks I would not mind if done
> right and for the right reasons).
>
>
> - --
> Ralf Lang
> Linux Consultant / Developer
> Tel.: +49-170-6381563
> Mail: l...@b1-systems.de
>
> B1 Systems GmbH
> Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.18 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk+EeBcACgkQCs1dsHJ/X7DtXgCgjnp/QXvpkSo/i5AYamIVhp+s
> xS4AoO3vO25gDlvTyziUC0k3GYo19KDE
> =Yt9n
> -END PGP SIGNATURE-
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [off] PHP: a fractal of bad design

[Kris Craig]

On Tue, Apr 10, 2012 at 9:38 AM, Stas Malyshev wrote:

> Hi!
>
> > today I read this post, I think that some points are valid, follow the
> link for
> > you guys
> >
>
> Could you name a few and explain why you think they are valid and what
> you propose to do to fix them? This article is huge and if you want to
> start a discussion that makes sense (as opposed to a rant which is, I am
> sure, very therapeutic for the author of the post but I'm not sure why
> should we care) I think the approach of "read the whole thing and guess
> what I meant by 'some points'" is not the best one.
>

+1


> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Do you know why a full 1/3 of the internet uses PHP?  BECAUSE IT WORKS!!
It is easy for newcomers and veterans alike.  It's very forgiving when it
comes to typing and other semantics.  As far as an error stack goes, PHP
really doesn't *need* once IMHO because the error messages are already
surprisingly precise (with a few notable exceptions lol), typically telling
you not just what the error is but exactly *where* it is, right down to the
line number!  Personally, I think that's just fucking awesome.

I started programming at the age of 12 using GW BASIC on my old 286 (I
remember how excited I was when my brother managed to obtain a pirated copy
of QuickBASIC lol).  I later "matured" into C/C++.  I didn't start using
PHP until I was 19 or 20.  It's been my favorite language to work in ever
since.  It always amuses me when PERL developers go on their little
soapboxes about how "real" programmers all think PHP is stupid lol.

Granted, PHP has MANY flaws, some of which are accurately mentioned in the
article (though as Pierre pointed out, it doesn't actually raise any new
points; and yes I did read the whole thing, including the comments).  There
are some things that PERL and "Ruby with [sic?!] Rails" do better.  But
that's why we're here.  Instead of trying to use the Internals list to
boost the SEO of your blog, why not actually contribute to make the
language better?  Or do you prefer to just be an armchair quarterback?

--Kris

Re: [PHP-DEV] RFC: source files without opening tag

[Kris Craig]

On Mon, Apr 9, 2012 at 10:35 PM, Luke Scott  wrote:

> On Apr 9, 2012, at 10:03 PM, Yasuo Ohgaki  wrote:
>
> > I strongly discourage settingallow_url_include=on, too.
>
> Good.
>
> > Enabling it only when it is needed is okay.
>
> No it's not. There is no reason to do so other than backwards
> compatibility for very old code.
>
> > I think you are concerned about security,
>
> Absolutely.
>
> > so you could agree to have
> > option for disabling embedded mode by option,  couldn't you?
>
> Sure it can be an option. But it can't be the default, at least right
> away. It's unreasonable. I would prefer an environmental variable to
> choose the mode though. I'm not opposed to a php.ini option, but some
> people are
>
> (If by embedded mode you mean template mode, and non-embedded mode as
> "pure code mode").
>
> I still fail to see what this has to do with allow_url_include.
>
> > Letting programmers decide what  to do
>
> Not in all cases.
>
> > Programming languages should give freedom to write suicide code
> > more or less.
>
> No, it shouldn't.
>
> All that you've said comes down to this:
>
> Don't write bad code. Configure your web server properly.
>
> The RFC isn't meant to address these issues, and quite frankly it
> isn't a core PHP issue. It's no different than any language with an
> eval() statement.
>
> Keep in mind an RFC isn't gospel. And it's still being drafted. We
> need to give Tom a chance to finish it.
>
> Luke
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I feel obliged to point out that both sides of this argument have been
represented eloquently and fully IMHO.  It now seems to have reached the
point where all substantive arguments have been said and thus are now
merely being repeated.  The last few messages back-and-forth could, at
least one some level, be summarized simply as, "Yes it is!" and "No it
isn't!"

There's clearly a fundamental disagreement exposed here as to the role a
programming language should play pertaining to the prevention of vulnerable
code and whether the burden lies with the language or the programmer to
assume responsibility for this.  My guess would be that it falls somewhere
in the middle, though I really haven't given it much thought to be honest.

I'd like to suggest that a new thread be created for this debate, since it
does seem to be sufficiently divergent from the original topic posted by
Tom.  I would also be interested to hear why you believe it should or
should not be the role of the language to prevent exploitable code and to
what degree.  Both sides have stated quite authoritatively that it is one
or the other, but what I'd like to see are some more in-depth arguments to
back-up those assertions.  From a strictly academic standpoint, I think
this argument poses an interesting opportunity to explore this
philosophical divide in detail.


But regardless, let's at least move it to a separate topic so Tom can argue
the case for his RFC without too much distraction.  =)

--Kris

Re: [PHP-DEV] RFC: source files without opening tag

[Kris Craig]

On Mon, Apr 9, 2012 at 7:02 PM, Yasuo Ohgaki  wrote:

> 2012/4/10 Kris Craig :
> > On Mon, Apr 9, 2012 at 6:15 PM, Luke Scott  wrote:
> >
> >> On 4/9/12 5:02 PM, "Kris Craig"  wrote:
> >>
> >> >On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell  wrote:
> >> >
> >> >> Let me be very clear about that... I am NOT proposing that  >> >> the top be mandatory in a file loaded in code mode! I don't want to
> >> >> type it ever again outside of a template file, personally. See the
> >> >> title of the RFC.
> >> >>
> >> >
> >> >But again, how then do you intend to make it so that a pure-code file
> can
> >> >be called directly from the webserver on a host where the developer
> >> >doesn't
> >> >have access to most config options?  This is a very common scenario
> that
> >> >cannot be ignored.  If not a  has
> >> >to identify it as pure code otherwise this just isn't workable.
> >> >
> >> >Any INI option would be problematic because that would essentially
> cause
> >> >all scripts relying on the setting you didn't choose to break.  And
> >> >unfortunately, recognizing a new file extension could pose problems for
> >> >people running on heavily restricted hosts that currently have PHP
> support
> >> >"built-in".  While I would never host on one of those services myself,
> I
> >> >don't like the idea of suddenly alienating everyone who does.
> >> >
> >> >I'd totally be open to an alternative to the  withstand
> >> >scrutiny, but so far I haven't seen one.  And absent that, there's no
> way
> >> >I
> >> >could support this, which really sucks because at least conceptually I
> >> >think it's a really good idea.
> >>
> >>
> >> If the default is "template mode" and the " the
> >> top) in "code" mode there shouldn't be any problems.
> >>
> >> We don't need to change or leave out the tag entirely.
> >>
> >> Is there a problem with people being able to choose "template mode" or
> >> "code mode" as the default in the php.ini file if "template mode" is the
> >> default if not specified?
> >>
> >
> > I think so, yes.  A config option that causes massive BC breakage doesn't
> > become ok simply because it defaults to current behavior.  I just can't
> > envision any situation in which having that option switched on would not
> > cause problems, unless that server is *only* running scripts that assume
> > code mode.  However, what if you want to use two scripts, but one assumes
> > code and the other assumes HTML?  The ini_set() function would be pretty
> > much useless given the circumstances.
> >
> > Instead, I would have an optional   This
> > would be in addition to the file extension/SAPI approach and the require
> > keyword approach.  In other words, perhaps an "all of the above" strategy
> > is what's neeeded here.  But either way, I just don't think an INI
> setting
> > would be feasible.
>
> Hi,
>
> I guess you are trying to fix other problem than me, but
> please have a look this RFC
>
> https://wiki.php.net/rfc/nophptags
>
> INI setting is feasible for controlling template(embed) mode. It's easy to
> understand what it does also.
> PHP programmers may write
>
> ini_set('template_mode', 'off'); // in bootstrap. older PHP just ignores
> this.
>  // Admin may put it
> in php.ini or .htaccess also.
>
> then they would set template_mode="on"/"off" just before/afeter render
> templates.
>
> ini_set('template_mode', on); // old PHP ignores
> render_template($my_tpl, $my_tpl_vars); // do whatever is needed as
> template engine
> ini_set('template_mode', off); // old PHP ignores
>
> Above code works for both template_mode="on" and "off" in php.ini.
>
> In real world, programmer would write ini_set() inside of
> render_template().
> This simple change makes PHP free from fatal LFI mess while maintaining
> compatibility with older PHP.
>
> If you don't want to write needless PHP tags, you don't have to with this
> RFC, too.
>

Yeah I get that.  I'm just not sure I see the point.  Aren't there already
text editors that handle the  Regards,
>
> --
> Yasuo Ohg

Re: [PHP-DEV] RFC: source files without opening tag

[Kris Craig]

On Mon, Apr 9, 2012 at 6:15 PM, Luke Scott  wrote:

> On 4/9/12 5:02 PM, "Kris Craig"  wrote:
>
> >On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell  wrote:
> >
> >> Let me be very clear about that... I am NOT proposing that  >> the top be mandatory in a file loaded in code mode! I don't want to
> >> type it ever again outside of a template file, personally. See the
> >> title of the RFC.
> >>
> >
> >But again, how then do you intend to make it so that a pure-code file can
> >be called directly from the webserver on a host where the developer
> >doesn't
> >have access to most config options?  This is a very common scenario that
> >cannot be ignored.  If not a  >to identify it as pure code otherwise this just isn't workable.
> >
> >Any INI option would be problematic because that would essentially cause
> >all scripts relying on the setting you didn't choose to break.  And
> >unfortunately, recognizing a new file extension could pose problems for
> >people running on heavily restricted hosts that currently have PHP support
> >"built-in".  While I would never host on one of those services myself, I
> >don't like the idea of suddenly alienating everyone who does.
> >
> >I'd totally be open to an alternative to the  >scrutiny, but so far I haven't seen one.  And absent that, there's no way
> >I
> >could support this, which really sucks because at least conceptually I
> >think it's a really good idea.
>
>
> If the default is "template mode" and the " top) in "code" mode there shouldn't be any problems.
>
> We don't need to change or leave out the tag entirely.
>
> Is there a problem with people being able to choose "template mode" or
> "code mode" as the default in the php.ini file if "template mode" is the
> default if not specified?
>

I think so, yes.  A config option that causes massive BC breakage doesn't
become ok simply because it defaults to current behavior.  I just can't
envision any situation in which having that option switched on would not
cause problems, unless that server is *only* running scripts that assume
code mode.  However, what if you want to use two scripts, but one assumes
code and the other assumes HTML?  The ini_set() function would be pretty
much useless given the circumstances.

Instead, I would have an optional  Luke
>
>
> >
> >--Kris
> >
> >
> >
> >>
> >> On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott  wrote:
> >> > On 4/9/12 3:53 PM, "Tom Boutell"  wrote:
> >> >
> >> >>I see why you want to allow  >> >>mode,' rather than disallowed in code mode. But your purpose is to
> >> >>allow legacy code to be autoloaded without knowing in advance whether
> >> >>it starts with  >> >>
> >> >>But that would probably lead in practice to the use of a single file
> >> >>extension for old and new class files.
> >> >>
> >> >>And that, in turn, would lead to source code being spewed to the
> >> >>browser for all to see if a perfectly respectable autoloader circa PHP
> >> >>5.3 runs into one of these new files.
> >> >>
> >> >>This is a much more significant security issue than some of those
> >> >>mentioned previously because perfectly well-written code would display
> >> >>this behavior if someone unknowingly drops a newer library into, say,
> >> >>the lib/ folder of a Symfony 1.4 project. Ouch.
> >> >
> >> >
> >> > So are you saying the starting " >> > mode"?
> >> >
> >> > If so, I'm ok with that as long as:
> >> >
> >> > - "?>" is forbidden
> >> >
> >> > - Text before the opening  >> > either ignored or throws an error instead of printing to the output
> >> buffer.
> >> >
> >> > If that's not what you mean, please clarify.
> >> >
> >> > Luke
> >> >
> >> >>
> >> >>It would be much better for that autoloader to just ignore the file
> >> >>because it has a new extension. This way the problem is immediately
> >> >>apparent:
> >> >>
> >> >>"Hey, my class didn't load, something must be up. Oh my PHP is old
> >> >>and/or this autoloader doesn't know about .phpc files, what are they
> >> >>anyway... 

Re: [PHP-DEV] RFC: source files without opening tag

[Kris Craig]

On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell  wrote:

> Let me be very clear about that... I am NOT proposing that  the top be mandatory in a file loaded in code mode! I don't want to
> type it ever again outside of a template file, personally. See the
> title of the RFC.
>

But again, how then do you intend to make it so that a pure-code file can
be called directly from the webserver on a host where the developer doesn't
have access to most config options?  This is a very common scenario that
cannot be ignored.  If not a 
> On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott  wrote:
> > On 4/9/12 3:53 PM, "Tom Boutell"  wrote:
> >
> >>I see why you want to allow  >>mode,' rather than disallowed in code mode. But your purpose is to
> >>allow legacy code to be autoloaded without knowing in advance whether
> >>it starts with  >>
> >>But that would probably lead in practice to the use of a single file
> >>extension for old and new class files.
> >>
> >>And that, in turn, would lead to source code being spewed to the
> >>browser for all to see if a perfectly respectable autoloader circa PHP
> >>5.3 runs into one of these new files.
> >>
> >>This is a much more significant security issue than some of those
> >>mentioned previously because perfectly well-written code would display
> >>this behavior if someone unknowingly drops a newer library into, say,
> >>the lib/ folder of a Symfony 1.4 project. Ouch.
> >
> >
> > So are you saying the starting " > mode"?
> >
> > If so, I'm ok with that as long as:
> >
> > - "?>" is forbidden
> >
> > - Text before the opening  > either ignored or throws an error instead of printing to the output
> buffer.
> >
> > If that's not what you mean, please clarify.
> >
> > Luke
> >
> >>
> >>It would be much better for that autoloader to just ignore the file
> >>because it has a new extension. This way the problem is immediately
> >>apparent:
> >>
> >>"Hey, my class didn't load, something must be up. Oh my PHP is old
> >>and/or this autoloader doesn't know about .phpc files, what are they
> >>anyway... google google... aha, I need PHP 5.x and an updated
> >>autoloader. Grumble. Okay."
> >>
> >>This is a much safer outcome.
> >>
> >>On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott  wrote:
> >>> Tom,
> >>>
> >>> On 4/9/12 3:17 PM, "Tom Boutell"  wrote:
> >>>
> >>>>My original goal was to stop typing  >>>>includes at the top. I think it's entirely reasonable to achieve it
> >>>>with an option to the require keywords for this purpose and a naming
> >>>>convention to be followed by autoloaders. Keep in mind how rarely you
> >>>>have to change them. We're talking about code maintained by a
> >>>>relatively small number of very sharp developers. They can handle a
> >>>>few flags (:
> >>>>
> >>>>The prohibition of ?> still seems unnecessary and perhaps divisive,
> >>>>but if it were preferable to the majority to prohibit ?> in a pure
> >>>>code file, I could live with that as long as classic PHP files are
> >>>>also 100% supported and remain the default. I'm trying to craft a
> >>>>broadly acceptable compromise that still achieves the original goal of
> >>>>allowing people to write "just code" in a class file.
> >>>
> >>>
> >>> I think you can you achieve that by making "template mode" default and
> >>>the
> >>> default changeable in the php.ini file.
> >>>
> >>> Something like this:
> >>>
> >>> /*
> >>>Code only, .
> >>>Text before opening  >>>
> >>> */
> >>>
> >>> require "/path/to/somefile.php", INCLUDE_CODE;
> >>>
> >>> /*
> >>>Works exactly as it is now:  allowed.
> >>>Text betweeen ?>... >>> */
> >>>
> >>>
> >>>
> >>> require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now
> >>>
> >>> /*
> >>>By default INCLUDE_TEMPLATE
> >>>Can change default mode in php.ini to be INCLUDE_CODE if desired.
> >>> */
> >>>
> >>> require "/path/to/anot

Re: [PHP-DEV] RFC: source files without opening tag

[Kris Craig]

On Mon, Apr 9, 2012 at 3:34 PM, Luke Scott  wrote:

> Tom,
>
> On 4/9/12 3:17 PM, "Tom Boutell"  wrote:
>
> >My original goal was to stop typing  >includes at the top. I think it's entirely reasonable to achieve it
> >with an option to the require keywords for this purpose and a naming
> >convention to be followed by autoloaders. Keep in mind how rarely you
> >have to change them. We're talking about code maintained by a
> >relatively small number of very sharp developers. They can handle a
> >few flags (:
>

Again though, the problem here is that you're relying on the
*including*script to determine whether a PHP script is pure or not;
i.e. this approach
leaves no way for that to be determined in the file itself.  For example, I
can see perfectly valid instances where it would be ideal to execute one of
these pure scripts as a direct call to the webserver-- AJAX being a prime
example.  I.e. cases where you want backend PHP processing to take place
but it has to be accessed via the browser (most likely "hidden" as an AJAX
query though).

So without the ability to do that, I just don't think this passes the
usefulness test for me.  And if we do have the ability to specify that in
the file, on the other hand, then that would pretty much eliminate the need
for a require flag anyway.

The only alternative I can see would be to allow something to be passed in
the headers telling the webserver to parse a script as PHP instead of
HTML.  But I don't know if that would be extremely simple or extremely
problematic.

--Kris



> >
> >The prohibition of ?> still seems unnecessary and perhaps divisive,
> >but if it were preferable to the majority to prohibit ?> in a pure
> >code file, I could live with that as long as classic PHP files are
> >also 100% supported and remain the default. I'm trying to craft a
> >broadly acceptable compromise that still achieves the original goal of
> >allowing people to write "just code" in a class file.
>
>
> I think you can you achieve that by making "template mode" default and the
> default changeable in the php.ini file.
>
> Something like this:
>
> /*
>Code only, .
>Text before opening 
> */
>
> require "/path/to/somefile.php", INCLUDE_CODE;
>
> /*
>Works exactly as it is now:  allowed.
>Text betweeen ?>... */
>
>
>
> require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now
>
> /*
>By default INCLUDE_TEMPLATE
>Can change default mode in php.ini to be INCLUDE_CODE if desired.
> */
>
> require "/path/to/anotherfile.php"; // As it is now
>
>
> Personally I would like to be able to do something like this in my auto
> loader:
>
> include $file, INCLUDE_CODE & INCLUDE_SILENT;
>
>
>
> That way I can ensure pure code is being inserted and no warnings are
> thrown if the file doesn't exist (class undefined will be thrown anyway).
>
> I think it's important to make  existing or third party libraries that you can't modify. At least then
> you'll be able to maintain backwards compatibility with most code written
> since PHP 5.
>
> (We don't need PHP_*. See the output of get_defined_constants() ).
>
> I like where this is going! Hopefully after the RFC has been finalized
> everyone else will agree.
>
>
> >
> >On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig  wrote:
>
>
> Kris,
>
>
>
> >>
> >>
> >> Bah, right!  That damned  >>
> >> I already know what everyone's reaction will be, and it is probably a
> >>REALLY
> >> bad idea, but I feel obligated to at least mention it:  Should we
> >>consider
> >> replacing " >> perhaps starting in PHP 6?  No need to get out the torches and
> >>pitchforks,
> >> everyone!  As insane and problematic as that would be (i.e. BC break
> >>with
> >> roughly 1/3 of the internet lol), I felt as though the subject should at
> >> least be broached.  ;P
>
>
> No need. Just keep it as  should ovoid overcomplicating it.
>
> Luke
>
>
>

Re: [PHP-DEV] RFC: source files without opening tag

[Kris Craig]

On Mon, Apr 9, 2012 at 2:38 PM, Luke Scott  wrote:

> > Obviously, it would need to be at the top of the PHP file (whitespace
> > notwithstanding).  Since we don't want any BC breaks, we at very least
> need
> > it to start with " wasn't
> > mean to be parsed.  So how about we keep it simple and just use a single,
> > " would be allowed after
> that.
> > Anything before that (in the file itself) would also be ignored and
> throw a
> > warning.
>
> Remember, 

Bah, right!  That damned 
> > This sounds like the best approach, given the limitations involved with
> > webserver configurations.  I'm still very much against though allowing ?>
> > within one of these files (included or otherwise), as it really defeats
> the
> > whole purpose and would just encourage poor architecture without any
> > countervailing benefit.
>
> Agreed. Disallowing ?> in a file in pure code means only one  at the top.
>

> A flag on require/include is acceptable to me, as long as the default
> mode is configurable in the php.ini file (when none are specified).
>

Perhaps we should split that into a separate RFC?  I.e. a require flag that
tells it to parse the included PHP file as pure PHP, regardless of whether
or not it has the 
> Luke
>
> >
> > --Kris
>

Re: [PHP-DEV] release process with git

[Kris Craig]

On Mon, Apr 9, 2012 at 2:57 PM, Stas Malyshev wrote:

> Hi!
>
> > release candidates.  I mean, we're still planning on having multiple
> > release candidates before an actual release, right?  If so, then
>
> Not if we can avoid it. If we don't have critical bugs in RC1, we
> release it.
>
> > obviously we'll need a way to commit those changes.  If they're not made
> > on the RC branch, then where were you thinking they should go, and how
> > would we then apply those bugfixes to the 5.4 trunk if not through a
> merge?
>
> If you have bugfix for 5.4, commit it into 5.4. If it's critical for
> current release, it will be pulled by RM into the release, otherwise he
> automatically becomes part of the next release.
>

My concern is that merge conflicts can occur when cherry-picking in this
manner.  It's just generally not a "best practices" approach when using Git
IMHO.  The appropriate way to do this would be to have these bugfixes
pushed as separate branches based off of the release branch, then the RM
chooses whether or not to merge each one back into the release branch.
This takes advantage of Git's built-in branching/merging functionality
without the need for manual cherry-picking.  These fixes can then be merged
back into trunk, so the end result is the same but with far less manual
work and less potential for human error.

--Kris


> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

Re: [PHP-DEV] release process with git

[Kris Craig]

On Mon, Apr 9, 2012 at 2:33 PM, Kiall Mac Innes  wrote:

> On Mon, Apr 9, 2012 at 10:27 PM, Kris Craig  wrote:
>>
>> What I'm referring to is the same kind of bugfixes/etc that go into new
>> release candidates.  I mean, we're still planning on having multiple
>> release candidates before an actual release, right?  If so, then obviously
>> we'll need a way to commit those changes.  If they're not made on the RC
>> branch, then where were you thinking they should go, and how would we then
>> apply those bugfixes to the 5.4 trunk if not through a merge?
>
>
> Referring again to how openstack manages this (because I personally feel
> they have nailed it)..
>
> Any commit that should be applied to the RC should also be applied to
> master/trunk, right? So - Why not commit it to master/trunk and nominate it
> for inclusion in the release. This allows a release manager to look at the
> bug, the fix, and the implications of of the fix before the fix lands in
> the RC.
>
> Once a commit has been made to master/trunk.. That fix can be
> cherry-picked into the RC if it's deemed suitable.
>

That approach would also work, so long as the RM doesn't mind having to
cherry-pick through different commits, making sure they're not based off of
non-included commits that would cause conflicts, etc.  Git merging
essentially does the bulk of this grunt work for you; but the downside, as
Stas pointed out, is that people would then wind-up posting unnecessary
commits because there would be no manual filtering.

Hmm so how about we consider a third option?  It sounds like what we need
is a bridge so that bugfixes can be quarantined yet still cherry-picked by
the RM without the added burden of code conflicts being introduced from
trunk.

So how about this:


   1. RM creates PHP-5.4.x branch from PHP-5.4.
   2. Development continues on PHP-5.4 branch without any interaction with
   PHP-5.4.x branch.
   3. RM is allowed to commit directly to PHP-5.4.x.
   4. Anybody else who wants to propose a bugfix will create a new branch
   based off of PHP-5.4.x.
  - For example:  git checkout -b Bugfix-Some_Bugfix_Title PHP-5.4.x.
   5. Once commit(s) on Bugfix branch are made, developer merges the bugfix
   into PHP-5.4 trunk branch and asks the RM (i.e. "nominates" it, as you put
   it) to merge it into the PHP-5.4.x release branch as well.
   6. RM can decide whether or not to merge it in.  Because the branch was
   based off of the release branch as opposed to trunk, it's considerably less
   likely that any conflicts will emerge should the RM decide to merge it in.
   If s/he doesn't merge it in, the changes have already been merged into the
   trunk branch so at very least they'll be there for the next release.

This approach should address everyone's concerns while taking advantage of
Git's branching functionality, which was designed precisely with situations
such as this in mind.  The RM filter remains but the manual workload and
potential for human error are both dramatically reduced.

--Kris


> Thanks,
> Kiall
>

Re: [PHP-DEV] RFC: source files without opening tag

[Kris Craig]

Lol true dat.  You convinced me on the file extension, so as far as I can
tell that just leaves us with the tag itself as the viable approach.  =)

--Kris


On Mon, Apr 9, 2012 at 2:24 PM, Tom Boutell  wrote:

> I'm not sure you're wrong about this, but it's definitely an ironic
> suggestion (:
>
> On Mon, Apr 9, 2012 at 5:22 PM, Kris Craig  wrote:
> >
> >
> > On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell  wrote:
> >>
> >> As others explained before the RFC was drafted, file extensions should
> >> not be directly respected by PHP because environments differ too much.
> >> Instead a convention, NOT enforced at the code level, would be
> >> published and encouraged: .phpc for files that start out in PHP mode,
> >> and .php for files that start out in HTML mode. PHP would NOT enforce
> >> this, it would just be an encouraged practice in the writing of
> >> autoloaders and so on. (Note that autoloaders are already concerned
> >> with file extensions. They have to be in order to transform a class
> >> name into a filename.)
> >>
> >> The RFC does not call for putting an end to the traditional use of PHP
> >> for templates at all, that is still the default behavior when parsing
> >> PHP. There is an entirely separate RFC that calls for that, but that's
> >> another thread.
> >>
> >> On Mon, Apr 9, 2012 at 4:58 PM, Rick WIdmer 
> >> wrote:
> >> > On 4/9/2012 2:41 PM, Kris Craig wrote:
> >> >>>
> >> >>>
> >> >> Honestly, I would suggest just getting rid of "Option 1" altogether.
> >> >>  It
> >> >> would end up over-complicating this to such a degree that any
> >> >> usefulness
> >> >> it
> >> >> might serve would be considerably diminished.
> >> >>
> >> >> As for embedded HTML, if you allow the ?>  tag in these .phpp files,
> >> >> then
> >> >> that pretty much negates the entire purpose of having them to begin
> >> >> with.
> >> >> Essentially, you'd just be changing it so that, instead of defaulting
> >> >> to
> >> >> "?>" when no tag is present, it defaults to" >> >> any
> >> >> value in that as a developer.
> >> >>
> >> >> A developer should *not* be including in a .phpp file classes that
> >> >> contain
> >> >> HTML within the ?>  tag, period.  If they need to include something
> >> >> that
> >> >> has
> >> >> that, they should do it in a regular .php file.  An "HTML-less" PHP
> >> >> file
> >> >> needs to be exactly that; no direct HTML allowed.  Otherwise, the RFC
> >> >> is
> >> >> completely and utterly pointless IMHO.
> >> >>
> >> >>
> >> >> I think this would be awesome for PHP 6, but I'll have to vote
> against
> >> >> it
> >> >> if you settle on using "Option 1" and/or allow ?>  content to be
> >> >> embedded/included in .phpp files.  If we differentiate based solely
> on
> >> >> the
> >> >> file extension and keep ?>  tags out of it, then I'll definitely
> >> >> support
> >> >> it!
> >> >
> >> >
> >> >
> >> >
> >> > Please forget about file extensions.  PHP should not consider file
> >> > extensions.  The only reason .php files are executed by PHP is because
> >> > the
> >> > web browser is configured to pass that extension to PHP rather than
> >> > handle
> >> > it internally.
> >> >
> >> >
> >> > I sincerely hope that any suggestion to eliminate the ability to use
> PHP
> >> > as
> >> > a template engine will be met with a veto by the core developers, or
> >> > maybe
> >> > even another suggestion by the trademark owner of PHP that he will not
> >> > allow
> >> > the PHP name to be used on such a language.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > PHP Internals - PHP Runtime Development Mailing List
> >> > To unsubscribe, visit: http://www.php.net/unsub.php
> >> >
> >>
> >>
> >>
> >> --
&g

Re: [PHP-DEV] release process with git

[Kris Craig]

Stas,

On Mon, Apr 9, 2012 at 2:07 PM, Stas Malyshev wrote:

> Hi!
>
> > version of a "Release-x.xx" branch.  I would suggest allowing commits on
> > that branch, but *only* if they're bugfixes or minor housekeeping.  Each
>
> I don't want to do this, because this would very quickly lead us back to
> old chaotic situation where people commit stuff at the last moment and
> it's not properly tested. I prefer to have defined merge points.
>
> > commit would basically be the equivalent of a release candidate (i.e.
> > initial branch commit would be RC1, next commit RC2, etc).
> >
> > Then when it's time to pull the trigger, the final commit on that branch
> > will be the actual release.  Then merge that branch back into PHP-5.4.
>
> That's what I don't want to do. I don't want people to be
> live-committing into release branch and then merge it back to dev
> branch. I want release branch be clean and frozen as much as possible,
> and people committing to dev branch as needed. No last-minute bugfixes
> either unless it's a bug that absolutely breaks the release - otherwise
> it'll be released in a month, most bugs can wait for a month without any
> problem, given that they waited till now.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

What I'm referring to is the same kind of bugfixes/etc that go into new
release candidates.  I mean, we're still planning on having multiple
release candidates before an actual release, right?  If so, then obviously
we'll need a way to commit those changes.  If they're not made on the RC
branch, then where were you thinking they should go, and how would we then
apply those bugfixes to the 5.4 trunk if not through a merge?

--Kris

Re: [PHP-DEV] RFC: source files without opening tag

[Kris Craig]

On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell  wrote:

> As others explained before the RFC was drafted, file extensions should
> not be directly respected by PHP because environments differ too much.
> Instead a convention, NOT enforced at the code level, would be
> published and encouraged: .phpc for files that start out in PHP mode,
> and .php for files that start out in HTML mode. PHP would NOT enforce
> this, it would just be an encouraged practice in the writing of
> autoloaders and so on. (Note that autoloaders are already concerned
> with file extensions. They have to be in order to transform a class
> name into a filename.)
>
> The RFC does not call for putting an end to the traditional use of PHP
> for templates at all, that is still the default behavior when parsing
> PHP. There is an entirely separate RFC that calls for that, but that's
> another thread.
>
> On Mon, Apr 9, 2012 at 4:58 PM, Rick WIdmer 
> wrote:
> > On 4/9/2012 2:41 PM, Kris Craig wrote:
> >>>
> >>>
> >> Honestly, I would suggest just getting rid of "Option 1" altogether.  It
> >> would end up over-complicating this to such a degree that any usefulness
> >> it
> >> might serve would be considerably diminished.
> >>
> >> As for embedded HTML, if you allow the ?>  tag in these .phpp files,
> then
> >> that pretty much negates the entire purpose of having them to begin
> with.
> >> Essentially, you'd just be changing it so that, instead of defaulting to
> >> "?>" when no tag is present, it defaults to" any
> >> value in that as a developer.
> >>
> >> A developer should *not* be including in a .phpp file classes that
> contain
> >> HTML within the ?>  tag, period.  If they need to include something that
> >> has
> >> that, they should do it in a regular .php file.  An "HTML-less" PHP file
> >> needs to be exactly that; no direct HTML allowed.  Otherwise, the RFC is
> >> completely and utterly pointless IMHO.
> >>
> >>
> >> I think this would be awesome for PHP 6, but I'll have to vote against
> it
> >> if you settle on using "Option 1" and/or allow ?>  content to be
> >> embedded/included in .phpp files.  If we differentiate based solely on
> the
> >> file extension and keep ?>  tags out of it, then I'll definitely support
> >> it!
> >
> >
> >
> >
> > Please forget about file extensions.  PHP should not consider file
> > extensions.  The only reason .php files are executed by PHP is because
> the
> > web browser is configured to pass that extension to PHP rather than
> handle
> > it internally.
> >
> >
> > I sincerely hope that any suggestion to eliminate the ability to use PHP
> as
> > a template engine will be met with a veto by the core developers, or
> maybe
> > even another suggestion by the trademark owner of PHP that he will not
> allow
> > the PHP name to be used on such a language.
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > 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
>
>
Hmm yeah I see your point.  Requiring a separate file extension would force
configuration changes to the webserver.  And since not everybody has access
to that, it would mean that any projects that contain these files would not
be able to run on hosts like that.

Ok you've convinced me on the file extension issue, just based on that.
But I still don't like the new require_* keywords or allowing ?> to be
mixed-in with PHP scripts that are supposed to be pure code.  Again it just
comes down to a question of usefulness and creating a solution in search of
a problem.

What we need is a way to tell the parser that this file is pure PHP.  We
can't use the file extension, so it has to be at the code level.  If I'm
interpreting your proposals correctly, it looks like your approach would be
to have the including file make this determination.  Personally, I think we
should do the opposite; i.e. this should be defined in the PHP file itself.

Obviously, it would need to be at the top of the PHP file (whitespace
notwithstanding).  Since we don't want any BC breaks, we at very least need
it to start with " would be allowed after that.
Anything before that (in the file itself) would also be ignored and throw a
warning.

This sounds like the best approach, given the limitations involved with
webserver configurations.  I'm still very much against though allowing ?>
within one of these files (included or otherwise), as it really defeats the
whole purpose and would just encourage poor architecture without any
countervailing benefit.

--Kris

Re: [PHP-DEV] RFC: source files without opening tag

[Kris Craig]

On Mon, Apr 9, 2012 at 1:58 PM, Rick WIdmer wrote:

> On 4/9/2012 2:41 PM, Kris Craig wrote:
>
>>
>>>  Honestly, I would suggest just getting rid of "Option 1" altogether.  It
>> would end up over-complicating this to such a degree that any usefulness
>> it
>> might serve would be considerably diminished.
>>
>> As for embedded HTML, if you allow the ?>  tag in these .phpp files, then
>> that pretty much negates the entire purpose of having them to begin with.
>> Essentially, you'd just be changing it so that, instead of defaulting to
>> "?>" when no tag is present, it defaults to"> value in that as a developer.
>>
>> A developer should *not* be including in a .phpp file classes that contain
>>
>> HTML within the ?>  tag, period.  If they need to include something that
>> has
>> that, they should do it in a regular .php file.  An "HTML-less" PHP file
>> needs to be exactly that; no direct HTML allowed.  Otherwise, the RFC is
>> completely and utterly pointless IMHO.
>>
>>
>> I think this would be awesome for PHP 6, but I'll have to vote against it
>> if you settle on using "Option 1" and/or allow ?>  content to be
>> embedded/included in .phpp files.  If we differentiate based solely on the
>> file extension and keep ?>  tags out of it, then I'll definitely support
>> it!
>>
>
>
>
> Please forget about file extensions.  PHP should not consider file
> extensions.  The only reason .php files are executed by PHP is because the
> web browser is configured to pass that extension to PHP rather than handle
> it internally.
>
>
> I sincerely hope that any suggestion to eliminate the ability to use PHP
> as a template engine will be met with a veto by the core developers, or
> maybe even another suggestion by the trademark owner of PHP that he will
> not allow the PHP name to be used on such a language.


That's a bit harsh, don't you think?  I mean, it seems a little premature
to be talking about bringing forth IP litigation to stop an RFC that's
still being drafted.

--Kris

Re: [PHP-DEV] release process with git

[Kris Craig]

On Mon, Apr 9, 2012 at 3:26 AM, Kiall Mac Innes  wrote:

> This is a very similar process to what OpenStack uses, it seems to work
> well for them.
>
> They have a few guys on freenode in #openstack-infra that have shown
> themselves more than willing to go into detail about their setup and its
> pro/con's..
>
> It would be worth asking them for their experience...
>
> Thanks,
> Kiall
>
> Sent from my phone.
> On Apr 9, 2012 7:54 a.m., "Stas Malyshev"  wrote:
>
> > Hi!
> >
> > 5.4.1 will be the first release we're releasing using our new git setup.
> > I would like to refine a process that we used to have for releases and
> > make small tweaks hopefully to allow us more predictable release
> > schedule and faster releases.
> > What I am proposing is the following:
> > 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is
> > done on Monday/Tuesday (days can be tweaked back&forth a bit, but I
> > assume we'll usually release on Thursday and count back from that).
> > 2. This branch is checked by RM to compile, pass unit tests
> > satisfactory, etc. and is released as 5.4.X RC1
> > 3. In two weeks, if no critical errors is found in RC1, the same branch
> > is released as 5.4.X. If any critical errors are found, RM cherry-pick
> > fixes from 5.4 and release RC2 (RC3, etc. as needed) each two weeks
> > after no criticial bugs are in 5.4.X branch.
> > 4. In two more weeks, 5.4.(X+1) starts, provided we have changes from
> > 5.4.X. If not, it is postponed by 2 weeks.
> >
> > It is somewhat different from what we did before as we never disallow
> > committing into 5.4 and never allow (direct) committing into 5.4.X. This
> > also means we will be releasing 2-weeks-old code (or maybe older), i.e.
> > we will frequently be releasing code which has known (and fixed in other
> > branch) bugs.
> >
> > This will also mean we will have to define what constitutes critical
> > error, and maybe raise the bar a bit. I would like to propose the
> > following criteria for critical error:
> > 1. Compilation failure on a major platform (Linux, Windows, Mac, maybe
> > some others at RM discretion)
> > 2. Remotely exploitable security problem
> > 3. Bug that breaks a large piece of widely used functionality, effective
> > rendering it unusable (i.e. if somebody broke fopen() and it always
> > returned false).
> > Other things may be added on case-by-case basis but this will be the
> > guidelines. All other changes go into the next release.
> >
> > I think doing it this way will allow us to have 5.4.X releases monthly
> > as we planned in the release RFC. This will also mean that there would
> > be almost constant lag between committing regular fix and releasing it,
> > which may be larger than we had before. I think it won't be too bad if
> > we had regular monthly releases.
> >
> > Comments?
> > --
> > Stanislav Malyshev, Software Architect
> > SugarCRM: http://www.sugarcrm.com/
> > (408)454-6900 ext. 227
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Yeah this also sounds similar to Gitflow, as this would basically be our
version of a "Release-x.xx" branch.  I would suggest allowing commits on
that branch, but *only* if they're bugfixes or minor housekeeping.  Each
commit would basically be the equivalent of a release candidate (i.e.
initial branch commit would be RC1, next commit RC2, etc).

Then when it's time to pull the trigger, the final commit on that branch
will be the actual release.  Then merge that branch back into PHP-5.4.  By
doing that last step, parallel ongoing development on the next 5.4 release
can continue without restriction.  Any last-minute bugfixes from the
PHP-5.4.X branch would be merged-in so everything would remain up-to-date.

--Kris

Re: [PHP-DEV] PHP class files without

[Kris Craig]

On Mon, Apr 9, 2012 at 4:11 AM, Pierre Joye  wrote:

> hi!
>
> On Mon, Apr 9, 2012 at 12:48 PM, Tom Boutell  wrote:
> > I agree, which is why the rfc does not call for a php.ini option.
>
> Can we kill this thread and focus only on the RFC one please? Thanks.
>
>
+1

We've got 2 active threads discussing the same idea.  Let's move further
replies to the one linking to the RFC so it's easier to follow, ok?

Thanks!

--Kris


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

Re: [PHP-DEV] RFC: source files without opening tag

[Kris Craig]

Tom,

On Mon, Apr 9, 2012 at 1:20 PM, Yasuo Ohgaki  wrote:

> Hi,
>
>
> 2012/4/10 Stas Malyshev :
> > Hi!
> >
> >>> I'm not sure I follow - which PHP vulnerability you are talking about?
> >>
> >> Local file includes. (LFI)
> >
> > I'm not sure I understand - where's the vulnerability?
> >
> >> There is a null byte protection for LFI and I really like to the
> protection.
> >> It's also beneficial to other problems. However, it would not help codes
> >> like "include $_REQUEST['var']"
> >
> > Don't write such code. It's like saying exec() function is a
> > "vulnerability" in libc. You instruct PHP to run code based on user
> > input - that's what PHP will be doing, it's not a "vulnerability" by any
> > definition.
>
> I agree. Programmer should not write that.
>
> I would not propose the RFC if PHP is used as embedded languages mainly
> or the vulnerability is non fatal. By making embedded mode non mandatory,
> almost all issues will be gone. Why shouldn't we?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Honestly, I would suggest just getting rid of "Option 1" altogether.  It
would end up over-complicating this to such a degree that any usefulness it
might serve would be considerably diminished.

As for embedded HTML, if you allow the ?> tag in these .phpp files, then
that pretty much negates the entire purpose of having them to begin with.
Essentially, you'd just be changing it so that, instead of defaulting to
"?>" when no tag is present, it defaults to " tag, period.  If they need to include something that has
that, they should do it in a regular .php file.  An "HTML-less" PHP file
needs to be exactly that; no direct HTML allowed.  Otherwise, the RFC is
completely and utterly pointless IMHO.


I think this would be awesome for PHP 6, but I'll have to vote against it
if you settle on using "Option 1" and/or allow ?> content to be
embedded/included in .phpp files.  If we differentiate based solely on the
file extension and keep ?> tags out of it, then I'll definitely support it!

--Kris

Re: [PHP-DEV] RFC: source files without opening tag

[Kris Craig]

Tom,

On Sun, Apr 8, 2012 at 4:14 PM, Tom Boutell  wrote:

> Thanks. However, would you please fix the summary on the RFC's page to
> match the summary in the actual RFC? As you have written it, it
> implies that support for  not the case.
>
> As for adding a boolean parameter to the require keyword, as the RFC
> mentions there are already at least two distinctions already when
> requiring files in PHP:
>
> * include vs. require behavior (warning vs. error on failure)
> * once vs. every time (require_once vs. require)
>
> And we are proposing a third:
>
> * start in php mode vs. start in html mode
>
> We already have four keywords for requiring files. At this point it
> does not make sense to keep introducing more keywords (we would need 8
> with this change). Your boolean flag proposal keeps it to four
> keywords, but as soon as someone adds another flag it will become
> awkward to remember them. Since PHP does not have named parameters I
> think an associative array is the best way to go (especially with the
> new short syntax).
>
> Also I don't think it makes sense to forbid shifting into html mode
> later in the file, it could reduce support for the proposal needlessly
> - since it already lets people who want to write clean all-PHP files
> do so, and some of those people might have legitimate reasons to use
> HTML mode in the scope of a function or method (where it does not
> suddenly introduce whitespace without being explicitly called, etc).
>
> But if it really came down to it I could live with an "absolutely
> nothing but PHP" behavior when the code flag is true (supporting  when the flag is not set is a must of course).
>
> On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki  wrote:
> > Hi,
> >
> > I talked on twitter.
> > Yes, he is kidding, but he is serious, too.
> >
> > I've added the RFC to Under Discussion and added
> > security issue description. I also added my proposal that
> > controls embed mode.
> >
> > BTW, I don't think we need new "require_path" why don't
> > we use
> >
> > require "file.php", ture;
> >
> > or some thing similar?
> > I prefer to use switch, since security countermeasure is
> > better to be enforced by switch.
> >
> > Regards,
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
> >
> >
> >
> > 2012/4/9 Tom Boutell :
> >> Moriyoshi was kidding, as near as I can tell (:
> >>
> >> To take it at face value though, the *cough* April 1st *cough*
> >> proposal of Moriyoshi calls for the complete abolition of the feature
> >> with no backwards compatibility with existing code that uses PHP as a
> >> template language... including most popular frameworks that sensibly
> >> obey a separation between class files and template files but still use
> >> PHP rather than a dedicated templating language for templates.
> >>
> >> I don't think that's realistic (and neither did the author it
> >> appears). Since PHP's usability as a template language may conceivably
> >> be improved by other proposals, it is undesirable as well even if you
> >> don't currently find PHP to be a suitable template language.
> >>
> >> Please read my proposal over carefully as it does address the obvious
> >> issues that make Moriyoshi's proposal possibly less than serious in
> >> intent (:
> >>
> >> I would oppose a php.ini flag for this as that gives us two
> >> incompatible versions of the current version of the language to worry
> >> about and makes the feature effectively unusable in reusable code.
> >> This approach has created problems before.
> >>
> >> On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki 
> wrote:
> >>> Hi,
> >>>
> >>> There is RFC that is written by Moriyoshi.
> >>> It's not listed in RFC page, though.
> >>>
> >>> https://wiki.php.net/rfc/nophptags
> >>>
> >>> I think these should be merged.
> >>>
> >>> Regards,
> >>>
> >>> --
> >>> Yasuo Ohgaki
> >>> yohg...@ohgaki.net
> >>>
> >>>
> >>>
> >>> 2012/4/9 Yasuo Ohgaki :
>  Hi,
> 
>  Moriyoshi has created same entry on 4/1, but
>  it seems it was deleted  already.
> 
>  Anyway, he had a patch for it.
> 
>  https://gist.github.com/2266652
> 
>  As I mentioned in other thread, we should better to have
>  a switch to disable embed mode for security reasons.
> 
>  Regards,
> 
>  --
>  Yasuo Ohgaki
>  yohg...@ohgaki.net
> 
> 
> 
>  2012/4/9 Tom Boutell :
> > I have written an RFC proposing backwards-compatible support for
> > source files without an opening  >
> > https://wiki.php.net/rfc/source_files_without_opening_tag
> >
> > This RFC is not yet listed at https://wiki.php.net/rfc. I am not
> sure
> > what the requirements are to get it added to the "Under Discussion"
> > session and get the ball rolling formally. Please enlighten and I'll
> > do whatever is required.
> >
> > Thanks!
> >
> > --
> > Tom Boutell
> > P'unk Avenue
> > 215 755 1330
> > punkave.com
> > window.punkave.com
> >
> > --
>

Re: [PHP-DEV] RFC: source files without opening tag

[Kris Craig]

As far as I know, you've already met that req by posting the RFC here, so
go ahead and add it.  In the future, remember there's also an "In Draft"
status for RFCs that haven't been announced here yet.  :)
On Apr 8, 2012 9:32 AM, "Tom Boutell"  wrote:

> I have written an RFC proposing backwards-compatible support for
> source files without an opening 
> https://wiki.php.net/rfc/source_files_without_opening_tag
>
> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
> what the requirements are to get it added to the "Under Discussion"
> session and get the ball rolling formally. Please enlighten and I'll
> do whatever is required.
>
> Thanks!
>
> --
> 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
>
>

Re: [PHP-DEV] Reindl's inappropriate behaviour (Was: Re: [PHP-DEV] PHP class files without

[Kris Craig]

While anything even resembling censorship naturally makes me cringe, it is
a reasonable expectation I think that this list be a place where people can
suggest ideas without being called "stupid" and childishly berated.
Bullying, it could be argued, is also a form of censorship.

So despite my instinctive unease, I think booting this guy was the right
call.  He was just using this list to bully people and I think we sent a
good message by getting rid of him.

Civility and mutual respect FTW!

(Seriously, Droid?!  Not only is it highlighting "FTW" as a misspelling,
but "Droid" as well lol  /tangent)

--Kris
On Apr 7, 2012 8:32 AM, "Rasmus Lerdorf"  wrote:

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

Re: [PHP-DEV] RFC: Removing PHP tags

[Kris Craig]

On Sat, Mar 31, 2012 at 8:38 PM, Xinchen Hui  wrote:

> -_#...
> Nice play ,Moriyoshi sama!
>
> Sent from my iPhone
>
> 在 2012-4-1，11:03，Rasmus Lerdorf  写道：
>
> > On Mar 31, 2012, at 7:45 PM, Moriyoshi Koizumi  wrote:
> >
> >> Ok, I'll try to fix that part. Thanks for the correction.
> 
> 
> >>>
> >>>
> >
> > No problem. Keeping the April 1st RFCs factually accurate is a top
> priority around here.
> >
> > -Rasmus
> > --
> > 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
>
>
Damnit!  I just got April Fools punked for the first time since I was a
kid!  Now how am I supposed to look down my nose at everyone else?!  Thanks
a lot, Moriyoshi.

Though does it count if it's still March 31st over here?  ;)

--Kris

Re: [PHP-DEV] Re: Confusing Windows Users 101...the download page is UNUSABLE.

[Kris Craig]

On Sat, Mar 31, 2012 at 1:54 PM, Yasuo Ohgaki  wrote:

> Hi
>
> 2012/4/1 David Soria Parra :
> > On 2012-03-31, Thomas Hruska  wrote:
> >> I've been writing software for Windows in Visual Studio since forever
> >> and also know user-land PHP like the back of my hand and, even after a
> >> few Google searches, I'm still scratching my head over which PHP Windows
> >> binary download I want to use.  If *I* can't figure out which version is
> >> appropriate, neither can the average web developer.
> >>
> >> Fixing the Windows binary download page so that it is USABLE by the
> >> average user should be priority #1.
> >
> > Thank you for letting us know about the potential problems of the
> > windows download site. Feedback is alwahys appreciated. Why not go
> > ahead and help out? Feel free to fork the windows website on
> > https://github.com/php/web-windows and open a pull request.
> >
> > Thanks
>
> You would probably want to read these to contribute.
>
> https://wiki.php.net/vcs/gitfaq
> https://wiki.php.net/vcs/gitworkflow
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Isn't Apache still building under VC6, or have they finally switched to VC9?

--Kris

Re: [PHP-DEV] git merge and generated files?

[Kris Craig]

Pierre,

On Tue, Mar 27, 2012 at 5:43 PM, Stas Malyshev wrote:

> Hi!
>
> >> Why would these change every 2nd commit? These only should change when
> >> you change the scanner, which happens very rarely.
> >
> > It depends what you do, but still annoying when it happens.
> >
> > But that does not answer the question...
>
> Looking at the patch, it looks like yours and git's line endings did not
> match, which may have caused the conflict.


Stas is right.  Looks like the Windows CR line endings are causing it to
puke on ya.  I'm assuming you're working in Windows, right?  What Git
client are you using?

If you're using Msysgit, it automatically converts these line endings for
you specifically to avoid this problem, but you have to select that option
during the installation process when it prompts you.  I don't know if the
setting can be changed after install; my guess would be it can, but I have
no idea how.  The easiest thing to do would be to just re-run the Msysgit
installer (if that's what you're using) and when prompted select the option
to auto-convert line endings (i.e. I think the option is something along
the lines of "Use Unix-Style line endings").

--Kris



> I think it'd be also the best
> to resolve such conflicts by leaving the files as-is, maybe just by
> using git reset or using git mergetool and choosing the "old" variant.
> Depending on the system mergetool would use different tools so I'm not
> sure which one would be best on yours. I usually just use mergetool,
> mark every change to resolve to "old" variant and that cleans up the
> commit.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Adopt GitFlow process

[Kris Craig]

On Mon, Mar 26, 2012 at 12:03 PM, Alexey Shein  wrote:

> 26 марта 2012 г. 4:30 пользователь Stas Malyshev
>  написал:
> > Hi!
> >
> >> Main problem is that our current workflow doesn't allow branch-only
> >> changes. I.e. if you make a bugfix and want to stay it in PHP-5.3 only
> >> you can't merge 5.3 with 5.4 anymore, otherwise your bugfix will go
> >> there.
> >
> > Why would you want a bugfix to be in 5.3 but not in 5.4? Can you give an
> > example?
> > I can see it if the code had substantial change there so bugfix no
> > longer applies. In this case, I would try the merge, see it fail and
> > resolve it as "all ours". It shouldn't take longer than 10 mins. Though
> > it you have ideas how to improve that without disrupting the rest of the
> > process and the common use case, you are welcome.
>
> For example this commit
>
> http://git.php.net/?p=php-src.git;a=commit;h=8d0760f38a9d3dabb3a31d1d47f85827d27d0db4
> by Ilia was intentionally commited in PHP-5.3 only, maybe Ilia will
> describe better. It was then accidentally merged into PHP-5.4 by
> Hannes (which broke something in PHP-5.4) when he was merging his own
> changes which merge made a lot of confusion.
>
> We should really deal with this problem first before diving further,
> since it will have great impact on the whole working process with git.
> If we can live with simple git merge - it would be simply awesome.
>
> >> 1) use cherry-picking in one repo. This has big downside (as dsp
> >> pointed) that we can't use git annotate, bisect and other commands
> >> assuming that commit is introduced in repository only once.
> >
> > bisect is a bit weird now btw, since it seems to be a bit confused by
> > 5.3-5.4 merge that happened not when it thinks it did - so if you try to
> > bisect changes in 5.4 branch only, you will get some very old changes
> > in. You can quickly go through that, marking them as good, but still not
> > ideal situation.
>
> Yep, already tried bisect and it doesn't seem work good at least for
> php-5.3 branch.
>
> >> Okay, since I'm not too familiar with release process, assume
> >> following (please, correct me if I'm wrong):
> >> * PHP 5.3 can't have features, only bugfixes
> >
> > True.
> >
> >> * PHP 5.3 can have bugfixes that are merged upstream (PHP-5.4 and
> >> master) and bugfixes that should stay only in PHP-5.3
> >
> > Not entirely true - 5.3 code can have bugfixes that aren't merged up,
> > but that would not be the common case. Example - bugfix regarding magic
> > quotes or safe mode, which are not in 5.4.
>
> So it's still possible to have not-merged up bugfixes. That means that
> we should take that into account.
> I'm just trying to figure out our needs to better understand what
> needs to be done then.
>
> >
> >> * PHP-5.4 and master can have bugfixes and features that are merged
> >> upstream (master) and bugfixes/features that should stay only in
> >> current branch
> >
> > 5.4-only fixes very unlikely, as master and 5.4 are very close today. If
> > we ever do big changes in master this is a possibility, as described
> > above, but still won't be a common case - unless we rewrite our engine
> > completely, which doesn't seem to be likely.
> >
> >> * All branches are have regular releases
> >
> > True, except for master.
> >
> >> In gitflow you have 4 branches:
> >> * master - contains only production ready releases, nobody commits here
> directly
> >> * develop - main development branch, all work usually is get merged here
> >> * feature/ - feature/bugfix branches for separate bugfixes and
> >> features. Merged into develop.
> >> * hotfix/ - same that feature branches but is urgent and is
> >> always merged into master *and* develop. For example, when security
> >> release is issued, this fix should go into release and into main
> >> development branch.
> >> * release/ - pre-release stability branches, for bug-fixes only.
> >> Merged into develop and master (making a new release). When you have a
> >> release branch, you can't commit into develop (so hotfixes go here
> >> too, if we have release branch).
> >
> > I don't like that "can't commit into" thing - the main advantage of git
> > as I see it that you can manage release branch and dev/stable branches
> > separately and not have the situation of asking people to sit on their
> > code for 2 months while release is being stabilized.
>
> Sorry, I messed this up. You actually can commit into the develop, new
> features go there, while bugfixes should go in release branch. If you
> want you can merge release branch into develop anytime you want, it's
> just should be done at least once when release branch is closed.
>
> >> Make a bugfix in 5.3
> >> $ git flow feature start bugfix PHP-5.3 # create a bugfix branch based
> on 5.3
> >> $ git flow feature finish -k bugfix 5.3-develop
> >> Bugfix get merged into 5.3-develop - this should be implemented since
> >> gitflow supports only 1 develop branch for now. -k says to keep branch
> >> after finish, since we'll 

Re: [PHP-DEV] Adopt GitFlow process

[Kris Craig]

On Sun, Mar 25, 2012 at 2:04 PM, Stas Malyshev wrote:

> Hi!
>
> > There was a discussion recently on IRC that our current git working
> > process is not perfect (especially about keeping one branch-only
> > bugfixes) so that's a
>
> One thing with discussions on IRC is that nobody except those present
> there can neither participate nor know what was talked about. And since
> we have timezone differences and other stuff going on in our lives, that
> means, on my estimate, a substantial percentage of the people here
> wouldn't know anything about what was discussed. Thus, it would be
> useful to explain what exactly is the problem we are talking about.
>

+1


>
> > If you're not yet familiar what is that, please read
> > his wonderful article
> http://nvie.com/posts/a-successful-git-branching-model/
> > another wonderful article about the gitflow tool
> > http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
>
> This is a nice process, however I'm not sure how it could apply to PHP.
> Could you outline what will be done in this case when we have:
> 1. A bugfix for 5.3
> 2. A bugfix for 5.4
> 3. A feature addition for 5.4
> 4. A release of 5.3.x
> 5. A release of 5.4.x
> 6. A release of 5.5 and 5.5.x
>
> Also, what would happen if bugfix/feature is contributed via github pull?
>

I'm also a strong proponent of NVIE's branching model.  We'd probably have
to modify it to suit PHP's exact needs, but in principle I very much
advocate it as it actually takes full advantage of Git's branching
strengths over Subversion.


> > Personally, I see migration from current setup that way so each
> > release branch (PHP-5.3, PHP-5.4 and master) becomes a separate
> > repository with adopted gitflow model (although it should be thought
> > through more carefully).
> > What do you think about that?
>
> I do not think it makes sense to keep the code in separate repos, given
> that about 90% of the code is the same. It also will make much harder to
> accept outside contribution - I'm not sure how easy would it be to merge
> a patch into three repos from one pull req.
>

Agreed.  Breaking PHP into separate repos would carry a lot of implications
that make me uneasy.  Instead, I think it would be better to modify the
NVIE workflow model to "bridge" the two branches (basically, it would be
like linking 2 "develop" and 2 "master" branches somehow) in parallel on
the same repo.

--
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Github Pull Request

[Kris Craig]

Arpad,

On Tue, Mar 20, 2012 at 6:23 PM, Arpad Ray  wrote:

> Hi Kris,
>
> On 20 Mar 2012 23:29, "Kris Craig"  wrote:
> >
> > On Tue, Mar 20, 2012 at 4:08 PM, Ferenc Kovacs  wrote:
> > >
> > >> But just because you and a few other stuffed shirts don't understand
> the
> > >> value of dissenting viewpoints,
> > >
> > >
> > > that's so nice of you
> > >
> >
> > You're welcome.
> >
>
> Your tone and argumentative style in recent posts is really not helpful to
> your cause.
>
> Please try to keep discussions on this list civil and technical.
>
> Often emotion and other biases do appear. It's much better to ignore them
> and keep focused on the true issues, than to address them - no matter how
> calmly worded or light-hearted your response may be.
>
> I.E. Let's have a technical debate not a pissing contest ;)
>
> Regards,
>
> Arpad
>
You're absolutely right.  Generally speaking, when somebody delivers a
witlessly sarcastic remark like, "that's so nice of you," or, "thank you
for being a dick," my default reply is, "You're welcome."  It falls under
the principle of beating them at their own game; fighting fire with fire,
as it were.

But you're correct in that I need to be careful not to allow my zeal for
putting bullies in their place go too far and start annoying people who
don't actually deserve to be annoyed.  It's a delicate balance and letting
emotion into the equation really doesn't help.  I'll try to be more mindful
of that.


He definitely had that, "you're welcome," response coming to him after his
sardonic little jab, but that alone doesn't mean it was necessary.  I allow
myself to be a bit hypersensitive when I perceive an environment where
people with dissenting views are being bullied into silence, which I
believe for some time now has been the case on this list.  I.e. I hit back
to set an example and level the playing field a little.  But even so,
sometimes I get a bit carried away.  I probably could have safely ignored
some of Ferenc's juvenile remarks while still sufficiently pushing back
against this latest anti-dissent gangbang.

Thanks for the reminder!  If it ever looks like I'm getting carried away
while standing up to these guys, please don't be afraid to let me know.  =)

--Kris

Re: [PHP-DEV] Github Pull Request

[Kris Craig]

On Tue, Mar 20, 2012 at 4:08 PM, Ferenc Kovacs  wrote:

>
>> The horse is already dead.  Why are you still wacking it with a stick?
>>
>
> that was my first and only reply to you about this issue, and this will be
> my last one, I promise.
>

I was referring to you guys piling on as a group.  Try not to take it so
personally.


>
>
>> Last time I checked, the PHP Group doesn't take orders from Github.
>
>
> we don't, my point was that if you really want to fix that terminology
> "issue", it would make more sense to complain at the source.
> as you have seen and said yourself, most people around here are familiar
> with the term, so there is no confusion to be fixed here.
>

It's not a question of awareness.  It's just an ill-thought term to begin
with.  It's inaccurate and vague.  I'm trying to make things as easy as
possible for Subversion folks switching over to Git without too much
confusion.  At very least, the "noise" from this little thread should
mitigate that.

Perhaps it was wrong of me to think that we should actually take the lead
and set a good example on something that needs to be fixed.  Oh well.


>
>
>>   We have the power to use whatever internal terminology we damn well
>> please with or without their permission.
>
>
> sure, you can, as github also had that option, and it seems that their
> terminology got more traction than yours.
>

You're just regurgitating what I've already said ad nauseum.  But again,
the majority view isn't always the right view.  You should try to be
mindful of that when evaluating new ideas.


>
>
>>   But again, why do you insist on resurrecting this dead discussion??
>
>
> that's redundant, see above.
>

Of course it is.  Like I said, everything has already been said.  That
breeds redundancy.  Stop bringing up the same points and the redundancy
will cease lol.


>
>
>
>> I've already acknowledged repeatedly that I'm in the minority on this
>> one.
>
>
> yeah, and in this very same mail you still questioning why should we use
> the generally accepted term, so?
>

That's right.  You don't seem to understand the difference between
deference and conformance.  I deferred to the majority opinion since
there's really no point in trying to jam my view down other people's
throats, but that does not mean that I decided to conform my views to match
yours.  I've made it clear that, while my opinion has not changed, I've
decided this one just isn't worth fighting over.  Of course, the irony is
that you guys are prolonging this fight needlessly by continuing to pile on
with stuff that has already been said.


>
>
>> But just because you and a few other stuffed shirts don't understand the
>> value of dissenting viewpoints,
>
>
> that's so nice of you
>

You're welcome.


>
>
>> that doesn't mean that said dissent amounts to "noise."
>
>
> your mail didn't really added anything valuable, got called out as noise,
> it happens.
>

In your opinion.  But just because something has no value for you doesn't
mean that it has no value period.  That's the sort of arrogant posturing
that causes these flamewars to begin with.  One would think you guys who
engage in this behavior would have learned from that by now.


>
>
>> Maybe some people here aren't accustomed to having their edicts
>> challenged.
>
>
> nah, thanks to you and a few other folks those people are constantly
> practicing to endure that.
>

Keep practicing.


>
>
>>   Either way, I've noticed a consistent pattern of dissenting views being
>> clamped-down and summarily dismissed in the same manner; that is, in part,
>> what prompted me to become more active on here to begin with.  I.e. because
>> I'm accustomed to dealing with a tough room.  I'm a liberal intellectual in
>> the U.S., so being in the oft-dismissed and shouted-down minority is
>> something I am very much used to.  =)
>>
>
> the idea never occured to you that maybe there is some connection between
> your attitude and those "tough rooms" and "stuffed shirts" that you see
> everywhere?
>

Lol have you ever visited the U.S.?  I've had roomfuls of people scream
bloody murder (literally) for daring to suggest that an egg that was just
penetrated by a sperm cell is not equivalent to a human baby.  I've had
people call me a terrorist sympathizer for suggesting that the proposed
invasion of Iraq might not be such a good idea (and boy was I wrong lol!).
I've gotten into shouting matches trying to explain to protesters why their
signs that said, "Keep your government hands off my Medicare!" made no
sense.

Again, you seem to be embracing the logical fallacy that, if the majority
is hostile to your views, then your views must be wrong.


>
>
>>
>> But seriously, the discussion on the terminology has already ended.
>> Everything has been said.  I don't like the choice that the majority has
>> made but I'll just have to live with it.
>
>
> hurray
>

You're really slow on the uptake, considering I'd already said that several
times lol.


>
>
>>   I made my suggestion, prese

Re: [PHP-DEV] Github Pull Request

[Kris Craig]

On Tue, Mar 20, 2012 at 3:04 PM, Ferenc Kovacs  wrote:

>
>
> On Tue, Mar 20, 2012 at 9:14 PM, Kris Craig  wrote:
>
>> On Tue, Mar 20, 2012 at 12:56 PM, Stas Malyshev > >wrote:
>>
>> > Hi!
>> >
>> > > Yeah I know.  That doesn't mean I have to like it though lol.  ;P
>> >
>> > You may like it or not like it, but it's established terminology so
>> > we're going to use it. Let's not add noise to our lists.
>> > --
>> > Stanislav Malyshev, Software Architect
>> > SugarCRM: http://www.sugarcrm.com/
>> > (408)454-6900 ext. 227
>> >
>>
>> If we don't critically re-examine "established" ideas now and then, who
>> will?
>
>
> please go with that problem to github, we didn't coined that term, so we
> can't really fix it for you.
>
>
>>  You can disagree with me, but please don't belittle other people's
>> concerns by dismissing them as "noise."
>
>
> it is noise on this mailing list, as this isn't the place to fix that
> term, even if you are right.
>
>
>>  I raised a legitimate concern that
>> was not "unworthy" of discussion.  Just because I hold a minority
>> viewpoint
>> doesn't make it any less valid and I stand by my posts.  Ironically, your
>> dismissive comment after the fact only increased the "noise" factor by at
>> least two more posts.
>>
>
> the thing is that it wasn't your first or second post which regulars would
> count as noise, so this time somebody mentioned that you shouldn't do that.
>
>
>>
>> I believe that the majority, including Github, is wrong on this.
>
>
> yeah, but how can you fix that with lecturing people here?
>
>
>>  That term
>> is needlessly confusing in my opinion.  I made that point and it didn't
>> gain any traction, so like I said I'll just have to suck it up and move
>> on.  But if you're going to jump in with a, "We're gonna do it this way so
>> shut up," then all that's going to do is create animosity and drag this
>> out
>> since obviously I"m not about to let such a comment go unchallenged.  ;P
>>
>
> sigh.
>
>
>>
>> If you want to keep beating this dead horse, I'm game.  Otherwise, all the
>> arguments have already been made so just let it go.  I voiced my concern
>> and the majority doesn't share it, so that's that.  Time to move on.
>>
>
> \o/
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>

The horse is already dead.  Why are you still wacking it with a stick?

Last time I checked, the PHP Group doesn't take orders from Github.  We
have the power to use whatever internal terminology we damn well please
with or without their permission.  But again, why do you insist on
resurrecting this dead discussion??  I've already acknowledged repeatedly
that I'm in the minority on this one.  But just because you and a few other
stuffed shirts don't understand the value of dissenting viewpoints, that
doesn't mean that said dissent amounts to "noise."  Maybe some people here
aren't accustomed to having their edicts challenged.  Either way, I've
noticed a consistent pattern of dissenting views being clamped-down and
summarily dismissed in the same manner; that is, in part, what prompted me
to become more active on here to begin with.  I.e. because I'm accustomed
to dealing with a tough room.  I'm a liberal intellectual in the U.S., so
being in the oft-dismissed and shouted-down minority is something I am very
much used to.  =)

But seriously, the discussion on the terminology has already ended.
Everything has been said.  I don't like the choice that the majority has
made but I'll just have to live with it.  I made my suggestion, presented
my argument, and this time it just didn't have legs.  You win some, you
lose some; I'm ok with that.  I still believe a more accurate term would be
better but I've already moved on.  It's time for you to do the same and let
it go.  You're not accomplishing anything by continuing to drag this out.
Let the dead horse rest in peace.

--Kris

Re: [PHP-DEV] Github Pull Request

[Kris Craig]

On Tue, Mar 20, 2012 at 12:56 PM, Stas Malyshev wrote:

> Hi!
>
> > Yeah I know.  That doesn't mean I have to like it though lol.  ;P
>
> You may like it or not like it, but it's established terminology so
> we're going to use it. Let's not add noise to our lists.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

If we don't critically re-examine "established" ideas now and then, who
will?  You can disagree with me, but please don't belittle other people's
concerns by dismissing them as "noise."  I raised a legitimate concern that
was not "unworthy" of discussion.  Just because I hold a minority viewpoint
doesn't make it any less valid and I stand by my posts.  Ironically, your
dismissive comment after the fact only increased the "noise" factor by at
least two more posts.

I believe that the majority, including Github, is wrong on this.  That term
is needlessly confusing in my opinion.  I made that point and it didn't
gain any traction, so like I said I'll just have to suck it up and move
on.  But if you're going to jump in with a, "We're gonna do it this way so
shut up," then all that's going to do is create animosity and drag this out
since obviously I"m not about to let such a comment go unchallenged.  ;P

If you want to keep beating this dead horse, I'm game.  Otherwise, all the
arguments have already been made so just let it go.  I voiced my concern
and the majority doesn't share it, so that's that.  Time to move on.

--Kris

Re: [PHP-DEV] Github Pull Request

[Kris Craig]

Yeah I know.  That doesn't mean I have to like it though lol.  ;P

--Kris


On Tue, Mar 20, 2012 at 12:11 PM, Hugo Peixoto wrote:

> Kris,
>
> "Pull request" is a generally accepted term, specially when it comes to
> github: http://help.github.com/send-pull-requests/
>
> Hugo Peixoto
> --
>
> website: http://hugopeixoto.net
>
>
>
> On Tue, Mar 20, 2012 at 7:06 PM, Kris Craig  wrote:
>
>> On Tue, Mar 20, 2012 at 10:34 AM, David Soria Parra 
>> wrote:
>>
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA1
>> >
>> > On 03/20/2012 06:29 PM, Kris Craig wrote:
>> > > Quick clarification: On the other hand, by "pull request" are you
>> > > simply referring to somebody else requesting that you "pull" their
>> > > submission and merge/push it?  If so, I get it, but I really think
>> > > we should come up with another term to describe it because it
>> > > really does sound kinda backwards IMHO.  I just woke up less than
>> > > an hour ago though so maybe I'm just groggy lol
>> >
>> > Drink a coffee wake up, think first and write the mail then and help
>> > reducing mailinglist noise by trying to figure it out yourself.
>> >
>> > We are referring to pull requests in the sense of pulling stuff from
>> > another repository into ours. We talk about pull requests made on
>> > github for the php/php-src repository. We use pull request the same
>> > way everyone else uses. Someone requests via github or a pull request
>> > mail (linux style) to pull his changes and merge them into our
>> repository.
>> > -BEGIN PGP SIGNATURE-
>> > Version: GnuPG v1.4.12 (GNU/Linux)
>> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>> >
>> > iQIcBAEBAgAGBQJPaL+6AAoJEAT0aMuPE7Z1QUEP/0eHx5TWk3EI2Y7RZPoBPZlT
>> > 2/uxGtc0ofAu2Tk+xEt0Avhbxoy9+gwlsXsDZK2aTYd3lfHoHQJ9YJfcsbIH7vWi
>> > n08N0zI3uqeETyo/8W07KDIch6UGfEQaCgMDTDsAvIIJ7wLRCIYVuJEbAELdY1Xq
>> > egBOBxSuEFie2k4P0GPnw92P0vf5orvMRwnIrIks26/OnxEpBlvC/bR2JQbfbHSy
>> > qgJRP9KFV/rx8myvWPXhI6soNx1W8cuIiPgZY3ljslSjXJP5xiB88xzHIdnGk9KH
>> > 5q1H2XEZRt9TtLnOv0fxhvfgdPgxG2nD0UMo1Ucm/MJcDDaRA+hvlKpjNhAAx5qC
>> > K4+Jtt4er0Q9D3lZW+vYY4lfpmADrTIN2UylFqm/9K1Tyn3t3aZPo1R9xxLH9mtX
>> > JYRrZ2PZSWLdhQfZrPkJlVjkTZUCded/fEgr/3N4qjgoV+Yta4pw+XT1ccV8wMnG
>> > tUy2RBaZloIsRObQ/JUps1SURYjDLAku+1eaPKeCcgkJnhF7fDgm6BJyfqqXg9c6
>> > ci/Pg0K69UtzbLNpThZefU6WHCHdUUZKU8/cea4NX1vnpzW1orsTxbFLtxfYlxUq
>> > eNTBQPeD7x0IGktF1uy5v+RGlpAEQQDgwEil3ovtjoNQ+XoAvDxeKtmhKzw0YmVF
>> > vltnqeQggRED7abRzXxR
>> > =W89T
>> > -END PGP SIGNATURE-
>> >
>>
>> Yeah I get that.  It just feels imprecise to me.  Wouldn't "external merge
>> request" be more descriptive?  Generally, a pull request refers to a pull
>> from a remote repository.  While that's an initial component of this, the
>> fact that it ends with a push request just makes the terminology
>> needlessly
>> confusing IMHO.  But if nobody else is bothered by it then I guess I'll
>> just have to suck it up lol.
>>
>> --Kris
>>
>> P.S. I don't drink coffee.  Never been able to develop a taste for it.
>> That's really sad seeing as how I live in Seattle
>>
>
>

Re: [PHP-DEV] Github Pull Request

[Kris Craig]

On Tue, Mar 20, 2012 at 10:34 AM, David Soria Parra  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/20/2012 06:29 PM, Kris Craig wrote:
> > Quick clarification: On the other hand, by "pull request" are you
> > simply referring to somebody else requesting that you "pull" their
> > submission and merge/push it?  If so, I get it, but I really think
> > we should come up with another term to describe it because it
> > really does sound kinda backwards IMHO.  I just woke up less than
> > an hour ago though so maybe I'm just groggy lol
>
> Drink a coffee wake up, think first and write the mail then and help
> reducing mailinglist noise by trying to figure it out yourself.
>
> We are referring to pull requests in the sense of pulling stuff from
> another repository into ours. We talk about pull requests made on
> github for the php/php-src repository. We use pull request the same
> way everyone else uses. Someone requests via github or a pull request
> mail (linux style) to pull his changes and merge them into our repository.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJPaL+6AAoJEAT0aMuPE7Z1QUEP/0eHx5TWk3EI2Y7RZPoBPZlT
> 2/uxGtc0ofAu2Tk+xEt0Avhbxoy9+gwlsXsDZK2aTYd3lfHoHQJ9YJfcsbIH7vWi
> n08N0zI3uqeETyo/8W07KDIch6UGfEQaCgMDTDsAvIIJ7wLRCIYVuJEbAELdY1Xq
> egBOBxSuEFie2k4P0GPnw92P0vf5orvMRwnIrIks26/OnxEpBlvC/bR2JQbfbHSy
> qgJRP9KFV/rx8myvWPXhI6soNx1W8cuIiPgZY3ljslSjXJP5xiB88xzHIdnGk9KH
> 5q1H2XEZRt9TtLnOv0fxhvfgdPgxG2nD0UMo1Ucm/MJcDDaRA+hvlKpjNhAAx5qC
> K4+Jtt4er0Q9D3lZW+vYY4lfpmADrTIN2UylFqm/9K1Tyn3t3aZPo1R9xxLH9mtX
> JYRrZ2PZSWLdhQfZrPkJlVjkTZUCded/fEgr/3N4qjgoV+Yta4pw+XT1ccV8wMnG
> tUy2RBaZloIsRObQ/JUps1SURYjDLAku+1eaPKeCcgkJnhF7fDgm6BJyfqqXg9c6
> ci/Pg0K69UtzbLNpThZefU6WHCHdUUZKU8/cea4NX1vnpzW1orsTxbFLtxfYlxUq
> eNTBQPeD7x0IGktF1uy5v+RGlpAEQQDgwEil3ovtjoNQ+XoAvDxeKtmhKzw0YmVF
> vltnqeQggRED7abRzXxR
> =W89T
> -END PGP SIGNATURE-
>

Yeah I get that.  It just feels imprecise to me.  Wouldn't "external merge
request" be more descriptive?  Generally, a pull request refers to a pull
from a remote repository.  While that's an initial component of this, the
fact that it ends with a push request just makes the terminology needlessly
confusing IMHO.  But if nobody else is bothered by it then I guess I'll
just have to suck it up lol.

--Kris

P.S. I don't drink coffee.  Never been able to develop a taste for it.
That's really sad seeing as how I live in Seattle

Re: [PHP-DEV] Github Pull Request

[Kris Craig]

Quick clarification:

On Tue, Mar 20, 2012 at 7:11 AM, Paul Dragoonis  wrote:

> thanks dsp and johannes for this nice tool.
>
> On Tue, Mar 20, 2012 at 10:16 AM, David Soria Parra  wrote:
> > Hi
> >
> > with the php-src migrated to git we start receiving
> > pull request on github. A few things to notice:
> >
> >  - developers can pull the requests as described here:
> >https://wiki.php.net/vcs/gitfaq#github_pull_requests
> >  - people with valid github accounts can comment
> >on pull request
> >  - people with valid php accounts can close pull
> >request using the tool http://qa.php.net/pulls.
> >Thank you joahnnes for writing it.
> >
> > Before pulling make sure:
> >
> >  - the pull request contains appropriate tests for
> >the change
> >  - the commit message contains a good and precise
> >description what was changed and why
> >
> > ensure that you pull it into the right branch.
> >
> > Pull request notifications are send to the
> > git-pu...@lists.php.net mailinglist.
> >
> > Note that we DONT hand out access to the
> > github repository and will we not add
> > you to the PHP organization on github.
> >
> >  - David
> >
> > --
> > 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
>
>
Are you referring to "push" requests?  I.e. are you talking about posting
commits you've made locally to the remote Git repo?  If so, then in Git
this is referred to as a "push," not a "pull."  I bring this up because, in
Git, a "pull" actually refers to something entirely different.  A pull
refers to the exact opposite, in fact; i.e. using Git to "download" a
branch from a remote repo.  In other words, you "pull" a branch from remote
to local, make your commits/merges/whatever, then "push" that branch back
up to the remote repo.  If we start referring to pushes as pulls, that will
inevitably lead to a ton of unnecessary confusion.

On the other hand, by "pull request" are you simply referring to somebody
else requesting that you "pull" their submission and merge/push it?  If so,
I get it, but I really think we should come up with another term to
describe it because it really does sound kinda backwards IMHO.  I just woke
up less than an hour ago though so maybe I'm just groggy lol

--Kris

Re: [PHP-DEV] php-src is now on git

[Kris Craig]

On Mon, Mar 19, 2012 at 4:03 PM, Ferenc Kovacs  wrote:

>
>> Specifically, I noticed the "SSH Key" field in user administration (is
>> that
>> new or was that always there?).
>
>
> https://wiki.php.net/vcs/gitfaq#using_ssh
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>

Lol yep that's where I found it!  What I'm asking though is whether this
should be the *recommended* approach on the workflow page.  I.e. are there
any potential problems with having too many people using the SSH login at
once, for example?

--Kris

Re: [PHP-DEV] php-src is now on git

[Kris Craig]

Question:

On Mon, Mar 19, 2012 at 2:01 PM, Kris Craig  wrote:

>
>
> On Mon, Mar 19, 2012 at 1:39 PM, Christopher Jones <
> christopher.jo...@oracle.com> wrote:
>
>>
>>
>> On 03/19/2012 01:31 PM, Kris Craig wrote:
>>
>>>  I added an entry to the FAQ about the merge.ff option
>>> available in newer clients.
>>>
>>
>> Would it be more visible if that comment was moved to the Recommended Git
>> Settings section?
>>
>>
>> Chris
>>
>> --
>> Email: christopher.jo...@oracle.com
>> Tel:  +1 650 506 8630
>> Blog:  http://blogs.oracle.com/opal/
>>
>>
> Hmm good idea, I'll move it there and mention the client version
> requirement (tnx for looking that up, Gábor!).
>
> --Kris
>
>
Regarding the recommended method for using git clone, after a little
tinkering I realized that I do, in fact, have SSH access for Git-- Or, to
be more precise, I didn't have access but I had the ability to make it so
that I did.

Specifically, I noticed the "SSH Key" field in user administration (is that
new or was that always there?).  By using ssh-keygen and adding the
newly-generated public key to that field in my php.net user account, I was
able to successfully perform a git clone using g...@git.php.net:php-src.git.

So here's my question:  Assuming everyone with SVN karma can do this as
well, is there any cost that would make it undesirable for us to recommend
wide use of this?  I.e. I remember somebody mentioning something about
limited SSH ports available.  Could you elaborate on that?

If it is doable, then I'd recommend scrapping my previous suggestion and
going with the SSH option (though still mentioning the https one as an
lighter-weight alternative) and also adding a brief section on how to
configure add/configure the necessary keys to make it work.  Again I'm more
than happy to do the heavy lifting on actually updating the docs; I just
want to make sure we're all on the same page before I do.


Thanks!  =)

--Kris

Re: [PHP-DEV] php-src is now on git

[Kris Craig]

On Mon, Mar 19, 2012 at 3:07 PM, Christopher Jones <
christopher.jo...@oracle.com> wrote:

>
>
> On 03/19/2012 01:31 PM, Kris Craig wrote:
>
>> Here's what I wound-up doing: The merge entries on the workflow page now
>> contain "--no-ff" and I added an entry to the FAQ about the merge.ff option
>> available in newer clients. This way we should be covered either way. =)
>> --Kris
>>
>
> Is this supported by the php-src repo?  This is what I get after using
> --no-ff:
>
> $ git push origin
> To 
> https://git.php.net/**repository/php-src.git<https://git.php.net/repository/php-src.git>
>  ! [rejected]PHP-5.3 -> PHP-5.3 (non-fast-forward)
>  ! [rejected]PHP-5.4 -> PHP-5.4 (non-fast-forward)
>  ! [rejected]master -> master (non-fast-forward)
> error: failed to push some refs to 'https://git.php.net/**
> repository/php-src.git <https://git.php.net/repository/php-src.git>'
> To prevent you from losing history, non-fast-forward updates were rejected
> Merge the remote changes (e.g. 'git pull') before pushing again.  See the
> 'Note about fast-forwards' section of 'git push --help' for details.
>
>
> --
> Email: christopher.jo...@oracle.com
> Tel:  +1 650 506 8630
> Blog:  http://blogs.oracle.com/opal/
>
>
That error can sometimes be misleading.  I've noticed that it typically
happens if you're trying to push a branch containing merged commits to a
remote version of that branch that is newer than the one your commits were
merged into (i.e. you forgot to do a git pull followed by a git rebase
before doing the merge).  I can't say for certain but that's a likely
possibility that that's what happened in your case.

Moving forward, we should probably add that to the workflow as it can save
a lot of headaches moving forward.  Specifically, when merging in a branch:


   1. git checkout 
   2. git pull [destination branch]
   3. git checkout 
   4. git rebase 
   5. git checkout 
   6. git merge --no-ff 
   7. git push origin [destination branch]
   8. git branch -d 

What often happens is that you'll pull a branch then start working on a
feature branch.  However, while you're doing that, somebody else pushes a
newer version of the branch you pulled.  If you then merge into the older
"revision" of that branch without first making sure it's up-to-date,
everything will blow up in your face when you try to do a push.  Despite
the migraines this tends to cause, it's actually a good thing that it does
this.  After all, we don't *want* an older version of a branch being dumped
on top of a newer version.  That would get very ugly lol.  The only
downside is that the resulting error message when using --no-ff is
needlessly confusing for newcomers.

Assuming that's what happened in your case, you've got some damage control
to do.  Whenever I'm training people in the office on using Git and they
make this inevitable mistake, I always tell them to think of the damage
control as good practice lol.  =)

Anyway, assuming you haven't yet deleted the original feature branch, this
will be really easy:


   1. git checkout -b  
  - Creates a backup copy of the outdated branch with the merges.
   2. git branch -D 
  - Deletes the corrupted branch.  Note that uppercase "-D" is required
  since this is considered an "unsafe" delete.
   3. git checkout -b  origin/
  - Re-creates the branch you just deleted, this time just grabbing the
  one currently on the remote origin.
   4. git checkout 
  - Checkout the feature branch that you originally merged into the
  develop branch.
   5. git rebase 
  - Your feature branch will now be based off of the current develop
  branch that you just pulled from the remote origin.
   6. git checkout 
   7. git merge --no-ff 
  - Merge the newly-rebased feature branch into this branch.
   8. git push origin [corrupted branch name]
  - Now your push should be successful.


I hope that helps!  =)

--Kris

Re: [PHP-DEV] php-src is now on git

[Kris Craig]

On Mon, Mar 19, 2012 at 1:39 PM, Christopher Jones <
christopher.jo...@oracle.com> wrote:

>
>
> On 03/19/2012 01:31 PM, Kris Craig wrote:
>
>>  I added an entry to the FAQ about the merge.ff option
>> available in newer clients.
>>
>
> Would it be more visible if that comment was moved to the Recommended Git
> Settings section?
>
>
> Chris
>
> --
> Email: christopher.jo...@oracle.com
> Tel:  +1 650 506 8630
> Blog:  http://blogs.oracle.com/opal/
>
>
Hmm good idea, I'll move it there and mention the client version
requirement (tnx for looking that up, Gábor!).

--Kris

Re: [PHP-DEV] php-src is now on git

[Kris Craig]

On Mon, Mar 19, 2012 at 1:16 PM, Simon Schick
wrote:

> 2012/3/19 Kris Craig :
> > Simon,
> >
> > Yes that's a great recommendation and it should definitely be included
> > IMHO!  However, the merge.ff option is relatively new and is not
> available
> > in many older Git clients that are still in use.  So the --no-ff tag will
> > still probably be necessary for some people.  Perhaps we should recommend
> > both, or would that make things too confusing?
> >
> > --Kris
> >
>
> Hi, Kris
>
> Don't really know ... Do you know which version of GIT is the first
> who implements this feature? Would it be a problem to require an
> update or the people should find their own solution?
> I think that people who don't know much about GIT or are just starting
> with GIT should be fine with that as they haven't done much with that
> or just installed the latest version.
> The only problem I can see here is that some linux-distributions
> (Debian for example) tends to keep old versions in their repositories
> ;) Anyways ...
> I think it would be max-information to link the
> stackoverflow-discussion there if someone has a question to that. But
> this (of course) has to be describe it in a easy understandable way :)
> and I think that's the most dificult part.
>
> Bye
> Simon
>

I don't know off the top of my head which version it was implemented in,
but I'm pretty sure it was relatively recent.

Here's what I wound-up doing:  The merge entries on the workflow page now
contain "--no-ff" and I added an entry to the FAQ about the merge.ff option
available in newer clients.  This way we should be covered either way.  =)

--Kris

Re: [PHP-DEV] php-src is now on git

[Kris Craig]

FYI-

On Mon, Mar 19, 2012 at 8:24 AM, David Soria Parra  wrote:

> Hi Internals,
>
> The initial migration is done and initial testing was successful.
>
>  http://git.php.net/?p=php-src.git;a=summary
>  http://github.com/php/php-src
>
> Please note that some branches and tags were renamed to make
> the repository cleaner.
>
> Please checkout the repository and play around. I have created
> a workflow wiki page at https://wiki.php.net/vcs/gitworkflow.
> There is also an FAQ at https://wiki.php.net/vcs/gitfaq.
>
> If you have questions about the workflow or problems let me know.
> General git questions should be asked in the appropriate IRC channels
> and mailinglists.
>
> David
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
If you don't already have Git installed on your system and aren't sure
how/where to get it, I added a list on the FAQ for all major operating
systems.

--Kris

Re: [PHP-DEV] php-src is now on git

[Kris Craig]

Simon,

On Mon, Mar 19, 2012 at 11:55 AM, Simon Schick
wrote:

> 2012/3/19 Kris Craig :
> > Hey,
> >
> > Could we modify the workflow to recommend using the "--no-ff" switch when
> > merging in a feature branch?  This is by and large the recommended
> approach
> > as it preserves the feature branch's commit history, making it
> > *much*easier to sort through complex features that contain numerous
> > commits.
> >
> > --Kris
>
> Hi, Kris
>
> I'd instead suggest to execute the following command in the git-repository:
>
> git config --add merge.ff false
>
> Then you do not have to add --no-ff to every merge-command you're doing.
>
> You could even set it per branch if you want :) (just to round it up ..)
>
> http://stackoverflow.com/questions/2500296/can-i-make-fast-forwarding-be-off-by-default-in-git
>
> Bye
> Simon
>

Yes that's a great recommendation and it should definitely be included
IMHO!  However, the merge.ff option is relatively new and is not available
in many older Git clients that are still in use.  So the --no-ff tag will
still probably be necessary for some people.  Perhaps we should recommend
both, or would that make things too confusing?

--Kris

Re: [PHP-DEV] php-src is now on git

[Kris Craig]

On Mon, Mar 19, 2012 at 11:46 AM, Alexander Moskaliov wrote:

> Really it was a mistake to do this option recommended (I did it =)). But
> I think for webprojects and documentation will need to mention this option.
>
> With regards, Alexander Moskaliov
> ir...@irker.net
>
>
> 2012/3/19 Christopher Jones 
>
> >
> >
> > On 03/19/2012 10:19 AM, David Soria Parra wrote:
> >
> >  Also a small thing - gitfaq recommends git config core.autocrlf
> >>> input, but we have some files in win32 which do not work with this
> >>> setting (at least on my Mac).
> >>>
> >>
> >> ah okay, can you remove it please? Thanks
> >>
> >
> > Done.
> >
> > --
> > Email: christopher.jo...@oracle.com
> > Tel:  +1 650 506 8630
> > Blog:  http://blogs.oracle.com/opal/
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Ahh ok then I figured it was probably something like that but wanted to
make sure lol.  I'll go ahead and make the correction.  =)

--Kris

Re: [PHP-DEV] php-src is now on git

[Kris Craig]

Hey Chris,

On Mon, Mar 19, 2012 at 11:40 AM, Christopher Jones <
christopher.jo...@oracle.com> wrote:

>
>
> On 03/19/2012 11:34 AM, Kris Craig wrote:
>
>  I noticed that the workflow page recommends using the SSH URL for cloning.
>> However, isn't that one much more limited access?  I.e. for myself at
>> least, it just prompts for a password (presumably for the SSH "git" user)
>> which of course I don't have.  Is there a reason why that's recommended or
>> is it just a typo?  If the latter, I'd be inclined to change it to the SSL
>> (i.e. https) URL (which the FAQ recommends for clone/push and utilizes
>> php.net credentials) to minimize confusion.
>>
>>
> Which exact bit are you talking about, and did you check the page commit
> history?
>
> I added https:// because git: is not usable from where I am.
>
> I believe from your emails you have more git experience than me, and I
> know you've been asked several times to contribute to the docs: go do it.
>
> Chris
>
>
>
> --
> Email: christopher.jo...@oracle.com
> Tel:  +1 650 506 8630
> Blog:  http://blogs.oracle.com/opal/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I sense your hostility but I think you misunderstood my question.  The
workflow page currently recommends the "git:" one for cloning (which
doesn't work for me, either).  I think it should be changed to "https://";,
and I fully intend on making the change myself but first I wanted to ask
here to make sure there wasn't a reason why they went with "git:" instead
(i.e. I don't want to step on anybody's toes).

If nobody objects then yeah I'll gladly update it myself.  =)

--Kris

Re: [PHP-DEV] php-src is now on git

[Kris Craig]

Me again,

On Mon, Mar 19, 2012 at 11:34 AM, Kris Craig  wrote:

> Also,
>
>
> On Mon, Mar 19, 2012 at 11:21 AM, Kris Craig  wrote:
>
>> Hey,
>>
>>
>> On Mon, Mar 19, 2012 at 8:24 AM, David Soria Parra  wrote:
>>
>>> Hi Internals,
>>>
>>> The initial migration is done and initial testing was successful.
>>>
>>>  http://git.php.net/?p=php-src.git;a=summary
>>>  http://github.com/php/php-src
>>>
>>> Please note that some branches and tags were renamed to make
>>> the repository cleaner.
>>>
>>> Please checkout the repository and play around. I have created
>>> a workflow wiki page at https://wiki.php.net/vcs/gitworkflow.
>>> There is also an FAQ at https://wiki.php.net/vcs/gitfaq.
>>>
>>> If you have questions about the workflow or problems let me know.
>>> General git questions should be asked in the appropriate IRC channels
>>> and mailinglists.
>>>
>>> David
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>> Could we modify the workflow to recommend using the "--no-ff" switch when
>> merging in a feature branch?  This is by and large the recommended approach
>> as it preserves the feature branch's commit history, making it *much*easier 
>> to sort through complex features that contain numerous commits.
>>
>> --Kris
>>
>>
> I noticed that the workflow page recommends using the SSH URL for
> cloning.  However, isn't that one much more limited access?  I.e. for
> myself at least, it just prompts for a password (presumably for the SSH
> "git" user) which of course I don't have.  Is there a reason why that's
> recommended or is it just a typo?  If the latter, I'd be inclined to change
> it to the SSL (i.e. https) URL (which the FAQ recommends for clone/push and
> utilizes php.net credentials) to minimize confusion.
>
> --Kris
>
>
Also on the workflow page, it shouldn't be necessary to do "git checkout -b
PHP-5.3 origin/PHP-5.3" if the local repo is already tracking from remote
(which it is if you did a git clone to set it up).  Instead, you can simply
do "git checkout PHP-5.3" and it will automatically track from the remote
branch and pull the necessary data to create a local working copy.

Any objections to me changing that?  The less confusing we can make it,
particularly for people who are already struggling with the SVN
withdrawals, the better IMHO.  =)

--Kris

Re: [PHP-DEV] php-src is now on git

[Kris Craig]

Also,

On Mon, Mar 19, 2012 at 11:21 AM, Kris Craig  wrote:

> Hey,
>
>
> On Mon, Mar 19, 2012 at 8:24 AM, David Soria Parra  wrote:
>
>> Hi Internals,
>>
>> The initial migration is done and initial testing was successful.
>>
>>  http://git.php.net/?p=php-src.git;a=summary
>>  http://github.com/php/php-src
>>
>> Please note that some branches and tags were renamed to make
>> the repository cleaner.
>>
>> Please checkout the repository and play around. I have created
>> a workflow wiki page at https://wiki.php.net/vcs/gitworkflow.
>> There is also an FAQ at https://wiki.php.net/vcs/gitfaq.
>>
>> If you have questions about the workflow or problems let me know.
>> General git questions should be asked in the appropriate IRC channels
>> and mailinglists.
>>
>> David
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> Could we modify the workflow to recommend using the "--no-ff" switch when
> merging in a feature branch?  This is by and large the recommended approach
> as it preserves the feature branch's commit history, making it *much*easier 
> to sort through complex features that contain numerous commits.
>
> --Kris
>
>
I noticed that the workflow page recommends using the SSH URL for cloning.
However, isn't that one much more limited access?  I.e. for myself at
least, it just prompts for a password (presumably for the SSH "git" user)
which of course I don't have.  Is there a reason why that's recommended or
is it just a typo?  If the latter, I'd be inclined to change it to the SSL
(i.e. https) URL (which the FAQ recommends for clone/push and utilizes
php.net credentials) to minimize confusion.

--Kris

Re: [PHP-DEV] php-src is now on git

[Kris Craig]

Hey,

On Mon, Mar 19, 2012 at 8:24 AM, David Soria Parra  wrote:

> Hi Internals,
>
> The initial migration is done and initial testing was successful.
>
>  http://git.php.net/?p=php-src.git;a=summary
>  http://github.com/php/php-src
>
> Please note that some branches and tags were renamed to make
> the repository cleaner.
>
> Please checkout the repository and play around. I have created
> a workflow wiki page at https://wiki.php.net/vcs/gitworkflow.
> There is also an FAQ at https://wiki.php.net/vcs/gitfaq.
>
> If you have questions about the workflow or problems let me know.
> General git questions should be asked in the appropriate IRC channels
> and mailinglists.
>
> David
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Could we modify the workflow to recommend using the "--no-ff" switch when
merging in a feature branch?  This is by and large the recommended approach
as it preserves the feature branch's commit history, making it
*much*easier to sort through complex features that contain numerous
commits.

--Kris

Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production

[Kris Craig]

I'm curious:  What would be the implications of having a third option to
display a generic "catch-all" error instead of a blank page?  For example,
something like, "An error has occurred.  Please check your server's error
log for details."  That would significantly reduce the confusion factor for
inexperienced devs while, at least presumably, not presenting any security
risk because no details are actually being included.

--Kris


On Wed, Mar 14, 2012 at 10:27 AM, Rasmus Lerdorf  wrote:

> On 03/14/2012 10:09 AM, Ferenc Kovacs wrote:
> > On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling  >wrote:
> >> Maybe, and this is right of the top of my head, if PHP is installed
> >> for a production environment with no INI file, or if an ini file
> >> doesn't alter any of the core settings (maybe a separation of INI
> >> files for core and extensions?), it could be labelled/considered as a
> >> virgin PHP install. Something which could be marketed / advertised.
> >> Essentially, the PHP Group agree that for a production environment,
> >> these are the settings that are the safest to use. If there are
> >> considerations that need to be made for shared hosters, then maybe
> >> some mechanism to set these appropriately. So, for a user coming to an
> >> ISP and looking at hosting, they can see "We use Virgin PHP Settings"
> >> or something like that and know that they won't be different to a
> >> documented "standard". Add this labelling to the phpinfo() page and it
> >> makes things very very clear what is in play.
> >>
> >> Richard.
> >>
> >> --
> >> Richard Quadling
> >> Twitter : EE : Zend : PHPDoc
> >> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
> >>
> >
> > bump
>
> The biggest problem with the concept of virgin PHP settings being geared
> for production is that by definition that isn't very developer friendly.
> Keeping the learning curve shallow has always been a goal for PHP which
> is why things like display_errors exist. A new developer may not have
> any idea where to look for PHP errors and might give up when all he gets
> is a blank page.
>
> The assumption is that by the time you are ready to put something into
> production you have spent a little bit of time with PHP and you likely
> have stumbled across the suggested production php.ini which is then
> trivial to apply.
>
> -Rasmus
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] HEADS UP: 5.4 branch is open again

[Kris Craig]

Yes, IF you're using a proper branching model.  If you're just using it the
same way you'd use Subversion, which currently is the direction we seem to
be moving in, those advantages are mostly negated.

I agree that PHP 5.5 (and maybe even 5.6, etc) should come before PHP 6.
That being said, at some point a parallel development workflow might be
prudent IMHO, but even that would be a ways off I think.

--Kris


On Tue, Mar 13, 2012 at 11:55 AM, Richard Lynch  wrote:

> On Fri, March 2, 2012 4:26 am, Ferenc Kovacs wrote:
> > If we can agree upon the next version number beforehand, and we decide
> > that
> > we will go with the major release (be that php 6 or 7, whatever), we
> > don't
> > to do anything right now, we can branch the version from trunk/master,
> > when
> > the time comes.
> > If we can't agree upon the next version number, or we agree upon that
> > there
> > will be an 5.5 version, I think it would make sense to create a branch
> > for
> > it ASAP, so there is place (trunk/master) for the approved but
> > backward
> > incompatible changes, and people don't have to hold patches.
> > What do you think?
>
> If I was in charge, and thankfully I'm not, I'd just create 5.5 and 6.0
>
> If you have patches that don't break BC, put them in both. If you're
> too busy to do both, put it in 6.0  Somebody will back-port or not,
> based on their relative need/availability or not.
>
> If it breaks BC, put it in 6.0
>
> Or perhaps I misunderstand the tiny bit I thought I "got it" of the
> point of using Git in the first place...
>
> Branches and merges are supposed to be seamless, right???
>
> --
> brain cancer update:
> http://richardlynch.blogspot.com/search/label/brain%20tumor
> Donate:
>
> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: Git Migration: Status Update

[Kris Craig]

+1

Git can be confusing for seasoned Subversion developers at first, as it
really is a fundamental paradigm shift in many respects.  I'm not sure why
you're only able to do read-only access, though.  The add/commit syntax for
Git is fairly similar to that of SVN.  Have you tried creating a dummy repo
locally and making commits to that?  I'm not privy to the latest on the Git
migration project, but it could just be a Git and/or FSO permissions issue
on the remote origin.

--Kris


On Tue, Mar 13, 2012 at 8:18 AM, Richard Lynch  wrote:

> On Wed, March 7, 2012 1:51 pm, Sebastian Bergmann wrote:
> > Am 07.03.2012 19:46, schrieb Kris Craig:
> >> As I and others have said already, using a Subversion branching
> >> model
> >> on Git just doesn't make any sense.
> >
> >  How often does it have to be explained to you and others that we
> > would
> >  like to do this step by step? First we change the tool, then we
> > change
> >  the process. Shouldn't be too hard to understand ...
>
> Maybe it's just me, but if I told my boss we were going to change the
> tool and decide and document the fundamental business processes later,
> I don't think that would float...
>
> That said, I still can't get my head around Git at all, and so far
> have only managed to checkout/update on a read-only basis. Not that it
> matters. My code contributions to PHP have been nil so far anyway.
>
> --
> brain cancer update:
> http://richardlynch.blogspot.com/search/label/brain%20tumor
> Donate:
>
> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Upgrade cURL extension

[Kris Craig]

I think waiting until PHP++ is probably the best approach.  It would've
been nice to have the current libcurl version in 5.4.0, but since we're not
talking about any critical bug/security fixes, I don't think it's that big
a deal either way.  So we may as well just sit on it for now.

--Kris


On Sun, Mar 11, 2012 at 8:55 PM, Pierrick Charron wrote:

> I thought about it but I think it may confuse people to have two
> different extensions with the same name, same interface, but one in
> pecl and one in the core package (the difference between the 2
> versions are not that big). Also as ilia mentioned if someone already
> have the original version, they will have symbol conflicts. So I guess
> we could just wait until PHP next unless someone have an other nice
> solution which will not confuse people :)
>
> Thanks all for your input.
>
> Pierrick
>
> On 11 March 2012 03:33, Stas Malyshev  wrote:
> > Hi!
> >
> >
> >> I wanted to make this new version available in PHP5.4 but
> >> unfortunately I did finish my work when it was already in RC phase.
> >> The question now is should we include this new version in PHP5.4.1 or
> >> should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is
> >> no feature break (AFAIK) so all the previous code should work as
> >> expected. You'll find the list of new features attached and the last
> >> code in the trunk branch.
> >
> >
> > Can't you make it also available as pecl extension, which could be built
> on
> > 5.4? This way people could enjoy the benefits of your work without stable
> > branch being disrupted and BC problems raised.
> >
> > --
> > Stanislav Malyshev, Software Architect
> > SugarCRM: http://www.sugarcrm.com/
> > (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [VOTE] APXS LoadModule Option in configure

[Kris Craig]

On Tue, Mar 6, 2012 at 11:56 PM, Lester Caine  wrote:

> Kris Craig wrote:
>
>> I'll commit the changes to 5.4 at the earliest opportunity.  I just
>> realized that the language was somewhat vague as to whether it should be
>> applied to 5.3 branch or not; I don't really care either way but I'll
>> probably just go ahead and apply it to both unless anyone has any
>> objections.
>>
>
> Any reason to change the 'logic' of 5.3 now? Having already been hit by a
> 5.4 change that has not been back-ported, some consistency on what is and
> isn't would be helpful, and I don't think there is any point changing this
> now as most people will simply be updating existing set-ups, and we should
> be recommending 5.4 for new installations anyway?
>
> --
> 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
>
>
Hmm good point.  Ok, you've convinced me.  I'll only apply it to 5.4.  =)

--Kris

Re: [PHP-DEV] Re: Git Migration: Status Update

[Kris Craig]

Umm Sebastian, how many times do I have to explain that *I agree with you*?!

Please read my post before responding.  Specifically, point #5.  I hate
repeating myself, so I'll simply copy/paste it if you don't mind:

"when I draft it I'll propose a gradual adoption scheme"


--Kris


On Wed, Mar 7, 2012 at 10:51 AM, Sebastian Bergmann wrote:

> Am 07.03.2012 19:46, schrieb Kris Craig:
> > As I and others have said already, using a Subversion branching model
> > on Git just doesn't make any sense.
>
>  How often does it have to be explained to you and others that we would
>  like to do this step by step? First we change the tool, then we change
>  the process. Shouldn't be too hard to understand ...
>
> --
> Sebastian BergmannCo-Founder and Principal Consultant
> http://sebastian-bergmann.de/   http://thePHP.cc/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Quoting again (Was: Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Kris Craig]

On Wed, Mar 7, 2012 at 10:31 AM, Sebastian Bergmann wrote:

> Am 07.03.2012 11:05, schrieb Derick Rethans:
> >> "3. Do not top post. Place your answer underneath anyone you wish to
> >> quote and remove any previous comment that is not relevant to your
> >> post."
>
>  Couldn't agree more, such quoting is really annoying. While we are at
>  the topic of etiquette: please use your realname when posting to this
>  list. Thanks!
>
> --
> Sebastian BergmannCo-Founder and Principal Consultant
> http://sebastian-bergmann.de/   http://thePHP.cc/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
You guys make a valid point, but I think Pierre does as well.  Creating a
stink over a quick one-liner reply seems a bit excessive IMHO.  If this is
really such a problem, we need to try and think of a solution other than
just "policing," which obviously hasn't worked.

Just my five cents (damn inflation!).

--Kris

Re: [PHP-DEV] Re: Git Migration: Status Update

[Kris Craig]

On Wed, Mar 7, 2012 at 1:12 AM, David Soria Parra  wrote:

> On 2012-03-07, Kris Craig  wrote:
> > --f46d044304ec4e135704baa12342
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes 
> wrote:
> >
> >> On Wed, Mar 7, 2012 at 6:03 AM, Drak  wrote:
> >>
> > I know I keep promising to draft an RFC for this lol, so I'll make it a
> > high priority to put together an RFC for a PHP Git branching model
> sometime
> > this week[end].
>
> There is no need for that. PHP will continue to use release branches
> with optional feature branches. We are doing one step at a time and
> have people adopt the changes slowly. We are after all a large project
> and a lot of contributors cannot spend hours of reading into a VCS
> and a new branching model. So we are slowly moving towards new models.
>
> After all I see no need to do it differently. You can use whatever
> branching model you want in your personal github repository and then
> send a final pull request that can be merged. Adding complexity
> to the main repository for no reason is not needed. Keep the
> complexity in your personal repositories. That is after all
> one of the main benefits of a decentralized version control system.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
A few points

   1. This really wouldn't be adding "complexity" to the repo.  We would
   merely be using a branching model that is more compatible with Git's
   feature set.  As I and others have said already, using a Subversion
   branching model on Git just doesn't make any sense.  We may as well just
   keep using SVN if we're not going to make use of Git's branching advantages.
   2. Using different branching structures between repo clones is not
   considered a good practice in Git.  On the contrary, it just makes the
   commit history that much more confusing to read.  If you use a standardized
   branching model, on the other hand, different features/contributions can be
   quickly and easily identified in the history (see "gitk --all").  In the
   event of a regression or other bad feature commit, reversing it is
*much*easier and cleaner if branches are clearly segregated.  It also
makes
   drafting the changelog a much less cumbersome task.
   3. I'm all for using a gradual approach so that people have time to get
   used to it.  However, that transition to a standards-compliant Git
   branching model is still something that does need to happen eventually.
   4. Git branching is not *nearly* as complicated or confusing as you guys
   are making it out to be.  You know how long it took me to train our IT guy
   at work on Git branching?  10 minutes.  He then made one mistake (forgot
   the --no-ff), which I corrected, and ever since he's been using it without
   any problems and raving about how much easier it is to keep track of our
   commit history now than when we were on Subversion.  Seriously, the
   learning curve is *very* minimal, even for those who are used to SVN
   branching.
   5. Enough people have expressed support for this idea to justify
   drafting an RFC and letting it be voted on IMHO.  However, I would like to
   address your concerns about confusion (though experience tells me that
   they're largely unfounded), so when I draft it I'll propose a gradual
   adoption scheme of some sort so that anyone who feels intimidated by
   adhering to mainstream accepted Git branching standards won't feel
   disenfranchised.
   6. There are also scripts that simplify this model (
   https://github.com/nvie/gitflow), though I've never used them myself.
   But I'll take a look and see if that might be something that could be
   recommended for anyone who doesn't want to spend the few minutes it would
   take to learn t his model.


--Kris

Re: [PHP-DEV] Re: Git Migration: Status Update

[Kris Craig]

On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes  wrote:

> On Wed, Mar 7, 2012 at 6:03 AM, Drak  wrote:
>
> > [snip]
> > Forcing pushes to one's own topic branches in one's own fork can be
> > acceptable providing
> > upstream maintainers know before merging (for example squashing some work
> > after peer review), but not to the central repo without some exceptional
> > reason - it could cause chaos otherwise.
>
>
> Gerrit has an interesting take on this, you are free to do whatever you
> like on refs/heads/dev/${username}/* - including force push etc.
>
> Maybe something like this could be useful?
>
> Kiall
>

Again I would just stress that, if people followed a Git branching model
and only made direct commits to feature branches they themselves
create/maintain, this scenario shouldn't be one that's likely to come up.
 Once a feature branch is complete and it's been tested/approved/whatever
(process is important), you simply do a fresh pull of the develop (or, in
this case, version) branch, rebase the feature off of that, then merge it
into the develop branch and do a push.  Using this approach, any merge
conflicts that might arise (such as overwriting work that somebody else
recently contributed) would be caught before anything is pushed.  Instead,
said conflicts are resolved manually and then Git proceeds with the merge.
 This is similar in concept to what Kiall alluded to.

I know I keep promising to draft an RFC for this lol, so I'll make it a
high priority to put together an RFC for a PHP Git branching model sometime
this week[end].

--Kris

[PHP-DEV] Re: [VOTE] APXS LoadModule Option in configure

[Kris Craig]

Voting is now closed.  This RFC was passed unanimously 12-0.

I'll commit the changes to 5.4 at the earliest opportunity.  I just
realized that the language was somewhat vague as to whether it should be
applied to 5.3 branch or not; I don't really care either way but I'll
probably just go ahead and apply it to both unless anyone has any
objections.


Thanks!

--Kris


On Mon, Mar 5, 2012 at 11:24 AM, Kris Craig  wrote:

> FYI-
>
> Voting will be closed at 2 PM (PST) tomorrow.
>
> --Kris
>
>
>
> On Thu, Mar 1, 2012 at 1:04 PM, Kris Craig  wrote:
>
>> Just a friendly reminder to vote on this if you haven't already.  5
>> people have voted on it thus far but I'd like to have at least twice that
>> by the time voting closes.
>>
>> You can read the RFC and vote on it at:
>> https://wiki.php.net/rfc/apxs-loadmodule
>>
>>
>> Thanks!
>>
>> --Kris
>>
>>
>>
>> On Tue, Feb 28, 2012 at 12:19 PM, Kris Craig wrote:
>>
>>> Hi all,
>>>
>>> It looks like we've reached a consensus on this, so absent any
>>> objections, I went ahead and moved this to the voting phase.
>>>
>>> If you're eligible to vote on RFC's, please navigate to the RFC and cast
>>> your vote now:
>>>
>>> https://wiki.php.net/rfc/apxs-loadmodule
>>>
>>>
>>> In case you weren't following the previous thread, this is a very
>>> low-impact RFC that will add a new, optional switch to the configure
>>> script.  This switch, if specified, would tell APXS (which already has this
>>> functionality built-in) not to write the LoadModule line to httpd.conf when
>>> "make install" is performed.  This is a feature that has been requested for
>>> some time and would allow people with manually-built PHP installs to
>>> isolate their mod_php hooks in a separate php.conf file without having to
>>> manually edit httpd.conf whenever a new build is performed.
>>>
>>> If this optional switch is not specified, the configure script will
>>> behave exactly as it does now.  As such, this RFC will *not* alter
>>> configure's existing behavior unless you explicitly include this new switch.
>>>
>>>
>>> Please let me know if you have any last-minute questions.  Otherwise,
>>> happy voting!  Thanks!
>>>
>>> --Kris
>>>
>>>
>>
>

Re: [PHP-DEV] Scalar Type Hinting

[Kris Craig]

Personally, speaking for myself at least, I've quieted on the subject
temporarily in favor of advocating some improvements to the RFC voting
process that will ultimately make it easier for us to work through these
type hinting questions.  I'll be resurrecting the discussion on this end
before too long.  =)

--Kris


On Tue, Mar 6, 2012 at 3:35 PM, Anthony Ferrara  wrote:

> My concern is the total lack of talk on-list about it.  It's obviously
> not perfect, but there has been little to no talk on-list about it.
> That is an indication to me that it's not ready or that it won't get
> in if put to a vote...
>
> Thoughts?
>
> Anthony
>
> On Tue, Mar 6, 2012 at 6:10 PM, Simon Schick
>  wrote:
> > Hi,
> >
> > It got quite around that because we have some RFCs to this where the
> > functionality seems to be defined as the people thought it should be.
> > Otherwise they can raise their hands and write a mail that they want to
> > update the RFC - but as there's no one doing that, I think we're quite
> > close to what we wanted.
> >
> > Take a look at it and feel free to add your ideas in this thread.
> > https://wiki.php.net/rfc/parameter_type_casting_hints
> > https://wiki.php.net/rfc/object_cast_to_types
> >
> > Bye
> > Simon
> >
> > 2012/3/6 Kris Craig 
> >
> >> Wow no offense, but your timing is terrible, Raymond!  We've been going
> >> back and forth on this for the past couple weeks now, though the
> discussion
> >> has quieted for the moment.
> >>
> >> I would suggest you go through some of the recent posts on Internals.
> >> Right now there basically is no solid consensus on this issue, though
> some
> >> of us have been working to change that.  But as it stands now, I'm not
> >> aware of any plans to introduce expanded typing of any kind in the
> >> foreseeable future.  And even if we did, I highly doubt it would happen
> >> before PHP 6.
> >>
> >> --Kris
> >>
> >>
> >> On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving 
> wrote:
> >>
> >> > Hello,
> >> >
> >> > I came across some info on the web that states that scalar type
> hinting
> >> was
> >> > added to the PHP trunk but it did not make it's way into 5.4 because
> of
> >> > objections from the community. Will it ever make it's way into 5.5?
> >> >
> >> > I know PHP is considered to be a weak typed language but it should
> also
> >> be
> >> > about freedom. Freedom for a PHP developer to choose to use scalar
> type
> >> > hinting whenever he/she sees the need.
> >> >
> >> >
> >> > Best regards,
> >> > __
> >> > Raymond
> >> >
> >>
>

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

[Kris Craig]

Do we have any solid data on the performance difference between arithmetic
operations with bcmath and without?  To me, that would be immensely helpful
in framing this.  I like the idea, but the potential performance drag
concerns me.  Knowing exactly how big a drag we're looking at would make it
easier to put this into some sort of context IMHO.

--Kris

Re: [PHP-DEV] '

[Kris Craig]

2012/3/6 Ángel González 

> On 06/03/12 19:36, Kris Craig wrote:
>
> 
>
> >> FIRST:
> >> do NOT top post after get a reply below your text
> >> or how do you imagine that anybody can follow a
> >> thread where answers randomly before and after
> >> the quotet text?
> > Sorry.  Sometimes I forget that there are some people out there who still
> > use legacy non-threaded inboxes.  I would recommend you consider
> switching
> > to Gmail or some other email client/service that supports threaded views.
> > That will make it a lot easier for you to follow these threads.  =)
> Threaded MUAs won't help when fragments appear as
> 3
> 1
> 2
> 4
>
> In such cases, the people breaking the thread convention should
> the very least remove all the other content.
> And yes, his MUA does support threading.
>
> 
>

I'll try this one last time:  I don't know what the solution is.  What I do
know is that relying solely on, "people should" is not a smart approach
because people are going to break that convention regardless of whether
they should or not.  Yes, educating people is important, but that in and of
itself isn't working.  It doesn't work on any similar listserv I've
subscribed to over the years.  It just seems a bit naive to think that we
can keep repeating the same pattern over and over and expect a different
result.  What I'm suggesting is that it would be to our benefit to think of
a more sustainable approach.  I'm not saying I know what that approach is,
mind you.


>
>
> > To clarify again, I was under the mistaken impression that  > alias for short_open_tag.  My argument was (and still is) against
> > short_open_tag.  I do see some use in this new echo alias for templating
> > purposes.
> >
> > --Kris
> 
>
And your point is?  I initially thought this thread was saying that
this alias had been removed and instead made to replace the
short_open_tag.  I stood corrected and we moved on.  What does PHP 3 have
to do with any of this?  I think you've officially crossed the line from
correcting somebody's error to beating a dead horse.  ;P

--Kris

Re: [PHP-DEV] '

[Kris Craig]

Responses inline per your request.

--Kris


On Tue, Mar 6, 2012 at 3:32 AM, Reindl Harald wrote:

> Am 06.03.2012 01:13, schrieb Kris Craig:
> > On Windows (where I generally do most of my scripting grunt work),
> > I typically use Notepad++ and it highlights
> >  >
> > On Mon, Mar 5, 2012 at 4:11 PM, Reindl Harald 
> >  h.rei...@thelounge.net>> wrote:
> > Am 06.03.2012 01:03, schrieb Kris Craig:
> > > I've never understood the "it's easier to read" argument since
> I've found
> > > it to be exactly the opposite.  The  least for
> > > me, makes it more difficult to "at a glance" see where the PHP
> code begins
> >
> > if you hvae a usebale editor  would become different
> colors
> > only in notepad or on the shell you would not see php-code but
> > who does develop this way these days?
>
> FIRST:
> do NOT top post after get a reply below your text
> or how do you imagine that anybody can follow a
> thread where answers randomly before and after
> the quotet text?
>

Sorry.  Sometimes I forget that there are some people out there who still
use legacy non-threaded inboxes.  I would recommend you consider switching
to Gmail or some other email client/service that supports threaded views.
That will make it a lot easier for you to follow these threads.  =)


>
> SECOND:
> it is simply clear that it highlights " what i said is "throw it away if it does NOT highlight ""
>
> the "" is much easier readable as ""
>
>
>
To clarify again, I was under the mistaken impression that