[PHP-DEV] Some Stats
Number of posts to internals since Jan.1,2012 (top 15): [kris.cr...@gmail.com]=> 249 [smalys...@sugarcrm.com] => 193 [pierre@gmail.com]=> 146 [yohg...@ohgaki.net] => 105 [t...@punkave.com] => 98 [tyr...@gmail.com]=> 96 [ircmax...@gmail.com] => 75 [keis...@gmail.com] => 75 [c...@l-i-e.com] => 63 [johncrens...@priacta.com]=> 63 [ras...@lerdorf.com] => 61 [larue...@php.net]=> 61 [simonsimc...@googlemail.com] => 58 [glo...@nebm.ist.utl.pt] => 51 [les...@lsces.co.uk] => 51 Number of posts to the commit list since Jan.1,2012 (top 25): [s...@php.net] => 412 [d...@php.net] => 146 [larue...@php.net] => 117 [a...@php.net] => 75 [cataphr...@php.net] => 59 [ir...@php.net]=> 52 [ras...@php.net] => 51 [paj...@php.net] => 47 [johan...@php.net] => 42 [s...@php.net] => 36 [m...@php.net] => 31 [der...@php.net] => 25 [dmi...@php.net] => 23 [il...@php.net]=> 22 [christopher.jo...@oracle.com] => 19 [smalys...@sugarcrm.com] => 17 [ni...@php.net]=> 17 [pierre@gmail.com] => 15 [nlop...@php.net] => 12 [yohg...@php.net] => 11 [ahar...@php.net] => 11 [bj...@php.net]=> 10 [phi...@php.net] => 8 [sebast...@php.net]=> 8 [pierr...@php.net] => 7 -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] voting without vcs accounts
On Apr 16, 2012, at 6:21 PM, Ferenc Kovacs wrote: > On Tue, Apr 17, 2012 at 3:14 AM, Kris Craig wrote: > >> >> >> On Mon, Apr 16, 2012 at 6:10 PM, Ferenc Kovacs wrote: >> >>> Just to play devil's advocate (Satan and I go way back), what about people who are established PHP developers but who generally don't participate in the development/discussion of PHP core? An argument could be made that, as the users of PHP, they should be able to have some say in its development. That's not my position, mind you; I'm just throwing that premise out there to see if it holds up. =) >>> >>> could you please open a separate thread for that? >>> btw. "regular participant of internals discussions" is one of the reason >>> on which group someone can get voting karma. >>> so if that is provided, anybody have a chance to get join >>> the decision making process. >>> >>> -- >>> Ferenc Kovács >>> @Tyr43l - http://tyrael.hu >>> >> >> Why would that be a separate thread? Isn't that what we're talking >> about? I.e. determining who gets voting access and who doesn't? > > > I just ask for clarification on how the community representatives (which is > defined in the accepted voting RFC) can get their karma. > You are talking about changing the requirements for somebody to be able to > participate in the voting, thus changing/extending the original RFC. The voting RFC is unclear but aside from that, there are two non-vcs accounts with voting karma today: User: damz: Damien Tournoud - d...@damz.org User: hywan: Ivan Enderlin - ivan.ender...@hoa-project.net Not saying they should or should not, but just saying. And I'm not sure how/when they received the voting karma but it happened. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re voting
On Mon, Apr 16, 2012 at 11:42 PM, wrote: > Stas: > > Just b/c there are rarely any women at all that participate on this list, > could we at list maintain a facade of gender neutrality? I seriously can't > believe that you used the word "him". What about "her"? Yeah, "her" as in > myself and every other woman who codes with PHP whether to earn her living > or to have a pleasant past-time? I am sure that there are plenty of PHP > women just like me who might really appreciate having the opportunity to > vote on changes that might effect the way we work. > > Currently, it's as clear as mud to me as to what I need to do to be able > to have some kind of voting impact. The protocol or process needs to be > clearly articulated in very clear language so that all concerned PHP men > and women can be informed. > > Sharon Lee Levy, ZCE Hi Sharon, I'm a father of 3 daughters, and I'm protective of the opportunities they'll have when they're old enough to enter the working world (right now the oldest is 7.) In fact, my daughters have started developing websites already, and I'm sure PHP is just around the corner, so maybe they'll end up using this list a few years from now :) I believe you quoted Stas's response below: >> no, it only means that our internal processes aren't clear or easily >> accessible. >> people outside the circle can't do much, than asking people inside to >> let them in. > >If somebody is an outsider to PHP development, why do you think giving >him a deciding vote on it would be a good thing? One can discuss things, >propose changes, etc. without any special access. Stas does a great job engaging in the dialogues on this list, and I can't even imagine the cost in terms of time. I know it must be great. In this case, I don't believe Stas meant any offense. The lack of a gender neutral pronoun in English is well documented (and argued:) http://en.wikipedia.org/wiki/Gender-neutral_pronoun When Stas wanted to use a singular form of a pronoun, he had a few options (as outlined in the link): - he - they (implied singular) - one - he/she I'm confident his choice of words was for speed, not one of precise articulation of the group involvement. Glad you're own the list :) My girls will be grateful for the role model(s) in a few years! Adam
[PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
So, at current, is this small enough for just a pull request, or does
this deserve its own RFC?
-ralph
On 4/14/12 2:50 PM, Ralph Schindler wrote:
Hi all,
There are many different use cases were in code we expect classes names
as arguments to functions as fully qualified names. We do this in ZF a
lot with our Service Location and DI components, but also with our code
reflection API, etc. A more interesting use case I would like to call
out is with PHPUnit, for example in a test, you might find this:
$mock = $this->getMock('A\Namespaced\ClassName');
This becomes cumbersome when you are dealing with lots of strings about
lots of class names. This is also an area where, currently, namespace
declaration and use statements offer no real support.
The patch located here:
https://github.com/ralphschindler/php-src/commit/02210d51851a96d723fbedcfc64cde9f9ae2b22a
... implements the ability for a developer to leverage the file's
namespace declaration and use statements to be able to produce a scalar
(string) of the class name that can be then used, for example, as an
argument to a function elsewhere.
This overloads the "class" keyword, and by virtue of the existing usage
of "class" this feature is completely backwards compatible. All existing
tests pass. For example, the above PHPUnit snipped would become:
use A\Namespaced\ClassName;
$mock = $this->getMock(ClassName::class);
Another example with reflection:
use SomeOther\FullyNamespaced\ClassElsewhere as CE;
$r = new ReflectionClass(CE::class);
More examples from the test file:
namespace Foo\Bar {
class Baz {}
var_dump(Moo::CLASS); // "Foo\Bar\Moo"
}
namespace {
use Bee\Bop as Moo,
Foo\Bar\Baz;
var_dump(Baz::class); // "Foo\Bar\Baz"
var_dump(Boo::class); // "Boo"
var_dump(Moo::CLASS); // "Bee\Bop"
var_dump(\Moo::Class); // "Moo"
$class = Baz::class; // assign class as scalar to var
$x = new $class;
var_dump($x); object(Foo\Bar\Baz)#1 (0) {}
}
What do you guys think?
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re voting
On 17 April 2012 11:42, wrote: > Just b/c there are rarely any women at all that participate on this list, > could we at list maintain a facade of gender neutrality? I seriously can't > believe that you used the word "him". What about "her"? Yeah, "her" as in > myself and every other woman who codes with PHP whether to earn her living or > to have a pleasant past-time? I am sure that there are plenty of PHP women > just like me who might really appreciate having the opportunity to vote on > changes that might effect the way we work. While I am fully in support of PHP being inclusive towards men, women, the transgendered community, and anyone else who is not covered by the aforementioned categories, with respect, I don't believe Stas merited the sarcastic flame he has received from you. Singular "he" as a gender-neutral pronoun was taught as standard English for a long time, and whilst it may not be the most politically correct phrasing in the modern era, I doubt any offence or non-inclusion was intended. Furthermore, many of the participants on this list are not native English speakers, and the nuances and politics of gender representation in a largely non-gendered language like English are likely to be lost on them. Hanlon's Razor would seem to apply. > Currently, it's as clear as mud to me as to what I need to do to be able to > have some kind of voting impact. The protocol or process needs to be clearly > articulated in very clear language so that all concerned PHP men and women > can be informed. On that point, I doubt anyone disagrees. Thanks, Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re voting
> Just b/c there are rarely any women at all that participate on this list, > could we at list maintain a facade of gender neutrality? I seriously can't > believe that you used the word "him". What about "her"? Yeah, "her" as in > myself and every other woman who codes with PHP whether to earn her living or > to have a pleasant past-time? I am sure that there are plenty of PHP women > just like me who might really appreciate having the opportunity to vote on > changes that might effect the way we work. > > Currently, it's as clear as mud to me as to what I need to do to be able to > have some kind of voting impact. The protocol or process needs to be clearly > articulated in very clear language so that all concerned PHP men and women > can be informed. > > Sharon Lee Levy, ZCE I believe you might have been trying to reply to the "voting without vcs accounts" thread, possibly? I do agree that the current state of affairs with regard to voting on RFCs and the requirements/expectations for one to be promoted into the voting process are about as clear the night sky. There should be more transparency in understanding the requirements and setting forth the expectations for the process in a formal and sane manner. I also think that process should be fair irrespective of gender, race, etc... The process should be subject to one's own demonstrated active (and hopefully positive) role in the PHP community. I think if someone shows initiative to consistently produce positive results they should be accepted into the voting process based on their own merits. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re voting
Stas: Just b/c there are rarely any women at all that participate on this list, could we at list maintain a facade of gender neutrality? I seriously can't believe that you used the word "him". What about "her"? Yeah, "her" as in myself and every other woman who codes with PHP whether to earn her living or to have a pleasant past-time? I am sure that there are plenty of PHP women just like me who might really appreciate having the opportunity to vote on changes that might effect the way we work. Currently, it's as clear as mud to me as to what I need to do to be able to have some kind of voting impact. The protocol or process needs to be clearly articulated in very clear language so that all concerned PHP men and women can be informed. Sharon Lee Levy, ZCE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] voting without vcs accounts
On Mon, Apr 16, 2012 at 7:41 PM, Ryan McCue wrote: > Kris Craig wrote: > >> An argument could be made that, as the users of PHP, they should be able >> to have some say in its development. >> > > As a PHP developer (that is, a developer who writes in PHP), I'd agree, > *to an extent*. There are certainly things that I'd like to be able to vote > on (such as additions to the language/syntax and things such as .phpp). > However, I've got no idea how easy such things are to implement, so I don't > feel qualified to even ask to be able to vote. > > However, these things are going to influence me as a developer, so I'd > like to be able to vote. > > Take, as an example, the .phpp debates. (Just as an example.) If I didn't > like it, I'd like to be able to vote against it to avoid having to handle > it later. However, if I *was* for it, I wouldn't feel qualified to comment, > as I have no idea how hard these things are to implement. > > (Just my $0.02. Apologies if this is confusing, I'm a mixture of tired and > distracted.) > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Hmm yeah that makes sense. What if we split the questions into multiple parts? For example, the first question would be something along the lines of, "Conceptually, do you think this is a good idea?" That could be open to PHP developers as well. Then the second question could be, "If you answered 'Yes', as a core contributor, do you believe this proposal is technically feasible?" That question would be open only to the people who can vote now. Mind you, I'm just throwing this out there off the top of my head. It could be a really stupid idea, but I thought it might provoke some interesting discussion at the very least. With that in mind Thoughts? =) --Kris
Re: [PHP-DEV] voting without vcs accounts
Kris Craig wrote: An argument could be made that, as the users of PHP, they should be able to have some say in its development. As a PHP developer (that is, a developer who writes in PHP), I'd agree, *to an extent*. There are certainly things that I'd like to be able to vote on (such as additions to the language/syntax and things such as .phpp). However, I've got no idea how easy such things are to implement, so I don't feel qualified to even ask to be able to vote. However, these things are going to influence me as a developer, so I'd like to be able to vote. Take, as an example, the .phpp debates. (Just as an example.) If I didn't like it, I'd like to be able to vote against it to avoid having to handle it later. However, if I *was* for it, I wouldn't feel qualified to comment, as I have no idea how hard these things are to implement. (Just my $0.02. Apologies if this is confusing, I'm a mixture of tired and distracted.) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] voting without vcs accounts
On Mon, Apr 16, 2012 at 6:21 PM, Ferenc Kovacs wrote: > > > On Tue, Apr 17, 2012 at 3:14 AM, Kris Craig wrote: > >> >> >> On Mon, Apr 16, 2012 at 6:10 PM, Ferenc Kovacs wrote: >> >>> Just to play devil's advocate (Satan and I go way back), what about people who are established PHP developers but who generally don't participate in the development/discussion of PHP core? An argument could be made that, as the users of PHP, they should be able to have some say in its development. That's not my position, mind you; I'm just throwing that premise out there to see if it holds up. =) >>> >>> could you please open a separate thread for that? >>> btw. "regular participant of internals discussions" is one of the reason >>> on which group someone can get voting karma. >>> so if that is provided, anybody have a chance to get join >>> the decision making process. >>> >>> -- >>> Ferenc Kovács >>> @Tyr43l - http://tyrael.hu >>> >> >> Why would that be a separate thread? Isn't that what we're talking >> about? I.e. determining who gets voting access and who doesn't? > > > I just ask for clarification on how the community representatives (which > is defined in the accepted voting RFC) can get their karma. > You are talking about changing the requirements for somebody to be able to > participate in the voting, thus changing/extending the original RFC. > It's the same topic, and the question of who *should* or should not be allowed to vote was already raised previously on this thread. That's what I was responding to. So, deep breath =) --Kris > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu >
Re: [PHP-DEV] voting without vcs accounts
On Tue, Apr 17, 2012 at 3:14 AM, Kris Craig wrote: > > > On Mon, Apr 16, 2012 at 6:10 PM, Ferenc Kovacs wrote: > >> >>> Just to play devil's advocate (Satan and I go way back), what about >>> people who are established PHP developers but who generally don't >>> participate in the development/discussion of PHP core? An argument could >>> be made that, as the users of PHP, they should be able to have some say in >>> its development. That's not my position, mind you; I'm just throwing that >>> premise out there to see if it holds up. =) >>> >> >> could you please open a separate thread for that? >> btw. "regular participant of internals discussions" is one of the reason >> on which group someone can get voting karma. >> so if that is provided, anybody have a chance to get join >> the decision making process. >> >> -- >> Ferenc Kovács >> @Tyr43l - http://tyrael.hu >> > > Why would that be a separate thread? Isn't that what we're talking > about? I.e. determining who gets voting access and who doesn't? I just ask for clarification on how the community representatives (which is defined in the accepted voting RFC) can get their karma. You are talking about changing the requirements for somebody to be able to participate in the voting, thus changing/extending the original RFC. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] voting without vcs accounts
On Mon, Apr 16, 2012 at 6:10 PM, Ferenc Kovacs wrote: > >> Just to play devil's advocate (Satan and I go way back), what about >> people who are established PHP developers but who generally don't >> participate in the development/discussion of PHP core? An argument could >> be made that, as the users of PHP, they should be able to have some say in >> its development. That's not my position, mind you; I'm just throwing that >> premise out there to see if it holds up. =) >> > > could you please open a separate thread for that? > btw. "regular participant of internals discussions" is one of the reason > on which group someone can get voting karma. > so if that is provided, anybody have a chance to get join > the decision making process. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > Why would that be a separate thread? Isn't that what we're talking about? I.e. determining who gets voting access and who doesn't? --Kris
Re: [PHP-DEV] voting without vcs accounts
> > > Just to play devil's advocate (Satan and I go way back), what about people > who are established PHP developers but who generally don't participate in > the development/discussion of PHP core? An argument could be made that, as > the users of PHP, they should be able to have some say in its development. > That's not my position, mind you; I'm just throwing that premise out there > to see if it holds up. =) > could you please open a separate thread for that? btw. "regular participant of internals discussions" is one of the reason on which group someone can get voting karma. so if that is provided, anybody have a chance to get join the decision making process. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] voting without vcs accounts
On Mon, Apr 16, 2012 at 4:58 PM, Stas Malyshev wrote: > Hi! > > > no, it only means that our internal processes aren't clear or easily > > accessible. > > people outside the circle can't do much, than asking people inside to > > let them in. > > If somebody is an outsider to PHP development, why do you think giving > him a deciding vote on it would be a good thing? One can discuss things, > propose changes, etc. without any special access. > Just to play devil's advocate (Satan and I go way back), what about people who are established PHP developers but who generally don't participate in the development/discussion of PHP core? An argument could be made that, as the users of PHP, they should be able to have some say in its development. That's not my position, mind you; I'm just throwing that premise out there to see if it holds up. =) > > > you mean the +1/-1 on the mailing list threads? > > No, I mean community voting in the wiki. Voting plugin has option to > allow anybody to vote. We did such polls in the past. We can do it any day. > > > but if we decide to keep it, we should make it possible for people to be > > able to request for voting karma, and a way to handle those requests. > > Why sending a message to the list is not enough? > -- > 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] voting without vcs accounts
On Tue, Apr 17, 2012 at 2:28 AM, Stas Malyshev wrote: > Hi! > > > I'm not sure about it. AFAIK when I implemented my patch to restrict the > > voting to the vcs users + the voting wiki group, we lost that ability. > > (see http://www.mail-archive.com/internals@lists.php.net/msg51932.htmlfor > > the history of that change) > > I don't see any indication there that community vote is not possible, > but if it was changed we can make community vote be available again. > > http://www.mail-archive.com/internals@lists.php.net/msg51948.html Pierre said that it was a bug(better to say lack of restriction), that everybody with wiki account was able to vote, so I changed the voting plugin to only allow the specific groups(vcs + voting) to be able to vote. nobody asked that we would still need to keep the ability to create "open" votes where anybody can vote, so it wasn't implemented. > My point is that we are talking about some formal processes but I don't > see what would be the desired purpose of such processes. For release > process, it's releasing a stable code in time. For RFC, it is informing > people about proposed feature and getting it discussed and hopefully > accepted. Here, I'm not sure what is the goal. > To be able to get voting karma if you meet the requirements. without the need to bribe Hannes, Philip or any other wiki admin. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] voting without vcs accounts
Hi! > I'm not sure about it. AFAIK when I implemented my patch to restrict the > voting to the vcs users + the voting wiki group, we lost that ability. > (see http://www.mail-archive.com/internals@lists.php.net/msg51932.html for > the history of that change) I don't see any indication there that community vote is not possible, but if it was changed we can make community vote be available again. My point is that we are talking about some formal processes but I don't see what would be the desired purpose of such processes. For release process, it's releasing a stable code in time. For RFC, it is informing people about proposed feature and getting it discussed and hopefully accepted. Here, I'm not sure what is the goal. -- 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] voting without vcs accounts
On Tue, Apr 17, 2012 at 1:58 AM, Stas Malyshev wrote: > Hi! > > > no, it only means that our internal processes aren't clear or easily > > accessible. > > people outside the circle can't do much, than asking people inside to > > let them in. > > If somebody is an outsider to PHP development, why do you think giving > him a deciding vote on it would be a good thing? One can discuss things, > propose changes, etc. without any special access. > thats something which the current voting RFC allows. it seems that we are already over on that decision, as the accepted RFC had that clause. > > > you mean the +1/-1 on the mailing list threads? > > No, I mean community voting in the wiki. Voting plugin has option to > allow anybody to vote. We did such polls in the past. We can do it any day. > I'm not sure about it. AFAIK when I implemented my patch to restrict the voting to the vcs users + the voting wiki group, we lost that ability. (see http://www.mail-archive.com/internals@lists.php.net/msg51932.html for the history of that change) > > > but if we decide to keep it, we should make it possible for people to be > > able to request for voting karma, and a way to handle those requests. > > Why sending a message to the list is not enough? > dunno, but it seems it isn't, as nobody replied or gave voting karma to William. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] '9223372036854775807' == '9223372036854775808'
Hi! > In any case, your selective quoting destroyed the main point of my > e-mail -- that is, this problem implicates these questions: is > "9223372036854775808" different from 9223372036854775808? Is > "9223372036854775808" still deemed to represent an integer, even > though we cannot represent it as an integer type? Well, it is different, as it looks like from usage patterns. You can't get int 9223372036854775808 from database or web form, but you very well can get string "9223372036854775808". > I think most people can agree that this behavior is correct: > > var_dump(9223372036854775807 == 9223372036854775808); //true I would say, yes, this is fine. > therefore, we need some -- principled -- distinction to treat case > "9223372036854775807" == "9223372036854775808" differently. The > distinction I propose is answering "yes" to the questions above -- > they represent different entities and when no conversion of the > integer string to the integer type can't be done we should fall back > to memcmp(). This is what is already done with the overflowing > "1e400". I don't find it particularly convincing, though. I think this is the way to go, unless somebody proposes a better way to handle it. -- 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] voting without vcs accounts
Hi! > no, it only means that our internal processes aren't clear or easily > accessible. > people outside the circle can't do much, than asking people inside to > let them in. If somebody is an outsider to PHP development, why do you think giving him a deciding vote on it would be a good thing? One can discuss things, propose changes, etc. without any special access. > you mean the +1/-1 on the mailing list threads? No, I mean community voting in the wiki. Voting plugin has option to allow anybody to vote. We did such polls in the past. We can do it any day. > but if we decide to keep it, we should make it possible for people to be > able to request for voting karma, and a way to handle those requests. Why sending a message to the list is not enough? -- 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] voting without vcs accounts
On Tue, Apr 17, 2012 at 1:32 AM, Stas Malyshev wrote: > Hi! > > > the voting RFC explicitly states that it is possible for (some) non-vcs > > users to vote, but there isn't any formal process on how can someone > > apply for voting karma, and what is the decision making process on this. > > And what is the problem in not having the formal process? > uhm. do I really have to explain it? for you? the same reason why we have the rfc process, the release process, the voting process. I'm not talking about 100% complete, unchangeable rules, but some kind of process to follow. mentioning the option for non-vcs users to vote in the voting RFC without providing them a way to apply for karma is the same as we wouldn't mention it at all. I could also accept if we don't allow them, but then we should be clear about it. > > > which went unanswered and I was also questioned on irc/twitter multiple > > times about how can somebody request voting karma. > > I'd say if you have to request it and you have to ask about it on > twitter, you probably do not know enough about PHP development process > to have a deciding vote on PHP features. no, it only means that our internal processes aren't clear or easily accessible. people outside the circle can't do much, than asking people inside to let them in. > For non-deciding votes, we have > community voting where pretty much anyone can vote. > you mean the +1/-1 on the mailing list threads? that's nice, but I'm talking about the voting laid out in the voting process rfc https://wiki.php.net/rfc/voting (what you also supported). as I mentioned before, I can live with it if we remove the ability for non-vcs users to vote, but in that case we should update the rfc (and the karma check in the wiki) accordingly. but if we decide to keep it, we should make it possible for people to be able to request for voting karma, and a way to handle those requests. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
> > > @Ferenc Thanks for the thoughtful analysis! I must confess I'm a bit > groggy at the moment so I'll have to go over it later. > sure, take your time. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] voting without vcs accounts
Hi! > the voting RFC explicitly states that it is possible for (some) non-vcs > users to vote, but there isn't any formal process on how can someone > apply for voting karma, and what is the decision making process on this. And what is the problem in not having the formal process? > which went unanswered and I was also questioned on irc/twitter multiple > times about how can somebody request voting karma. I'd say if you have to request it and you have to ask about it on twitter, you probably do not know enough about PHP development process to have a deciding vote on PHP features. For non-deciding votes, we have community voting where pretty much anyone can vote. -- 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] [RFC] New .phpp File Type for Pure-Code PHP Scripts
2012/4/16 Tom Boutell > I think updating your RFC to cover the broad points that have changed > is worth it, even if small differences will continue to be expressed > about the syntax. > Hmm ok, I'll update it first chance I get. Keep in mind though it might still be a few days as I work during the week. --Kris
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
2012/4/16 Tom Boutell > What happens if two of them pass? > Come again? --Kris
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
I think updating your RFC to cover the broad points that have changed is worth it, even if small differences will continue to be expressed about the syntax. 2012/4/16 Kris Craig : > > > 2012/4/16 Tom Boutell >> >> Kris, you have been talking recently about allowing for a mode that >> permits the inclusion of .php from .php... something (whatever we're >> calling this middle mode's recommended file extension). >> >> I think having three modes is overkill, but some people think having >> even two modes is overkill, so I'm prepared to live with having all >> three modes (traditional PHP, "pure" PHP that is allowed to include >> traditional PHP, and "purest" PHP that is not allowed to include >> traditional PHP). >> >> After all, I don't have to use "purest" mode if I choose not to do so >> - and I suspect most library authors won't because they want to write >> code that can include whatever the user wants it to. That's their >> choice and mine, and there's really no reason to deny you the option >> of "purest" mode. >> >> And one can make the argument that while, as you say, model code >> should never include a template, controller code (or classes in the >> view layer that manage templates) should invoke templates. That would >> give a better rationale for having all three types. >> >> However, your RFC still does not address allowing all three and >> currently includes very negative language about the middle option. > > > That's because I haven't updated it since the initial draft. > >> >> >> A second issue is that your RFC calls for file extensions to be >> explicitly recognized by PHP itself, which is something many people >> have objected to because the file extension may be unavailable or >> irrelevant depending on the environment. That's why my RFC addresses >> the file extension issue as a strongly recommended convention, not a >> language feature, and provides keywords that can be used to implement >> that convention (and really ought to provide options for the various >> SAPIs as well, so entry points can be pure PHP if desired). > > > That's not actually true. What it's referring to is a convention and > distinguishing between file extensions when accessed via the webserver. > This is already the current behavior via handlers; the RFC isn't actually > proposing to parse the filename itself at the langugage level. Though > seeing as how you're the second person to have misinterpreted it to mean > that, it's possible that the wording I used wasn't clear enough on that > point. > >> >> >> I think it's probably time to write an updated version of your RFC so >> we can figure out if we're developing common ground here. > > > I was hoping to get a little more clarification on the inclusion method at > the language level before proceeding with that. Specifically, is everybody > good with using include/require as $bitwise_constant? Or do people still > think the other options need to be debated more first? > > --Kris > >> >> >> 2012/4/16 Kris Craig : >> > >> > >> > 2012/4/16 Tom Boutell >> >> >> >> Also, Kris's proposal requires that an additional flag be tracked all >> >> the way down through the stack of requires and includes from the point >> >> where pure mode is first encountered, remembering that we're in pure >> >> mode. Note that this flag cannot be a global variable because .php >> >> files that were loaded before this .phpp file are still permitted to >> >> load things, including when acting as autoloaders on behalf of .phpp >> >> code... my head hurts. This cannot be the cleanest way to solve the >> >> problem. >> >> >> >> 2012/4/16 Tom Boutell : >> >> > Oh I see. Yes, this is one of the reasons I don't like the "pure >> >> > can't >> >> > include non-pure" idea. >> >> > >> >> > Another reason: you can't write generic algorithms. PHP 5.4 has much >> >> > improved support for anonymous functions, so we should see an >> >> > increase >> >> > in libraries that take a few functions as parameters and carry out an >> >> > operation via those functions. But what if one of those functions >> >> > requires something from a .php file? Whoops, I guess it's not a >> >> > generic sorting algorithm library I just released, it's a "generic >> >> > sorting as long as none of your functions touch a .php file" >> >> > algorithm >> >> > library. And good luck figuring this out when it happens. >> >> > >> >> > Kris has pointed out that you could still load a .php file via a >> >> > function that was defined earlier in a .php file that later includes >> >> > .phpp. But this just means that, like my RFC, his RFC contains a >> >> > compromise about strictness. It's just that his compromise is more >> >> > confusing and less likely to be understood before the user gets >> >> > frustrated and declares the whole thing not worth messing with. I >> >> > think ".phpp files don't contain but can require and >> >> > include files that do" is a much clearer compromise, one that will >> >> > get >> >> > us what we want
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
What happens if two of them pass? On Mon, Apr 16, 2012 at 6:55 PM, Arvids Godjuks wrote: > 16 апреля 2012 г. 22:02 пользователь Kris Craig написал: > >> On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer > >wrote: >> >> > On 4/16/2012 3:31 AM, Arvids Godjuks wrote: >> > >> >> That's sad really, to be honest. >> >> I wonder if people even use this: >> >> >> >> echo include 'foo.bar', 'baz'; >> >>> >> >> >> > Probably not, Try it! you get: >> > >> > 1baz >> > >> > It actually works more like >> > >> > echo (include "foo.bar"), 'baz'; >> > >> > than >> > >> > >> > echo include( "foo.bar"), 'baz'; >> > >> > >> > >> > More important include doesn't currently allow multiple parms: >> > >> > include "foo.bar", 'baz'; >> > >> > Parse error: syntax error, unexpected ',' in bla.php on line xx >> > >> > >> > >> > >> > Rick >> > >> > >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> > >> I'll reiterate my position that I'm not ready to bring my RFC to a vote; >> and even if I was, the rules wouldn't allow it. In fact, unless I'm >> mistaken, none of the RFCs have met the 2-week minimum requirement yet, so >> no vote can take place at this time. But I do think we're making progress, >> so I would ask for a little extra patience from the peanut gallery for >> now. =) >> >> To Arvids' point, I'm definitely leaning in that direction, but I'd like to >> hear a little bit more from anyone who believes a different approach would >> be better. If nobody speaks-up, I'll just assume that we have consensus on >> that point and add it to the RFC. >> >> Regarding include/require, I agree that any BC break would be extremely >> minimal. In the 10+ years I've been developing PHP, I don't think I've >> ever once seen somebody include multiple scripts on a single line (I wasn't >> even aware that such a thing was allowed). So if it does pose a change, >> I'd be surprised if any existing scripts would be affected. And since this >> is a major version increment we're talking about here, I think a small >> amount of allowance can be made for low-impact BC breakage IMHO. >> >> How about we just keep the parentheses optional and comma-seperate the >> arguments? For example, the require syntax could look like this: >> >> require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)]; >> >> Possible values for $script_type: >> >> PHP_SCRIPT_TYPE_NORMAL (0x01) >> >> - If the included file contains PHP code, parse it. >> >> >> PHP_SCRIPT_TYPE_TAGLESS (0x02) >> >> - Code is assumed to be PHP throughout the script. The > E_NOTICE and the ?> tag throws E_RECOVERABLE_ERROR. >> >> >> PHP_SCRIPT_TYPE_STACK (0x04) >> >> - The $script_type is applied to all child scripts of the one being >> included. >> - Question : Would anyone see value in adding an override constant that, >> while not recommended, allows the developer to apply a different >> $script_type somewhere deeper in the stack? Personally this doesn't >> sound >> useful to me, but I'd be willing to put it in if enough of you wanted it. >> >> >> PHP_SCRIPT_TYPE_CODE_FILE (PHP_SCRIPT_TYPE_NORMAL & >> PHP_SCRIPT_TYPE_TAGLESS) >> >> - The entire script is assumed to be PHP code and is parsed accordingly. >> >> >> PHP_SCRIPT_TYPE_CODE_STACK (PHP_SCRIPT_TYPE_NORMAL & >> PHP_SCRIPT_TYPE_TAGLESS & PHP_SCRIPT_TYPE_STACK) >> >> - The entire script and all its child scripts (i.e. its "stack") are >> assumed to be PHP code and parsed accordingly. >> >> >> What do you think? >> >> --Kris >> > > I think there is no need for that many constants and types of inclusion. > Just a PHP_SCRIPT_TYPE_NORMAL and PHP_SCRIPT_TYPE_CODE will suffice (the > later just expects the header, and no other ?> or principle still applies, and it should be kept that way. Too many options > and you end up with people abusing that on purpose with reasoning "Because > I can, f**k everybody else!" (it's a "pleasure" to work with such people). > I don't like the idea of removing the mess up the syntax highlighting everywhere and annoy people that copy the > plain code without the code. -- 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] Re: Go for votes for the open tag-less PHP files
On Mon, Apr 16, 2012 at 3:55 PM, Arvids Godjuks wrote: > 16 апреля 2012 г. 22:02 пользователь Kris Craig написал: > >> On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer > >wrote: >> >> > On 4/16/2012 3:31 AM, Arvids Godjuks wrote: >> > >> >> That's sad really, to be honest. >> >> I wonder if people even use this: >> >> >> >> echo include 'foo.bar', 'baz'; >> >>> >> >> >> > Probably not, Try it! you get: >> > >> > 1baz >> > >> > It actually works more like >> > >> > echo (include "foo.bar"), 'baz'; >> > >> > than >> > >> > >> > echo include( "foo.bar"), 'baz'; >> > >> > >> > >> > More important include doesn't currently allow multiple parms: >> > >> > include "foo.bar", 'baz'; >> > >> > Parse error: syntax error, unexpected ',' in bla.php on line xx >> > >> > >> > >> > >> > Rick >> > >> > >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> > >> I'll reiterate my position that I'm not ready to bring my RFC to a vote; >> and even if I was, the rules wouldn't allow it. In fact, unless I'm >> mistaken, none of the RFCs have met the 2-week minimum requirement yet, so >> no vote can take place at this time. But I do think we're making >> progress, >> so I would ask for a little extra patience from the peanut gallery for >> now. =) >> >> To Arvids' point, I'm definitely leaning in that direction, but I'd like >> to >> hear a little bit more from anyone who believes a different approach would >> be better. If nobody speaks-up, I'll just assume that we have consensus >> on >> that point and add it to the RFC. >> >> Regarding include/require, I agree that any BC break would be extremely >> minimal. In the 10+ years I've been developing PHP, I don't think I've >> ever once seen somebody include multiple scripts on a single line (I >> wasn't >> even aware that such a thing was allowed). So if it does pose a change, >> I'd be surprised if any existing scripts would be affected. And since >> this >> is a major version increment we're talking about here, I think a small >> amount of allowance can be made for low-impact BC breakage IMHO. >> >> How about we just keep the parentheses optional and comma-seperate the >> arguments? For example, the require syntax could look like this: >> >> require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)]; >> >> Possible values for $script_type: >> >> PHP_SCRIPT_TYPE_NORMAL (0x01) >> >> - If the included file contains PHP code, parse it. >> >> >> PHP_SCRIPT_TYPE_TAGLESS (0x02) >> >> - Code is assumed to be PHP throughout the script. The > >> E_NOTICE and the ?> tag throws E_RECOVERABLE_ERROR. >> >> >> PHP_SCRIPT_TYPE_STACK (0x04) >> >> - The $script_type is applied to all child scripts of the one being >> included. >> - Question : Would anyone see value in adding an override constant that, >> >> while not recommended, allows the developer to apply a different >> $script_type somewhere deeper in the stack? Personally this doesn't >> sound >> useful to me, but I'd be willing to put it in if enough of you wanted >> it. >> >> >> PHP_SCRIPT_TYPE_CODE_FILE (PHP_SCRIPT_TYPE_NORMAL & >> PHP_SCRIPT_TYPE_TAGLESS) >> >> - The entire script is assumed to be PHP code and is parsed accordingly. >> >> >> >> PHP_SCRIPT_TYPE_CODE_STACK (PHP_SCRIPT_TYPE_NORMAL & >> PHP_SCRIPT_TYPE_TAGLESS & PHP_SCRIPT_TYPE_STACK) >> >> - The entire script and all its child scripts (i.e. its "stack") are >> >> assumed to be PHP code and parsed accordingly. >> >> >> What do you think? >> >> --Kris >> > > I think there is no need for that many constants and types of inclusion. > Just a PHP_SCRIPT_TYPE_NORMAL and PHP_SCRIPT_TYPE_CODE will suffice (the > later just expects the header, and no other ?> or principle still applies, and it should be kept that way. Too many options > and you end up with people abusing that on purpose with reasoning "Because > I can, f**k everybody else!" (it's a "pleasure" to work with such people). > I don't like the idea of removing the mess up the syntax highlighting everywhere and annoy people that copy the > plain code without the code. > Restricting it to just those two is a non-starter, period. It would unravel the compromise solution that has been worked out where three types exist. And I think a bitwise constant is the most logical approach. Keep in mind that scalability is a potential factor as well. It's possible that, at some point in the future, new ideas may emerge that add even more options to script inclusion, in which case having a flexible bit constant would allow this to scale without having to add additional arguments or other needless complexities. In this case, more constants means more flexibility for the developer IMHO. --Kris
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
16 апреля 2012 г. 22:02 пользователь Kris Craig написал: > On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer >wrote: > > > On 4/16/2012 3:31 AM, Arvids Godjuks wrote: > > > >> That's sad really, to be honest. > >> I wonder if people even use this: > >> > >> echo include 'foo.bar', 'baz'; > >>> > >> > > Probably not, Try it! you get: > > > > 1baz > > > > It actually works more like > > > > echo (include "foo.bar"), 'baz'; > > > > than > > > > > > echo include( "foo.bar"), 'baz'; > > > > > > > > More important include doesn't currently allow multiple parms: > > > > include "foo.bar", 'baz'; > > > > Parse error: syntax error, unexpected ',' in bla.php on line xx > > > > > > > > > > Rick > > > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > I'll reiterate my position that I'm not ready to bring my RFC to a vote; > and even if I was, the rules wouldn't allow it. In fact, unless I'm > mistaken, none of the RFCs have met the 2-week minimum requirement yet, so > no vote can take place at this time. But I do think we're making progress, > so I would ask for a little extra patience from the peanut gallery for > now. =) > > To Arvids' point, I'm definitely leaning in that direction, but I'd like to > hear a little bit more from anyone who believes a different approach would > be better. If nobody speaks-up, I'll just assume that we have consensus on > that point and add it to the RFC. > > Regarding include/require, I agree that any BC break would be extremely > minimal. In the 10+ years I've been developing PHP, I don't think I've > ever once seen somebody include multiple scripts on a single line (I wasn't > even aware that such a thing was allowed). So if it does pose a change, > I'd be surprised if any existing scripts would be affected. And since this > is a major version increment we're talking about here, I think a small > amount of allowance can be made for low-impact BC breakage IMHO. > > How about we just keep the parentheses optional and comma-seperate the > arguments? For example, the require syntax could look like this: > > require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)]; > > Possible values for $script_type: > > PHP_SCRIPT_TYPE_NORMAL (0x01) > > - If the included file contains PHP code, parse it. > > > PHP_SCRIPT_TYPE_TAGLESS (0x02) > > - Code is assumed to be PHP throughout the script. TheE_NOTICE and the ?> tag throws E_RECOVERABLE_ERROR. > > > PHP_SCRIPT_TYPE_STACK (0x04) > > - The $script_type is applied to all child scripts of the one being > included. > - Question : Would anyone see value in adding an override constant that, > while not recommended, allows the developer to apply a different > $script_type somewhere deeper in the stack? Personally this doesn't > sound > useful to me, but I'd be willing to put it in if enough of you wanted it. > > > PHP_SCRIPT_TYPE_CODE_FILE (PHP_SCRIPT_TYPE_NORMAL & > PHP_SCRIPT_TYPE_TAGLESS) > > - The entire script is assumed to be PHP code and is parsed accordingly. > > > PHP_SCRIPT_TYPE_CODE_STACK (PHP_SCRIPT_TYPE_NORMAL & > PHP_SCRIPT_TYPE_TAGLESS & PHP_SCRIPT_TYPE_STACK) > > - The entire script and all its child scripts (i.e. its "stack") are > assumed to be PHP code and parsed accordingly. > > > What do you think? > > --Kris > I think there is no need for that many constants and types of inclusion. Just a PHP_SCRIPT_TYPE_NORMAL and PHP_SCRIPT_TYPE_CODE will suffice (the later just expects the or
[PHP-DEV] Re: Upcoming Outage: php.net
and we're back. Sorry for the interruption. I know many of you were missing the RFC discussions and debates on Internals. I'll try not to let it happen again. ;-P If anyone sees any issues that could be related to the below, please let us know ASAP on syst...@php.net and/or https://bugs.php.net/. Thank you. On Apr 16, 2012 6:15 PM, "Daniel Brown" wrote: > Just a reminder, see the below message. > On Apr 13, 2012 3:43 PM, "Daniel Brown" wrote: > >>Greetings, all; >> >>This coming Monday, 16 April, 2012, between the hours of 18:00 and >> 20:00 EDT (22:00 to 00:00 GMT), the one of the primary php.net servers >> will be undergoing a critical preventative maintenance operation. In >> this two-hour maintenance window, we do expect a period of >> interruption lasting up to thirty minutes, during which certain core >> services will be partially or totally unavailable. >> >>The system that will experience the downtime is OSU1PHP.PHP.NET >> which, among other things, is the primary system for our mail exchange >> and master database. As such, a sample of services that will likely >> be unavailable for a short period of time will include: >> >>* Email (including mailing lists) >>* Events, user, and mirror management >>* User note submissions from userland >>* Et cetera >> >>We are informed by the on-site staff in Oregon State University's >> Open Source Lab, who quite generously provide this system >> free-of-charge, that while the maintenance is anticipated to take up >> to thirty minutes, they will be making all attempts to limit the >> downtime to a period of just five to ten minutes. >> >>My apologies for any inconvenience this may cause any of you, but >> as stated, this is critical preventative maintenance that is required >> to protect the integrity of the system, and to ensure that these >> services are not negatively impacted in the future. >> >>Please contact me directly if you have any questions or concerns. >> >>Thanks, all, and have a great weekend. >> >> -- >> >> Network Infrastructure Manager >> http://www.php.net/ >> >
Re: [PHP-DEV] voting without vcs accounts
On Mon, Apr 16, 2012 at 10:23 PM, Stas Malyshev wrote: > Hi! > > > So this time, I would like focusing only on the following: > > I think before going into these, it is important to answer this > question: what is the problem we're trying to solve? > > the voting RFC explicitly states that it is possible for (some) non-vcs users to vote, but there isn't any formal process on how can someone apply for voting karma, and what is the decision making process on this. we already had at least one formal submission ( http://www.mail-archive.com/internals@lists.php.net/msg54229.html) which went unanswered and I was also questioned on irc/twitter multiple times about how can somebody request voting karma. I would like to be able point people to the right direction about this kind of questions, but currently there is no official way of doing this. I know that some of the wiki admins are already handed out a few people voting karma, but there is no formal process, and it isn't transparent in any way. I would like to see that fixed. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Re: Upcoming Outage: php.net
Just a reminder, see the below message. On Apr 13, 2012 3:43 PM, "Daniel Brown" wrote: >Greetings, all; > >This coming Monday, 16 April, 2012, between the hours of 18:00 and > 20:00 EDT (22:00 to 00:00 GMT), the one of the primary php.net servers > will be undergoing a critical preventative maintenance operation. In > this two-hour maintenance window, we do expect a period of > interruption lasting up to thirty minutes, during which certain core > services will be partially or totally unavailable. > >The system that will experience the downtime is OSU1PHP.PHP.NET > which, among other things, is the primary system for our mail exchange > and master database. As such, a sample of services that will likely > be unavailable for a short period of time will include: > >* Email (including mailing lists) >* Events, user, and mirror management >* User note submissions from userland >* Et cetera > >We are informed by the on-site staff in Oregon State University's > Open Source Lab, who quite generously provide this system > free-of-charge, that while the maintenance is anticipated to take up > to thirty minutes, they will be making all attempts to limit the > downtime to a period of just five to ten minutes. > >My apologies for any inconvenience this may cause any of you, but > as stated, this is critical preventative maintenance that is required > to protect the integrity of the system, and to ensure that these > services are not negatively impacted in the future. > >Please contact me directly if you have any questions or concerns. > >Thanks, all, and have a great weekend. > > -- > > Network Infrastructure Manager > http://www.php.net/ >
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
On Mon, Apr 16, 2012 at 3:01 PM, Tom Boutell wrote: > Such a vote would make sense if it were clearly expressed that the > final RFC would also be subject to a binding vote, so there is no risk > of being forced to accept an implementation whose particular details > are unacceptable to you. > > On Mon, Apr 16, 2012 at 5:48 PM, Arpad Ray wrote: > > Please excuse me for butting in without immediate context. I'd just like > to > > support the idea of a vote on this concept without getting into > specifics. > > > > If the vote is positive then we can argue the various merits of the > > competing RFCs knowing that we at least agree in general. On the other > hand > > if the vote is negative, we can save a significant amount of time and > > effort, and can concentrate on more plausible subjects. > > > > Cheers, > > > > Arpad > > > > -- > 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 > > Problem is, the RFC voting process currently does not allow for this. You could take an informal vote, but I honestly don't see much value in that given that we've already invested ourselves in this. Any opinions on my idea of creating an RFC to expand the voting procedures? I'd be more than happy to draft one, but only if it's something people would actually be interested in. So far, the lack of response suggests to me that there is no interest in that, in which case we should accept the voting process as-is and vote on each RFC as a whole after the prescribed 2-week minimum discussion period. --Kris
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
2012/4/16 Tom Boutell > Kris, you have been talking recently about allowing for a mode that > permits the inclusion of .php from .php... something (whatever we're > calling this middle mode's recommended file extension). > > I think having three modes is overkill, but some people think having > even two modes is overkill, so I'm prepared to live with having all > three modes (traditional PHP, "pure" PHP that is allowed to include > traditional PHP, and "purest" PHP that is not allowed to include > traditional PHP). > > After all, I don't have to use "purest" mode if I choose not to do so > - and I suspect most library authors won't because they want to write > code that can include whatever the user wants it to. That's their > choice and mine, and there's really no reason to deny you the option > of "purest" mode. > > And one can make the argument that while, as you say, model code > should never include a template, controller code (or classes in the > view layer that manage templates) should invoke templates. That would > give a better rationale for having all three types. > > However, your RFC still does not address allowing all three and > currently includes very negative language about the middle option. > That's because I haven't updated it since the initial draft. > > A second issue is that your RFC calls for file extensions to be > explicitly recognized by PHP itself, which is something many people > have objected to because the file extension may be unavailable or > irrelevant depending on the environment. That's why my RFC addresses > the file extension issue as a strongly recommended convention, not a > language feature, and provides keywords that can be used to implement > that convention (and really ought to provide options for the various > SAPIs as well, so entry points can be pure PHP if desired). > That's not actually true. What it's referring to is a convention and distinguishing between file extensions when accessed via the webserver. This is already the current behavior via handlers; the RFC isn't actually proposing to parse the filename itself at the langugage level. Though seeing as how you're the second person to have misinterpreted it to mean that, it's possible that the wording I used wasn't clear enough on that point. > > I think it's probably time to write an updated version of your RFC so > we can figure out if we're developing common ground here. > I was hoping to get a little more clarification on the inclusion method at the language level before proceeding with that. Specifically, is everybody good with using include/require as $bitwise_constant? Or do people still think the other options need to be debated more first? --Kris > > 2012/4/16 Kris Craig : > > > > > > 2012/4/16 Tom Boutell > >> > >> Also, Kris's proposal requires that an additional flag be tracked all > >> the way down through the stack of requires and includes from the point > >> where pure mode is first encountered, remembering that we're in pure > >> mode. Note that this flag cannot be a global variable because .php > >> files that were loaded before this .phpp file are still permitted to > >> load things, including when acting as autoloaders on behalf of .phpp > >> code... my head hurts. This cannot be the cleanest way to solve the > >> problem. > >> > >> 2012/4/16 Tom Boutell : > >> > Oh I see. Yes, this is one of the reasons I don't like the "pure can't > >> > include non-pure" idea. > >> > > >> > Another reason: you can't write generic algorithms. PHP 5.4 has much > >> > improved support for anonymous functions, so we should see an increase > >> > in libraries that take a few functions as parameters and carry out an > >> > operation via those functions. But what if one of those functions > >> > requires something from a .php file? Whoops, I guess it's not a > >> > generic sorting algorithm library I just released, it's a "generic > >> > sorting as long as none of your functions touch a .php file" algorithm > >> > library. And good luck figuring this out when it happens. > >> > > >> > Kris has pointed out that you could still load a .php file via a > >> > function that was defined earlier in a .php file that later includes > >> > .phpp. But this just means that, like my RFC, his RFC contains a > >> > compromise about strictness. It's just that his compromise is more > >> > confusing and less likely to be understood before the user gets > >> > frustrated and declares the whole thing not worth messing with. I > >> > think ".phpp files don't contain but can require and > >> > include files that do" is a much clearer compromise, one that will get > >> > us what we want (an ever increasing percentage of .phpp files) without > >> > making enemies and generating opposition along the way to that better > >> > place. > >> > > >> > On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks > >> > wrote: > >> >> 16 апреля 2012 г. 16:09 пользователь Tom Boutell > >> >> написал: > >> >> > >> >>> These tools alre
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
Such a vote would make sense if it were clearly expressed that the final RFC would also be subject to a binding vote, so there is no risk of being forced to accept an implementation whose particular details are unacceptable to you. On Mon, Apr 16, 2012 at 5:48 PM, Arpad Ray wrote: > Please excuse me for butting in without immediate context. I'd just like to > support the idea of a vote on this concept without getting into specifics. > > If the vote is positive then we can argue the various merits of the > competing RFCs knowing that we at least agree in general. On the other hand > if the vote is negative, we can save a significant amount of time and > effort, and can concentrate on more plausible subjects. > > Cheers, > > Arpad -- 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] [RFC] New .phpp File Type for Pure-Code PHP Scripts
Kris, you have been talking recently about allowing for a mode that permits the inclusion of .php from .php... something (whatever we're calling this middle mode's recommended file extension). I think having three modes is overkill, but some people think having even two modes is overkill, so I'm prepared to live with having all three modes (traditional PHP, "pure" PHP that is allowed to include traditional PHP, and "purest" PHP that is not allowed to include traditional PHP). After all, I don't have to use "purest" mode if I choose not to do so - and I suspect most library authors won't because they want to write code that can include whatever the user wants it to. That's their choice and mine, and there's really no reason to deny you the option of "purest" mode. And one can make the argument that while, as you say, model code should never include a template, controller code (or classes in the view layer that manage templates) should invoke templates. That would give a better rationale for having all three types. However, your RFC still does not address allowing all three and currently includes very negative language about the middle option. A second issue is that your RFC calls for file extensions to be explicitly recognized by PHP itself, which is something many people have objected to because the file extension may be unavailable or irrelevant depending on the environment. That's why my RFC addresses the file extension issue as a strongly recommended convention, not a language feature, and provides keywords that can be used to implement that convention (and really ought to provide options for the various SAPIs as well, so entry points can be pure PHP if desired). I think it's probably time to write an updated version of your RFC so we can figure out if we're developing common ground here. 2012/4/16 Kris Craig : > > > 2012/4/16 Tom Boutell >> >> Also, Kris's proposal requires that an additional flag be tracked all >> the way down through the stack of requires and includes from the point >> where pure mode is first encountered, remembering that we're in pure >> mode. Note that this flag cannot be a global variable because .php >> files that were loaded before this .phpp file are still permitted to >> load things, including when acting as autoloaders on behalf of .phpp >> code... my head hurts. This cannot be the cleanest way to solve the >> problem. >> >> 2012/4/16 Tom Boutell : >> > Oh I see. Yes, this is one of the reasons I don't like the "pure can't >> > include non-pure" idea. >> > >> > Another reason: you can't write generic algorithms. PHP 5.4 has much >> > improved support for anonymous functions, so we should see an increase >> > in libraries that take a few functions as parameters and carry out an >> > operation via those functions. But what if one of those functions >> > requires something from a .php file? Whoops, I guess it's not a >> > generic sorting algorithm library I just released, it's a "generic >> > sorting as long as none of your functions touch a .php file" algorithm >> > library. And good luck figuring this out when it happens. >> > >> > Kris has pointed out that you could still load a .php file via a >> > function that was defined earlier in a .php file that later includes >> > .phpp. But this just means that, like my RFC, his RFC contains a >> > compromise about strictness. It's just that his compromise is more >> > confusing and less likely to be understood before the user gets >> > frustrated and declares the whole thing not worth messing with. I >> > think ".phpp files don't contain but can require and >> > include files that do" is a much clearer compromise, one that will get >> > us what we want (an ever increasing percentage of .phpp files) without >> > making enemies and generating opposition along the way to that better >> > place. >> > >> > On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks >> > wrote: >> >> 16 апреля 2012 г. 16:09 пользователь Tom Boutell >> >> написал: >> >> >> >>> These tools already strip > >>> to >> >>> support rolling in a .phpp file unmodified. Unless I am missing >> >>> something? >> >>> >> >>> Sent from my iPhone >> >>> >> >>> On Apr 15, 2012, at 5:30 PM, Arvids Godjuks >> >>> wrote: >> >>> >> >>> > I posted the bellow text in other thread, but i should have it post >> >>> > here, >> >>> > so i'm reposting it to this thread. >> >>> > >> >>> > Well, it's time for me to remind about the techique many use (and >> >>> > some >> >>> > frameworks provide it out of the box) - the application file >> >>> > concatination >> >>> > to speed up file loading. >> >>> > Yii framework provides a Yiilite.php file for this, that includes >> >>> > mostly >> >>> > used core classes in one big file.that loads much faster and is used >> >>> > for >> >>> > production. Any other framework has user extentions or other type of >> >>> > solutions for this to speed up the application, and it makes really >> >>> > big >> >>> > difference. >> >>> > So there is a goo
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
Please excuse me for butting in without immediate context. I'd just like to support the idea of a vote on this concept without getting into specifics. If the vote is positive then we can argue the various merits of the competing RFCs knowing that we at least agree in general. On the other hand if the vote is negative, we can save a significant amount of time and effort, and can concentrate on more plausible subjects. Cheers, Arpad
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
Hey guys, can we move the RFC updates back to the threads for each RFC? Subsequent discussion should go there as well. --Kris On Mon, Apr 16, 2012 at 2:30 PM, Tom Boutell wrote: > This has been added in version 1.1.1 of the > source_files_without_opening_tag RFC: > > https://wiki.php.net/rfc/source_files_without_opening_tag > > On Mon, Apr 16, 2012 at 5:25 PM, Tom Boutell wrote: > > I think the 'as' solution is smart. > > > > On Mon, Apr 16, 2012 at 3:54 PM, Kris Craig > wrote: > >> On Mon, Apr 16, 2012 at 12:51 PM, Nikita Popov < > nikita@googlemail.com>wrote: > >> > >>> On Mon, Apr 16, 2012 at 9:39 PM, Rick WIdmer < > vch...@developersdesk.com> > >>> wrote: > >>> > On 4/16/2012 1:02 PM, Kris Craig wrote: > >>> >> > >>> >> On Mon, Apr 16, 2012 at 10:31 AM, Rick > >>> >> WIdmerwrote: > >>> >>> > >>> >>> > >>> >>> More important include doesn't currently allow multiple parms: > >>> >>> > >>> >>> include "foo.bar", 'baz'; > >>> >>> > >>> >>> Parse error: syntax error, unexpected ',' in bla.php on line xx > >>> >> Regarding include/require, I agree that any BC break would be > extremely > >>> >> minimal. In the 10+ years I've been developing PHP, I don't think > I've > >>> >> ever once seen somebody include multiple scripts on a single line (I > >>> >> wasn't even aware that such a thing was allowed). > >>> > See above. It is not allowed now. > >>> > >>> I think there is a misunderstanding here. Inclusions with two > >>> arguments are currently not allowed, yes. The point is that adding > >>> such a second argument would make the grammar ambiguous. > >>> > >>> E.g, consider this: > >>> > >>> func(include 'foo', $someThing); > >>> > >>> Currently this is interpreted as the return value of 'foo' and the > >>> variable $someThing being passed to func. > >>> > >>> If you add a second argument it's unclear what this does. Is this a > >>> two-argument include? I.e. should it be interpreted as > >>> > >>> func((include 'foo', $someThing)); > >>> > >>> Or is this a one-argument include and should be interpreted as > >>> > >>> func((include 'foo'), $someThing); > >>> > >>> In my eyes such an ambiguity renders any proposal to add another > >>> argument to include completely unacceptable. > >>> > >>> The only option is to add a dedicated syntax for it like > >>> > >>> include 'foo' as $flags; > >>> > >>> Nikita > >>> > >>> -- > >>> PHP Internals - PHP Runtime Development Mailing List > >>> To unsubscribe, visit: http://www.php.net/unsub.php > >>> > >>> > >> Hmm I like that idea. Anyone see any downsides to using "as" instead of > >> comma delination? > >> > >> --Kris > > > > > > > > -- > > Tom Boutell > > P'unk Avenue > > 215 755 1330 > > punkave.com > > window.punkave.com > > > > -- > 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] Re: Go for votes for the open tag-less PHP files
This has been added in version 1.1.1 of the source_files_without_opening_tag RFC: https://wiki.php.net/rfc/source_files_without_opening_tag On Mon, Apr 16, 2012 at 5:25 PM, Tom Boutell wrote: > I think the 'as' solution is smart. > > On Mon, Apr 16, 2012 at 3:54 PM, Kris Craig wrote: >> On Mon, Apr 16, 2012 at 12:51 PM, Nikita Popov >> wrote: >> >>> On Mon, Apr 16, 2012 at 9:39 PM, Rick WIdmer >>> wrote: >>> > On 4/16/2012 1:02 PM, Kris Craig wrote: >>> >> >>> >> On Mon, Apr 16, 2012 at 10:31 AM, Rick >>> >> WIdmerwrote: >>> >>> >>> >>> >>> >>> More important include doesn't currently allow multiple parms: >>> >>> >>> >>> include "foo.bar", 'baz'; >>> >>> >>> >>> Parse error: syntax error, unexpected ',' in bla.php on line xx >>> >> Regarding include/require, I agree that any BC break would be extremely >>> >> minimal. In the 10+ years I've been developing PHP, I don't think I've >>> >> ever once seen somebody include multiple scripts on a single line (I >>> >> wasn't even aware that such a thing was allowed). >>> > See above. It is not allowed now. >>> >>> I think there is a misunderstanding here. Inclusions with two >>> arguments are currently not allowed, yes. The point is that adding >>> such a second argument would make the grammar ambiguous. >>> >>> E.g, consider this: >>> >>> func(include 'foo', $someThing); >>> >>> Currently this is interpreted as the return value of 'foo' and the >>> variable $someThing being passed to func. >>> >>> If you add a second argument it's unclear what this does. Is this a >>> two-argument include? I.e. should it be interpreted as >>> >>> func((include 'foo', $someThing)); >>> >>> Or is this a one-argument include and should be interpreted as >>> >>> func((include 'foo'), $someThing); >>> >>> In my eyes such an ambiguity renders any proposal to add another >>> argument to include completely unacceptable. >>> >>> The only option is to add a dedicated syntax for it like >>> >>> include 'foo' as $flags; >>> >>> Nikita >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> Hmm I like that idea. Anyone see any downsides to using "as" instead of >> comma delination? >> >> --Kris > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com -- 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] Re: Go for votes for the open tag-less PHP files
I think the 'as' solution is smart. On Mon, Apr 16, 2012 at 3:54 PM, Kris Craig wrote: > On Mon, Apr 16, 2012 at 12:51 PM, Nikita Popov > wrote: > >> On Mon, Apr 16, 2012 at 9:39 PM, Rick WIdmer >> wrote: >> > On 4/16/2012 1:02 PM, Kris Craig wrote: >> >> >> >> On Mon, Apr 16, 2012 at 10:31 AM, Rick >> >> WIdmerwrote: >> >>> >> >>> >> >>> More important include doesn't currently allow multiple parms: >> >>> >> >>> include "foo.bar", 'baz'; >> >>> >> >>> Parse error: syntax error, unexpected ',' in bla.php on line xx >> >> Regarding include/require, I agree that any BC break would be extremely >> >> minimal. In the 10+ years I've been developing PHP, I don't think I've >> >> ever once seen somebody include multiple scripts on a single line (I >> >> wasn't even aware that such a thing was allowed). >> > See above. It is not allowed now. >> >> I think there is a misunderstanding here. Inclusions with two >> arguments are currently not allowed, yes. The point is that adding >> such a second argument would make the grammar ambiguous. >> >> E.g, consider this: >> >> func(include 'foo', $someThing); >> >> Currently this is interpreted as the return value of 'foo' and the >> variable $someThing being passed to func. >> >> If you add a second argument it's unclear what this does. Is this a >> two-argument include? I.e. should it be interpreted as >> >> func((include 'foo', $someThing)); >> >> Or is this a one-argument include and should be interpreted as >> >> func((include 'foo'), $someThing); >> >> In my eyes such an ambiguity renders any proposal to add another >> argument to include completely unacceptable. >> >> The only option is to add a dedicated syntax for it like >> >> include 'foo' as $flags; >> >> Nikita >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > Hmm I like that idea. Anyone see any downsides to using "as" instead of > comma delination? > > --Kris -- 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] voting without vcs accounts
On Mon, Apr 16, 2012 at 2:00 PM, Nikita Popov wrote: > On Mon, Apr 16, 2012 at 10:57 PM, Kris Craig wrote: > > I reject the premise of that question because it implies that nothing in > > PHP should ever be changed unless it's "fixing" something that's broken. > > By that standard, it would be virtually impossible to get any new > features > > added. > > > > With that in mind, here's the short answer: The problem is that there > is a > > feature people are requesting that currently does not exist. > > > > The longer answer: This is not a bugfix, nor does it purport to be. > This > > is a requested new feature proposed for the next *major* PHP release > (i.e. > > 6.0). This feature will add convenience and allow developers o flexibly > > assert more control over their code structure. > I think you mixed up two threads here :) This one is about voting ;) > > Nikita > Oh, crap! You're right. Sorry, NM on that last post, everyone. I hate Mondays :/ --Kris
Re: [PHP-DEV] voting without vcs accounts
On Mon, Apr 16, 2012 at 10:57 PM, Kris Craig wrote: > I reject the premise of that question because it implies that nothing in > PHP should ever be changed unless it's "fixing" something that's broken. > By that standard, it would be virtually impossible to get any new features > added. > > With that in mind, here's the short answer: The problem is that there is a > feature people are requesting that currently does not exist. > > The longer answer: This is not a bugfix, nor does it purport to be. This > is a requested new feature proposed for the next *major* PHP release (i.e. > 6.0). This feature will add convenience and allow developers o flexibly > assert more control over their code structure. I think you mixed up two threads here :) This one is about voting ;) Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] voting without vcs accounts
On Mon, Apr 16, 2012 at 1:23 PM, Stas Malyshev wrote: > Hi! > > > So this time, I would like focusing only on the following: > > I think before going into these, it is important to answer this > question: what is the problem we're trying to solve? > > -- > 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 > > I reject the premise of that question because it implies that nothing in PHP should ever be changed unless it's "fixing" something that's broken. By that standard, it would be virtually impossible to get any new features added. With that in mind, here's the short answer: The problem is that there is a feature people are requesting that currently does not exist. The longer answer: This is not a bugfix, nor does it purport to be. This is a requested new feature proposed for the next *major* PHP release (i.e. 6.0). This feature will add convenience and allow developers o flexibly assert more control over their code structure. --Kris
Re: [PHP-DEV] release process with git
On 04/16/2012 01:12 PM, Stas Malyshev wrote: Hi! I think that once PHP-5.4.1 was branched, then PHP-5.4 should have become 5.4.2-dev. You're right. As an exercise, I submitted a pull request fixing this. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] voting without vcs accounts
Hi! > So this time, I would like focusing only on the following: I think before going into these, it is important to answer this question: what is the problem we're trying to solve? -- 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] release process with git
Hi! > I think that once PHP-5.4.1 was branched, then PHP-5.4 should have > become 5.4.2-dev. You're right. -- 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: Go for votes for the open tag-less PHP files
On Mon, Apr 16, 2012 at 12:51 PM, Nikita Popov wrote: > On Mon, Apr 16, 2012 at 9:39 PM, Rick WIdmer > wrote: > > On 4/16/2012 1:02 PM, Kris Craig wrote: > >> > >> On Mon, Apr 16, 2012 at 10:31 AM, Rick > >> WIdmerwrote: > >>> > >>> > >>> More important include doesn't currently allow multiple parms: > >>> > >>> include "foo.bar", 'baz'; > >>> > >>> Parse error: syntax error, unexpected ',' in bla.php on line xx > >> Regarding include/require, I agree that any BC break would be extremely > >> minimal. In the 10+ years I've been developing PHP, I don't think I've > >> ever once seen somebody include multiple scripts on a single line (I > >> wasn't even aware that such a thing was allowed). > > See above. It is not allowed now. > > I think there is a misunderstanding here. Inclusions with two > arguments are currently not allowed, yes. The point is that adding > such a second argument would make the grammar ambiguous. > > E.g, consider this: > > func(include 'foo', $someThing); > > Currently this is interpreted as the return value of 'foo' and the > variable $someThing being passed to func. > > If you add a second argument it's unclear what this does. Is this a > two-argument include? I.e. should it be interpreted as > > func((include 'foo', $someThing)); > > Or is this a one-argument include and should be interpreted as > > func((include 'foo'), $someThing); > > In my eyes such an ambiguity renders any proposal to add another > argument to include completely unacceptable. > > The only option is to add a dedicated syntax for it like > > include 'foo' as $flags; > > Nikita > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Hmm I like that idea. Anyone see any downsides to using "as" instead of comma delination? --Kris
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
On Mon, Apr 16, 2012 at 9:39 PM, Rick WIdmer wrote: > On 4/16/2012 1:02 PM, Kris Craig wrote: >> >> On Mon, Apr 16, 2012 at 10:31 AM, Rick >> WIdmerwrote: >>> >>> >>> More important include doesn't currently allow multiple parms: >>> >>> include "foo.bar", 'baz'; >>> >>> Parse error: syntax error, unexpected ',' in bla.php on line xx >> Regarding include/require, I agree that any BC break would be extremely >> minimal. In the 10+ years I've been developing PHP, I don't think I've >> ever once seen somebody include multiple scripts on a single line (I >> wasn't even aware that such a thing was allowed). > See above. It is not allowed now. I think there is a misunderstanding here. Inclusions with two arguments are currently not allowed, yes. The point is that adding such a second argument would make the grammar ambiguous. E.g, consider this: func(include 'foo', $someThing); Currently this is interpreted as the return value of 'foo' and the variable $someThing being passed to func. If you add a second argument it's unclear what this does. Is this a two-argument include? I.e. should it be interpreted as func((include 'foo', $someThing)); Or is this a one-argument include and should be interpreted as func((include 'foo'), $someThing); In my eyes such an ambiguity renders any proposal to add another argument to include completely unacceptable. The only option is to add a dedicated syntax for it like include 'foo' as $flags; Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
On 4/16/2012 1:02 PM, Kris Craig wrote: On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmerwrote: More important include doesn't currently allow multiple parms: include "foo.bar", 'baz'; Parse error: syntax error, unexpected ',' in bla.php on line xx Regarding include/require, I agree that any BC break would be extremely minimal. In the 10+ years I've been developing PHP, I don't think I've ever once seen somebody include multiple scripts on a single line (I wasn't even aware that such a thing was allowed). See above. It is not allowed now. How about we just keep the parentheses optional and comma-seperate the arguments? For example, the require syntax could look like this: require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)]; include/require are language constructs. They do not require () around the parms, and making it optional probably isn't reasonable. OTOH, since it currently only allows one parm, adding a second, optional parm should be no problem. -- 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
2012/4/16 Tom Boutell > Also, Kris's proposal requires that an additional flag be tracked all > the way down through the stack of requires and includes from the point > where pure mode is first encountered, remembering that we're in pure > mode. Note that this flag cannot be a global variable because .php > files that were loaded before this .phpp file are still permitted to > load things, including when acting as autoloaders on behalf of .phpp > code... my head hurts. This cannot be the cleanest way to solve the > problem. > > 2012/4/16 Tom Boutell : > > Oh I see. Yes, this is one of the reasons I don't like the "pure can't > > include non-pure" idea. > > > > Another reason: you can't write generic algorithms. PHP 5.4 has much > > improved support for anonymous functions, so we should see an increase > > in libraries that take a few functions as parameters and carry out an > > operation via those functions. But what if one of those functions > > requires something from a .php file? Whoops, I guess it's not a > > generic sorting algorithm library I just released, it's a "generic > > sorting as long as none of your functions touch a .php file" algorithm > > library. And good luck figuring this out when it happens. > > > > Kris has pointed out that you could still load a .php file via a > > function that was defined earlier in a .php file that later includes > > .phpp. But this just means that, like my RFC, his RFC contains a > > compromise about strictness. It's just that his compromise is more > > confusing and less likely to be understood before the user gets > > frustrated and declares the whole thing not worth messing with. I > > think ".phpp files don't contain but can require and > > include files that do" is a much clearer compromise, one that will get > > us what we want (an ever increasing percentage of .phpp files) without > > making enemies and generating opposition along the way to that better > > place. > > > > On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks > > wrote: > >> 16 апреля 2012 г. 16:09 пользователь Tom Boutell > написал: > >> > >>> These tools already strip to > >>> support rolling in a .phpp file unmodified. Unless I am missing > something? > >>> > >>> Sent from my iPhone > >>> > >>> On Apr 15, 2012, at 5:30 PM, Arvids Godjuks > >>> wrote: > >>> > >>> > I posted the bellow text in other thread, but i should have it post > >>> > here, > >>> > so i'm reposting it to this thread. > >>> > > >>> > Well, it's time for me to remind about the techique many use (and > some > >>> > frameworks provide it out of the box) - the application file > >>> > concatination > >>> > to speed up file loading. > >>> > Yii framework provides a Yiilite.php file for this, that includes > mostly > >>> > used core classes in one big file.that loads much faster and is used > for > >>> > production. Any other framework has user extentions or other type of > >>> > solutions for this to speed up the application, and it makes really > big > >>> > difference. > >>> > So there is a good question - how the hell in a MVC framework would i > >>> > combine my models, controllers, components and other stuff that will > >>> > definetly be as in .php so in .pphp. And not every file will be > cached > >>> > like > >>> > that - some will remain as distinct files even in production. > >>> > > >>> > The further discussion goes the more questions there is and less > answers > >>> > there are. > >> > >> > >> Yes they obviously do, but that's not what I'm concerned about. > >> What I'm concerned is that code from .php and .pphp files get's mixed in > >> together - template engine related stuff is used as much, as do > controllers, > >> session handling classes and bunch of other stuff that by definition is > >> .pphp stuff, but the template stuff is .php and it includes templates. > So > >> basically everything just has to fall back to the embedded PHP mode to > work > >> and we have no gain from the proposal what so ever - it just becomes > >> useless. > >> > >> That's not counting other issues that people and I have been voicing > and to > >> be honest, I never saw a reply to any of it. Maybe there is a reply to > >> all those questions, but they are under wall of text that usually goes > in > >> reply - that just discourages to read it at all. > > > > > > > > -- > > Tom Boutell > > P'unk Avenue > > 215 755 1330 > > punkave.com > > window.punkave.com > > > > -- > 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 > > The RFC is vague on these points because they haven't been determined yet, though I am starting to lean toward the include/require parameter option for includes. To Tom's point, these questions have already been addressed. Basically, there will be a third type that's on a per-file basis, designed to mitigate the concerns that have been expressed over making this acces
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer wrote: > On 4/16/2012 3:31 AM, Arvids Godjuks wrote: > >> That's sad really, to be honest. >> I wonder if people even use this: >> >> echo include 'foo.bar', 'baz'; >>> >> > Probably not, Try it! you get: > > 1baz > > It actually works more like > > echo (include "foo.bar"), 'baz'; > > than > > > echo include( "foo.bar"), 'baz'; > > > > More important include doesn't currently allow multiple parms: > > include "foo.bar", 'baz'; > > Parse error: syntax error, unexpected ',' in bla.php on line xx > > > > > Rick > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I'll reiterate my position that I'm not ready to bring my RFC to a vote; and even if I was, the rules wouldn't allow it. In fact, unless I'm mistaken, none of the RFCs have met the 2-week minimum requirement yet, so no vote can take place at this time. But I do think we're making progress, so I would ask for a little extra patience from the peanut gallery for now. =) To Arvids' point, I'm definitely leaning in that direction, but I'd like to hear a little bit more from anyone who believes a different approach would be better. If nobody speaks-up, I'll just assume that we have consensus on that point and add it to the RFC. Regarding include/require, I agree that any BC break would be extremely minimal. In the 10+ years I've been developing PHP, I don't think I've ever once seen somebody include multiple scripts on a single line (I wasn't even aware that such a thing was allowed). So if it does pose a change, I'd be surprised if any existing scripts would be affected. And since this is a major version increment we're talking about here, I think a small amount of allowance can be made for low-impact BC breakage IMHO. How about we just keep the parentheses optional and comma-seperate the arguments? For example, the require syntax could look like this: require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)]; Possible values for $script_type: PHP_SCRIPT_TYPE_NORMAL (0x01) - If the included file contains PHP code, parse it. PHP_SCRIPT_TYPE_TAGLESS (0x02) - Code is assumed to be PHP throughout the script. The tag throws E_RECOVERABLE_ERROR. PHP_SCRIPT_TYPE_STACK (0x04) - The $script_type is applied to all child scripts of the one being included. - Question : Would anyone see value in adding an override constant that, while not recommended, allows the developer to apply a different $script_type somewhere deeper in the stack? Personally this doesn't sound useful to me, but I'd be willing to put it in if enough of you wanted it. PHP_SCRIPT_TYPE_CODE_FILE (PHP_SCRIPT_TYPE_NORMAL & PHP_SCRIPT_TYPE_TAGLESS) - The entire script is assumed to be PHP code and is parsed accordingly. PHP_SCRIPT_TYPE_CODE_STACK (PHP_SCRIPT_TYPE_NORMAL & PHP_SCRIPT_TYPE_TAGLESS & PHP_SCRIPT_TYPE_STACK) - The entire script and all its child scripts (i.e. its "stack") are assumed to be PHP code and parsed accordingly. What do you think? --Kris
Re: [PHP-DEV] release process with git
On 04/10/2012 03: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. Stas, Currently is seems the PHP-5.4 branch is building version 5.4.1RC1-dev while the PHP-5.4.1 branch builds version 5.4.1RC2. I think that once PHP-5.4.1 was branched, then PHP-5.4 should have become 5.4.2-dev. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
On 4/16/2012 3:31 AM, Arvids Godjuks wrote: That's sad really, to be honest. I wonder if people even use this: echo include 'foo.bar', 'baz'; Probably not, Try it! you get: 1baz It actually works more like echo (include "foo.bar"), 'baz'; than echo include( "foo.bar"), 'baz'; More important include doesn't currently allow multiple parms: include "foo.bar", 'baz'; Parse error: syntax error, unexpected ',' in bla.php on line xx Rick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Ability to assign new object to a class property.
In my example the property was not static.
To make it clear - it cannot be static for this to work.
The instance of the class assigned to a property will be created when the
object is created -most likely
it will have to be done before the constructor is called so that the instance
of property is available
to constructor.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
"A Top 100 Logistics I.T. Provider in 2011"
-Original Message-
From: Simon Schick [mailto:simonsimc...@googlemail.com]
Sent: Sunday, April 15, 2012 6:47 PM
To: Dmitri Snytkine
Cc: PHP Internals
Subject: Re: [PHP-DEV] Ability to assign new object to a class property.
2012/4/13 Dmitri Snytkine :
> I always wondered why can't we do something like this in php
>
> class MyClass{
>
> private $storage = new ArrayObject();
>
> public function __construct($v){
> // whatever
> }
>
> // rest of class
>
> }
>
> Why can't we create a new object and assign it to property like this?
>
> Then when a new instance of MyClass is created the $storage variable is
> automatically assigned a new ArrayObject.
> Somethink like this is valid, possible and commonly used in Java, why not in
> php?
>
> Has anyone already asked for this to be valid syntax in php?
>
> Dmitri Snytkine
> Web Developer
> Ultra Logistics, Inc.
> Phone: (888) 220-4640 x 2097
> Fax: (888) 795-6642
> E-Mail: dsnytk...@ultralogistics.com
> Web: www.ultralogistics.com
>
> "A Top 100 Logistics I.T. Provider in 2011"
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Hi, Dmitri
Just to add a random thought
When do you expect this code to be executed?
class Foo {
static public $foo = new StdClass();
}
Sorry if this code contains syntax-errors, but I think you'll still
get the point ;)
Bye
Simon
--
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
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
For some this is sufficient, for others (like myself) getting rid of the initial wrote: > 16 апреля 2012 г. 11:05 пользователь Kris Craig написал: > >> Arvids, >> >> >> On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks > > wrote: >> >>> What happened with the proposal/RFC for expanding include/require with >>> additional optional second param to allow for developers to define in place >>> if he want's a pure PHP file to be included or a template file with direct >>> HTML output? >>> I like that proposal and take it over any other, because it gives >>> developer a choice. And if things do not go the right way and he ends up >>> screwing up somewhere - he is able to fall back to the old mode just by >>> modifying the include/require statement (and in a MVC framework with >>> autoload usage that would be 1-2 places in the whole project). >>> All that stuff with keywords, removing >> extensions require a continuous effort from the developers, additional >>> support from the IDE/editors/other tools. Do we really need all that just >>> to give people the ability to load their scripts as a pure PHP code? >>> To my mind a modification to the include/require statements is all there >>> is required to add that extra thing that Kris want's so badly and does not >>> require to change your habbits, IDE templates, waiting for IDE/editors/WEB >>> source code highlight libraries/source analyzers/etc to catch up with the >>> change. >>> There is also a question I just raised that is not yet answered that the >>> keyword/extension thing can just break the valid performance tweak >>> technique, that is used extensively in any project with big code base. >>> >> >> That may very well be the method proposed in my RFC, too. I haven't made >> up my mind on that point as I'd like to cover the pros/cons a little more >> in depth (including the potential perf issue you just raised). A handler >> approach or something similar will still be necessary as well, since one >> key reason for my RFC was to make it so that these scripts could be >> executed directly via the webserver. But as for determining how PHP itself >> can identify a .phpp file, I think the three best options are: Create new >> tags, create new keywords, or create new parameters to existing keywords. >> I keep bouncing back and forth on which one I think is best, which tells >> me that I need to hear more debate on that. Thoughts? >> >> --Kris >> >> I would encourage you to take a deep look into modifying the > include/require statements, because for all the issues popped out with > .pphp and keywords they just don't exist with include/require. And there is > no need to remove the start first thing in the file and there is no ?> at the end and hey (for my > case - my IDE removes all leading and trailing spaces on file save), your > include 'file', PHP_SOURCE_ONLY; works fine, but including a template > fails (as does an image with embedded tags uploaded through a > security hole) . > It's clean (although some BC break would occur, but I think it's minor), > simple and 100% voluntary. Any decently written 3rd party library will work > without any modification (well, removing trailing ?> is a matter of simple > script if required, but I haven't seen people putting ?> in the end for > years). -- 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] Re: Go for votes for the open tag-less PHP files
16 апреля 2012 г. 11:05 пользователь Kris Craig написал: > Arvids, > > > On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks > wrote: > >> What happened with the proposal/RFC for expanding include/require with >> additional optional second param to allow for developers to define in place >> if he want's a pure PHP file to be included or a template file with direct >> HTML output? >> I like that proposal and take it over any other, because it gives >> developer a choice. And if things do not go the right way and he ends up >> screwing up somewhere - he is able to fall back to the old mode just by >> modifying the include/require statement (and in a MVC framework with >> autoload usage that would be 1-2 places in the whole project). >> All that stuff with keywords, removing > extensions require a continuous effort from the developers, additional >> support from the IDE/editors/other tools. Do we really need all that just >> to give people the ability to load their scripts as a pure PHP code? >> To my mind a modification to the include/require statements is all there >> is required to add that extra thing that Kris want's so badly and does not >> require to change your habbits, IDE templates, waiting for IDE/editors/WEB >> source code highlight libraries/source analyzers/etc to catch up with the >> change. >> There is also a question I just raised that is not yet answered that the >> keyword/extension thing can just break the valid performance tweak >> technique, that is used extensively in any project with big code base. >> > > That may very well be the method proposed in my RFC, too. I haven't made > up my mind on that point as I'd like to cover the pros/cons a little more > in depth (including the potential perf issue you just raised). A handler > approach or something similar will still be necessary as well, since one > key reason for my RFC was to make it so that these scripts could be > executed directly via the webserver. But as for determining how PHP itself > can identify a .phpp file, I think the three best options are: Create new > tags, create new keywords, or create new parameters to existing keywords. > I keep bouncing back and forth on which one I think is best, which tells > me that I need to hear more debate on that. Thoughts? > > --Kris > > I would encourage you to take a deep look into modifying the include/require statements, because for all the issues popped out with .pphp and keywords they just don't exist with include/require. And there is no need to remove the at the end and hey (for my case - my IDE removes all leading and trailing spaces on file save), your include 'file', PHP_SOURCE_ONLY; works fine, but including a template fails (as does an image with embedded tags uploaded through a security hole) . It's clean (although some BC break would occur, but I think it's minor), simple and 100% voluntary. Any decently written 3rd party library will work without any modification (well, removing trailing ?> is a matter of simple script if required, but I haven't seen people putting ?> in the end for years).
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
Also, Kris's proposal requires that an additional flag be tracked all the way down through the stack of requires and includes from the point where pure mode is first encountered, remembering that we're in pure mode. Note that this flag cannot be a global variable because .php files that were loaded before this .phpp file are still permitted to load things, including when acting as autoloaders on behalf of .phpp code... my head hurts. This cannot be the cleanest way to solve the problem. 2012/4/16 Tom Boutell : > Oh I see. Yes, this is one of the reasons I don't like the "pure can't > include non-pure" idea. > > Another reason: you can't write generic algorithms. PHP 5.4 has much > improved support for anonymous functions, so we should see an increase > in libraries that take a few functions as parameters and carry out an > operation via those functions. But what if one of those functions > requires something from a .php file? Whoops, I guess it's not a > generic sorting algorithm library I just released, it's a "generic > sorting as long as none of your functions touch a .php file" algorithm > library. And good luck figuring this out when it happens. > > Kris has pointed out that you could still load a .php file via a > function that was defined earlier in a .php file that later includes > .phpp. But this just means that, like my RFC, his RFC contains a > compromise about strictness. It's just that his compromise is more > confusing and less likely to be understood before the user gets > frustrated and declares the whole thing not worth messing with. I > think ".phpp files don't contain but can require and > include files that do" is a much clearer compromise, one that will get > us what we want (an ever increasing percentage of .phpp files) without > making enemies and generating opposition along the way to that better > place. > > On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks > wrote: >> 16 апреля 2012 г. 16:09 пользователь Tom Boutell написал: >> >>> These tools already strip >> support rolling in a .phpp file unmodified. Unless I am missing something? >>> >>> Sent from my iPhone >>> >>> On Apr 15, 2012, at 5:30 PM, Arvids Godjuks >>> wrote: >>> >>> > I posted the bellow text in other thread, but i should have it post >>> > here, >>> > so i'm reposting it to this thread. >>> > >>> > Well, it's time for me to remind about the techique many use (and some >>> > frameworks provide it out of the box) - the application file >>> > concatination >>> > to speed up file loading. >>> > Yii framework provides a Yiilite.php file for this, that includes mostly >>> > used core classes in one big file.that loads much faster and is used for >>> > production. Any other framework has user extentions or other type of >>> > solutions for this to speed up the application, and it makes really big >>> > difference. >>> > So there is a good question - how the hell in a MVC framework would i >>> > combine my models, controllers, components and other stuff that will >>> > definetly be as in .php so in .pphp. And not every file will be cached >>> > like >>> > that - some will remain as distinct files even in production. >>> > >>> > The further discussion goes the more questions there is and less answers >>> > there are. >> >> >> Yes they obviously do, but that's not what I'm concerned about. >> What I'm concerned is that code from .php and .pphp files get's mixed in >> together - template engine related stuff is used as much, as do controllers, >> session handling classes and bunch of other stuff that by definition is >> .pphp stuff, but the template stuff is .php and it includes templates. So >> basically everything just has to fall back to the embedded PHP mode to work >> and we have no gain from the proposal what so ever - it just becomes >> useless. >> >> That's not counting other issues that people and I have been voicing and to >> be honest, I never saw a reply to any of it. Maybe there is a reply to >> all those questions, but they are under wall of text that usually goes in >> reply - that just discourages to read it at all. > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com -- 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] [RFC] New .phpp File Type for Pure-Code PHP Scripts
Oh I see. Yes, this is one of the reasons I don't like the "pure can't include non-pure" idea. Another reason: you can't write generic algorithms. PHP 5.4 has much improved support for anonymous functions, so we should see an increase in libraries that take a few functions as parameters and carry out an operation via those functions. But what if one of those functions requires something from a .php file? Whoops, I guess it's not a generic sorting algorithm library I just released, it's a "generic sorting as long as none of your functions touch a .php file" algorithm library. And good luck figuring this out when it happens. Kris has pointed out that you could still load a .php file via a function that was defined earlier in a .php file that later includes .phpp. But this just means that, like my RFC, his RFC contains a compromise about strictness. It's just that his compromise is more confusing and less likely to be understood before the user gets frustrated and declares the whole thing not worth messing with. I think ".phpp files don't contain but can require and include files that do" is a much clearer compromise, one that will get us what we want (an ever increasing percentage of .phpp files) without making enemies and generating opposition along the way to that better place. On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks wrote: > 16 апреля 2012 г. 16:09 пользователь Tom Boutell написал: > >> These tools already strip > support rolling in a .phpp file unmodified. Unless I am missing something? >> >> Sent from my iPhone >> >> On Apr 15, 2012, at 5:30 PM, Arvids Godjuks >> wrote: >> >> > I posted the bellow text in other thread, but i should have it post >> > here, >> > so i'm reposting it to this thread. >> > >> > Well, it's time for me to remind about the techique many use (and some >> > frameworks provide it out of the box) - the application file >> > concatination >> > to speed up file loading. >> > Yii framework provides a Yiilite.php file for this, that includes mostly >> > used core classes in one big file.that loads much faster and is used for >> > production. Any other framework has user extentions or other type of >> > solutions for this to speed up the application, and it makes really big >> > difference. >> > So there is a good question - how the hell in a MVC framework would i >> > combine my models, controllers, components and other stuff that will >> > definetly be as in .php so in .pphp. And not every file will be cached >> > like >> > that - some will remain as distinct files even in production. >> > >> > The further discussion goes the more questions there is and less answers >> > there are. > > > Yes they obviously do, but that's not what I'm concerned about. > What I'm concerned is that code from .php and .pphp files get's mixed in > together - template engine related stuff is used as much, as do controllers, > session handling classes and bunch of other stuff that by definition is > .pphp stuff, but the template stuff is .php and it includes templates. So > basically everything just has to fall back to the embedded PHP mode to work > and we have no gain from the proposal what so ever - it just becomes > useless. > > That's not counting other issues that people and I have been voicing and to > be honest, I never saw a reply to any of it. Maybe there is a reply to > all those questions, but they are under wall of text that usually goes in > reply - that just discourages to read it at all. -- 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] [RFC] New .phpp File Type for Pure-Code PHP Scripts
16 апреля 2012 г. 16:09 пользователь Tom Boutell написал: > These tools already strip support rolling in a .phpp file unmodified. Unless I am missing something? > > Sent from my iPhone > > On Apr 15, 2012, at 5:30 PM, Arvids Godjuks > wrote: > > > I posted the bellow text in other thread, but i should have it post here, > > so i'm reposting it to this thread. > > > > Well, it's time for me to remind about the techique many use (and some > > frameworks provide it out of the box) - the application file > concatination > > to speed up file loading. > > Yii framework provides a Yiilite.php file for this, that includes mostly > > used core classes in one big file.that loads much faster and is used for > > production. Any other framework has user extentions or other type of > > solutions for this to speed up the application, and it makes really big > > difference. > > So there is a good question - how the hell in a MVC framework would i > > combine my models, controllers, components and other stuff that will > > definetly be as in .php so in .pphp. And not every file will be cached > like > > that - some will remain as distinct files even in production. > > > > The further discussion goes the more questions there is and less answers > > there are. > Yes they obviously do, but that's not what I'm concerned about. What I'm concerned is that code from .php and .pphp files get's mixed in together - template engine related stuff is used as much, as do controllers, session handling classes and bunch of other stuff that by definition is .pphp stuff, but the template stuff is .php and it includes templates. So basically everything just has to fall back to the embedded PHP mode to work and we have no gain from the proposal what so ever - it just becomes useless. That's not counting other issues that people and I have been voicing and to be honest, I never saw a reply to any of it. Maybe there is a reply to all those questions, but they are under wall of text that usually goes in reply - that just discourages to read it at all.
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
2012/4/16 Ralph Schindler
>
> ... PHP does not invoke the autoloader to determine if the class name
> actually exists as a declaration somewhere, it simply resolves it according
> to some very specific rules (in the case of this patch, carried out by
> zend_resolve_class_name()).
>
> If I am within a namespace and am using a short name without a preceding
> "\", it means the class I am referencing exists in the current namespace.
> Whether or not that class exists is irrelevant as my short name can only
> mean "a class by this name in the current namespace". In this code:
>
> namespace Foo\Bar {
> global $foo;
> if ($foo && $foo instance Bar) {
> // ...
> }
> }
>
> ... that you, the developer, intend that your reference to Baz actually
> means "Foo\Bar\Baz", it can never mean anything else.
>
> So, in a nutshell, there is no guessing going on ;)
> -ralph
Hi, Ralph
Agree on that. I'd like to have a comment in the test, specially for
this line where you're checking for non-existing classes. It does not
seem to be obvious what should be tested here (at least it was not
obvious for me). This may make it easier to fix stuff if this test
should fail in future.
I don't know if this here is the right test to put the comment in, but
it's at least relying on something global that may change.
Thanks for giving me a deeper knowledge here :)
Bye
Simon
--
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
These tools already strip wrote: > I posted the bellow text in other thread, but i should have it post here, > so i'm reposting it to this thread. > > Well, it's time for me to remind about the techique many use (and some > frameworks provide it out of the box) - the application file concatination > to speed up file loading. > Yii framework provides a Yiilite.php file for this, that includes mostly > used core classes in one big file.that loads much faster and is used for > production. Any other framework has user extentions or other type of > solutions for this to speed up the application, and it makes really big > difference. > So there is a good question - how the hell in a MVC framework would i > combine my models, controllers, components and other stuff that will > definetly be as in .php so in .pphp. And not every file will be cached like > that - some will remain as distinct files even in production. > > The further discussion goes the more questions there is and less answers > there are. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
We could vote on whether we like the idea in principle, with the condition that the final proposal pass separately as a fully detailed rfc. That way you are telling the authors of these rfcs whether to keep trying and in what direction, but you are not forced to accept the end product. I would welcome such a vote just to end fruitless debate on the three points I mentioned. Sent from my iPhone On Apr 16, 2012, at 3:46 AM, Ferenc Kovacs wrote: > On Mon, Apr 16, 2012 at 3:39 AM, Yasuo Ohgaki wrote: > >> Hi, >> >> It would be better to vote >> >> - PHP will have script only (tag less) code or not >> >> then >> >> - How it will be implemented >> >> Regards, >> >> > That idea was raised a few times in the past, but Stas and others > expressed, they (and maybe most people) can only vote for something, if the > implementation details are tailored out (a patch is nice to have, but > not necessary), otherwise you can't measure whether that change is feasible > at all. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
Hey Simon,
As the class-definition for Moo is missing, I think it's an empty
class (like Baz) on the root-level defined somewhere else, right?
Otherwise this should do something else than guessing the class-name.
If you look at the patch, this feature is not doing anything PHP doesn't
already do in other circumstances - demonstrated by the fact that its
only about 4 lines of code ;)
In PHP, in situations like (instanceof):
if ($foo instanceof Bar)
or (catch)
} catch (SomeException $e) {
or (method signature)
public function setFoo(FooInterface $foo)
... PHP does not invoke the autoloader to determine if the class name
actually exists as a declaration somewhere, it simply resolves it
according to some very specific rules (in the case of this patch,
carried out by zend_resolve_class_name()).
If I am within a namespace and am using a short name without a preceding
"\", it means the class I am referencing exists in the current
namespace. Whether or not that class exists is irrelevant as my short
name can only mean "a class by this name in the current namespace". In
this code:
namespace Foo\Bar {
global $foo;
if ($foo && $foo instance Bar) {
// ...
}
}
... that you, the developer, intend that your reference to Baz actually
means "Foo\Bar\Baz", it can never mean anything else.
So, in a nutshell, there is no guessing going on ;)
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
hi Tom, On Sun, Apr 15, 2012 at 4:35 PM, Tom Boutell wrote: > I don't think a consensus on the following points is likely to emerge > without voting on them individually. I propose carrying out a vote > with up to three questions to be answered depending on your response > to each. We could then proceed to discuss the (relatively boring but > essential) details of keywords and extensions, if any, and create a > final RFC. > > Hopefully all parties can agree to be bound by the results of a vote > on these three questions and work together to create a final RFC that > abides by the result or let the matter drop. > > Let's briefly discuss whether these questions truly represent the > major differences between the three RFCs (not the merits of those > positions please) and then, I hope, carry out a vote on them so we can > move on. Agreed on your proposed next steps. It would rock if you could lead this effort and come up with a RFC covering the various points. I would suggest to sit down together with the other RFCs' authors and get that done. But please, no more discussions here about that. Makes no sense :) 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] Re: Go for votes for the open tag-less PHP files
16 апреля 2012 г. 11:24 пользователь Ferenc Kovacs написал:
>
>
> On Mon, Apr 16, 2012 at 9:46 AM, Arvids Godjuks
> wrote:
>
>> What happened with the proposal/RFC for expanding include/require with
>> additional optional second param to allow for developers to define in
>> place
>> if he want's a pure PHP file to be included or a template file with direct
>> HTML output?
>> I like that proposal and take it over any other, because it gives
>> developer
>> a choice.
>
>
> there is a valid issue which was discussed on irc yesterday:
> because include/require is a language construct, not a method, one is
> allowed, even advised to write the include/require calls without putting
> out the parentheses.
> if we introduce additional arguments for include/require, the following
> code will break:
> echo include 'foo.bar', 'baz';
> as currently it was interpreted as
> echo include('foo.bar'), 'baz';
> ofc. we could make that the additional params to include, require would
> only used, if the parentheses are uses, but that would make require/include
> inconsistent with every other language construct, where the parentheses is
> optional.
> so we either accept this BC, or not pursue this option, but go with the
> new functions/opcodes like include_code/require_code or similar.
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>
That's sad really, to be honest.
I wonder if people even use this:
> echo include 'foo.bar', 'baz';
> as currently it was interpreted as
> echo include('foo.bar'), 'baz';
I even didn't know it worked that way and if I saw code like this before
today I would consider it an error (I would discover that it actually
works, but I definitively would rewrite that part in two lines as distinct
operators them with ; instead of , between them)
Maybe it's not that big deal and a BC break would not impact things a lot.
What do you think?
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
I should say that I do not understand in full how it suppose to work. From the RFC it is absolutely unclear how to deal with this and the mixed code load approach is just dismissed as invalid concern, quoting from the RFC: > Besides, such an allowance is completely unnecessary anyway, since using non-horrible architecture can achieve the exact same result without having to pollute your .phpp stack. Here's a screenshot from a recent Internals thread where I illustrated this point a little more clearly: You just dismiss a valid stack structure with the screenshot below that and every PHP MVC framework I know of out there renders it's templates through a controller call or invoking a template engine of some kind in the main application and calling it's methods from controllers. Anyway the result is obvious - you have to make a global stand-alone template engine object that loads from index.php and not inside the application itself. I'm not willing to think how to couple them together and the difficulties with data passing, calling widgets and other stuff that comes along - it's just a stretch of epic proportions to radically alter the structure with unknown result in the end. So, since people write a lot about that RFC is not in sync with what you are writing, you should really update the thing. I follow the thread as much as I could, but lets be honest - following that wall of text posted every 4-5 minutes (while I read one mail the phone notified I received 2 more in the thread at times) was just not happening. So I'm convinced I skipped at least a half of the discussion just being humanly unable to read it all. The RFC should contain the solutions for the file template inclusion, 3rd party library inclusion,dealing with valid optimization practices and other related stuff. 16 апреля 2012 г. 11:09 пользователь Kris Craig написал: > > > On Mon, Apr 16, 2012 at 12:57 AM, Arvids Godjuks > wrote: > >> 16 апреля 2012 г. 2:52 пользователь Kris Craig написал: >> >> >>> >>> On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks < >>> arvids.godj...@gmail.com> wrote: >>> I posted the bellow text in other thread, but i should have it post here, so i'm reposting it to this thread. Well, it's time for me to remind about the techique many use (and some frameworks provide it out of the box) - the application file concatination to speed up file loading. Yii framework provides a Yiilite.php file for this, that includes mostly used core classes in one big file.that loads much faster and is used for production. Any other framework has user extentions or other type of solutions for this to speed up the application, and it makes really big difference. So there is a good question - how the hell in a MVC framework would i combine my models, controllers, components and other stuff that will definetly be as in .php so in .pphp. And not every file will be cached like that - some will remain as distinct files even in production. The further discussion goes the more questions there is and less answers there are. >>> >>> My response is in the other thread. But you're right, we should move >>> the discussion back here, so please post your reply here. Thanks! >>> >>> --Kris >>> >>> >> The Kris response from the "PHP-DEV Digest 13 Apr..." response to my mail >> quoted bellow: >> >> > I'm not quite sure I understand your concern. Are you saying that the >> Yii framework wouldn't work with this because .phpp files would be cached >> as .php?? If that's the case, what about .phpo? Or, perhaps we should >> name the extension .phpf instead, as in "PHP Framework-includable". >> >> What I'm saying that there is a widely used optimization technique - >> concatenate the project files in one big massive chunk, enable an opcode >> cache and things speed up big time. Almost any mid sized and above project >> ends up doing that in one or the other way. Some even do that on >> per-controller basis or otherwise - but the fact is - it's out there. >> I just gave an example of the popular framework that has this >> out-of-the-box as a feature. And I, for one, do not understand how this >> should play with your proposal, because in that state clean source code >> ends up with "tainted" source code in one big chunk of machine-generated >> striped-out-everything string of epic proportions witch PHP chews with >> happy face and damn fast (helps with response times a lot, up to the >> tenfold). >> > > What about the per-file approach that's been suggested? Would that work > with your framework? > > The stricter per-stack approach might wind up being better suited for > projects that are created from scratch with that architecture in mind. > It's common enough that I believe there's a genuine use case for it. If > we then had a separate per-file approach designed to accommodate > frameworks/libraries that by their nature might be a bit more tan
Re: [PHP-DEV] voting without vcs accounts
On Mon, Apr 16, 2012 at 4:14 AM, Ferenc Kovacs wrote: > Hi, > > I sent an email last year about this issue, but it got sidetracked (partly > it was my fault): > http://www.mail-archive.com/internals@lists.php.net/msg54267.html > So this time, I would like focusing only on the following: > > 1. What are the requirements for getting voting rights in the wiki > without having a vcs/master account? > - The voting RFC states: > - Representatives from the PHP community, that will be chosen by > those with php.net SVN accounts > - Lead developers of PHP based projects (frameworks, cms, > tools, etc.) > - regular participant of internals discussions > 2. What are the necessary steps from a volunteer to request voting > karma? > 3. How do we handle the applicants? Who will "judge" the applications? > 4. How can we see the list of the people having voting karma? Currently > only the wiki admins can see who are the people with the voting group > membership. > > > The wiki is already prepared to support voting without vcs account: there > is a voting group, anybody having membership in that group are able to vote > ( > http://git.php.net/?p=web/wiki.git;a=commit;h=e3b97f03548fab661b5bc2dd66420db1024b1f39 > ). > > My personal opinion would be that we have an application form like we have > for the vcs account request, which will send an email to the mailing list, > we can discuss here whether we support/approve the applicant or not, and > somebody with proper karma can approve/decline the application, which would > also trigger an email to the mailing list. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu I'm completely in favor of a formal process since it would mean there can be less biased and favor applied to the selection and this can eliminate the potential for people being included to vote for or against something for the purpose of overtaking the vote. I think PHP is already a very inclusive environment. Given that php.net now has edit.php.net and has streamlined the process of submitting bug reports both for documentation and language bugs I think the inclusion into the voting process as a formal outline and drafted step-by-step process will further help put PHP in a position of higher power among its neighboring communities. I propose three primary suggestions for helping formulate such a process: 1) The person requesting voting privileges in the RFC voting process should have either (a) contributed to the PHP community in a constructive and contemporary manner such as submitting helpful bug reports for docs or language bugs (did not contribute noise or repeat bugs or lack of reproducible test cases in the recent past), (b) participates in submitting patches to the PHP source repository, (c) participates in actively in php.net or wiki.php.net without a known history of disruptions among the community. 2) The person requesting voting privileges should only be allowed to make the request once every so often (such as on a monthly or quarterly, or even annual basis, for example). This will help avoid constant requests that just get turned down and avoid a load on applicants. Also, the applicant should be reviewed by their peers as well as the SVN account holders to avoid prejudice. If this is not possible it should at least be set in some fashion what guidelines/prerequisites would appeal to the potential applicant so that people can have a set expectation of what to look for before approaching such privileges. 3) Anyone who is not included in the voting process should not be turned down or discouraged from trying again (after an allotted waiting period) so as to keep the voting process lean and fair. However, I think it may also be fair to request that those re-sending a request to gain voting privileges should be required to produce some supporting evidence for their active and positive roles in their community, such as previous patches, bug report ids, mailing list archives discussions demonstrating some constructive feedback, logs, etc... I'm sure more can be made of this list in time. I just thought to start the discussion off with some constructive suggestions. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
On Mon, Apr 16, 2012 at 9:46 AM, Arvids Godjuks wrote:
> What happened with the proposal/RFC for expanding include/require with
> additional optional second param to allow for developers to define in place
> if he want's a pure PHP file to be included or a template file with direct
> HTML output?
> I like that proposal and take it over any other, because it gives developer
> a choice.
there is a valid issue which was discussed on irc yesterday:
because include/require is a language construct, not a method, one is
allowed, even advised to write the include/require calls without putting
out the parentheses.
if we introduce additional arguments for include/require, the following
code will break:
echo include 'foo.bar', 'baz';
as currently it was interpreted as
echo include('foo.bar'), 'baz';
ofc. we could make that the additional params to include, require would
only used, if the parentheses are uses, but that would make require/include
inconsistent with every other language construct, where the parentheses is
optional.
so we either accept this BC, or not pursue this option, but go with the new
functions/opcodes like include_code/require_code or similar.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
[PHP-DEV] voting without vcs accounts
Hi, I sent an email last year about this issue, but it got sidetracked (partly it was my fault): http://www.mail-archive.com/internals@lists.php.net/msg54267.html So this time, I would like focusing only on the following: 1. What are the requirements for getting voting rights in the wiki without having a vcs/master account? - The voting RFC states: - Representatives from the PHP community, that will be chosen by those with php.net SVN accounts - Lead developers of PHP based projects (frameworks, cms, tools, etc.) - regular participant of internals discussions 2. What are the necessary steps from a volunteer to request voting karma? 3. How do we handle the applicants? Who will "judge" the applications? 4. How can we see the list of the people having voting karma? Currently only the wiki admins can see who are the people with the voting group membership. The wiki is already prepared to support voting without vcs account: there is a voting group, anybody having membership in that group are able to vote ( http://git.php.net/?p=web/wiki.git;a=commit;h=e3b97f03548fab661b5bc2dd66420db1024b1f39 ). My personal opinion would be that we have an application form like we have for the vcs account request, which will send an email to the mailing list, we can discuss here whether we support/approve the applicant or not, and somebody with proper karma can approve/decline the application, which would also trigger an email to the mailing list. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On Mon, Apr 16, 2012 at 12:57 AM, Arvids Godjuks wrote: > 16 апреля 2012 г. 2:52 пользователь Kris Craig написал: > > >> >> On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks > > wrote: >> >>> I posted the bellow text in other thread, but i should have it post here, >>> so i'm reposting it to this thread. >>> >>> Well, it's time for me to remind about the techique many use (and some >>> frameworks provide it out of the box) - the application file >>> concatination >>> to speed up file loading. >>> Yii framework provides a Yiilite.php file for this, that includes mostly >>> used core classes in one big file.that loads much faster and is used for >>> production. Any other framework has user extentions or other type of >>> solutions for this to speed up the application, and it makes really big >>> difference. >>> So there is a good question - how the hell in a MVC framework would i >>> combine my models, controllers, components and other stuff that will >>> definetly be as in .php so in .pphp. And not every file will be cached >>> like >>> that - some will remain as distinct files even in production. >>> >>> The further discussion goes the more questions there is and less answers >>> there are. >>> >> >> My response is in the other thread. But you're right, we should move the >> discussion back here, so please post your reply here. Thanks! >> >> --Kris >> >> > The Kris response from the "PHP-DEV Digest 13 Apr..." response to my mail > quoted bellow: > > > I'm not quite sure I understand your concern. Are you saying that the > Yii framework wouldn't work with this because .phpp files would be cached > as .php?? If that's the case, what about .phpo? Or, perhaps we should > name the extension .phpf instead, as in "PHP Framework-includable". > > What I'm saying that there is a widely used optimization technique - > concatenate the project files in one big massive chunk, enable an opcode > cache and things speed up big time. Almost any mid sized and above project > ends up doing that in one or the other way. Some even do that on > per-controller basis or otherwise - but the fact is - it's out there. > I just gave an example of the popular framework that has this > out-of-the-box as a feature. And I, for one, do not understand how this > should play with your proposal, because in that state clean source code > ends up with "tainted" source code in one big chunk of machine-generated > striped-out-everything string of epic proportions witch PHP chews with > happy face and damn fast (helps with response times a lot, up to the > tenfold). > What about the per-file approach that's been suggested? Would that work with your framework? The stricter per-stack approach might wind up being better suited for projects that are created from scratch with that architecture in mind. It's common enough that I believe there's a genuine use case for it. If we then had a separate per-file approach designed to accommodate frameworks/libraries that by their nature might be a bit more tangled, I think we could get the best of both worlds with this. --Kris
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
Arvids, On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks wrote: > What happened with the proposal/RFC for expanding include/require with > additional optional second param to allow for developers to define in place > if he want's a pure PHP file to be included or a template file with direct > HTML output? > I like that proposal and take it over any other, because it gives > developer a choice. And if things do not go the right way and he ends up > screwing up somewhere - he is able to fall back to the old mode just by > modifying the include/require statement (and in a MVC framework with > autoload usage that would be 1-2 places in the whole project). > All that stuff with keywords, removing extensions require a continuous effort from the developers, additional > support from the IDE/editors/other tools. Do we really need all that just > to give people the ability to load their scripts as a pure PHP code? > To my mind a modification to the include/require statements is all there > is required to add that extra thing that Kris want's so badly and does not > require to change your habbits, IDE templates, waiting for IDE/editors/WEB > source code highlight libraries/source analyzers/etc to catch up with the > change. > There is also a question I just raised that is not yet answered that the > keyword/extension thing can just break the valid performance tweak > technique, that is used extensively in any project with big code base. > That may very well be the method proposed in my RFC, too. I haven't made up my mind on that point as I'd like to cover the pros/cons a little more in depth (including the potential perf issue you just raised). A handler approach or something similar will still be necessary as well, since one key reason for my RFC was to make it so that these scripts could be executed directly via the webserver. But as for determining how PHP itself can identify a .phpp file, I think the three best options are: Create new tags, create new keywords, or create new parameters to existing keywords. I keep bouncing back and forth on which one I think is best, which tells me that I need to hear more debate on that. Thoughts? --Kris
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
16 апреля 2012 г. 2:52 пользователь Kris Craig написал: > > > On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks > wrote: > >> I posted the bellow text in other thread, but i should have it post here, >> so i'm reposting it to this thread. >> >> Well, it's time for me to remind about the techique many use (and some >> frameworks provide it out of the box) - the application file concatination >> to speed up file loading. >> Yii framework provides a Yiilite.php file for this, that includes mostly >> used core classes in one big file.that loads much faster and is used for >> production. Any other framework has user extentions or other type of >> solutions for this to speed up the application, and it makes really big >> difference. >> So there is a good question - how the hell in a MVC framework would i >> combine my models, controllers, components and other stuff that will >> definetly be as in .php so in .pphp. And not every file will be cached >> like >> that - some will remain as distinct files even in production. >> >> The further discussion goes the more questions there is and less answers >> there are. >> > > My response is in the other thread. But you're right, we should move the > discussion back here, so please post your reply here. Thanks! > > --Kris > > The Kris response from the "PHP-DEV Digest 13 Apr..." response to my mail quoted bellow: > I'm not quite sure I understand your concern. Are you saying that the Yii framework wouldn't work with this because .phpp files would be cached as .php?? If that's the case, what about .phpo? Or, perhaps we should name the extension .phpf instead, as in "PHP Framework-includable". What I'm saying that there is a widely used optimization technique - concatenate the project files in one big massive chunk, enable an opcode cache and things speed up big time. Almost any mid sized and above project ends up doing that in one or the other way. Some even do that on per-controller basis or otherwise - but the fact is - it's out there. I just gave an example of the popular framework that has this out-of-the-box as a feature. And I, for one, do not understand how this should play with your proposal, because in that state clean source code ends up with "tainted" source code in one big chunk of machine-generated striped-out-everything string of epic proportions witch PHP chews with happy face and damn fast (helps with response times a lot, up to the tenfold).
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
What happened with the proposal/RFC for expanding include/require with additional optional second param to allow for developers to define in place if he want's a pure PHP file to be included or a template file with direct HTML output? I like that proposal and take it over any other, because it gives developer a choice. And if things do not go the right way and he ends up screwing up somewhere - he is able to fall back to the old mode just by modifying the include/require statement (and in a MVC framework with autoload usage that would be 1-2 places in the whole project). All that stuff with keywords, removing
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
On Mon, Apr 16, 2012 at 3:39 AM, Yasuo Ohgaki wrote: > Hi, > > It would be better to vote > > - PHP will have script only (tag less) code or not > > then > > - How it will be implemented > > Regards, > > That idea was raised a few times in the past, but Stas and others expressed, they (and maybe most people) can only vote for something, if the implementation details are tailored out (a patch is nice to have, but not necessary), otherwise you can't measure whether that change is feasible at all. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
