Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct
Or, is the purpose of the CoC really a device to control perceptions, i.e. protect the image of the PHP project and its citizens? Well, that would also be a benefit. I don't think these are exclusive goals. If PHP isn't inviting, people won't want to contribute. What I fear is that if the citizenry of Userland and PHPland do not feel at liberty to publicly and freely express their criticism of the PHP project, then important feedback will not be forthcoming, feedback that could aid in advancing PHP. Also, if taking personal responsibility for one's communication style seems like an unworthy value to subscribe to, then it seems that a BDFL might be in order. My own unsolicited 0.02 is that their should be a brief lexicon of expressions that are deemed inappropriate for discussion along with *suggested* substitutions. Those who feel only comfortable with rigid rules underestimate the power that freedom affords to the creative process. So, is this CoC really about attracting new thoughts or is it about making the status quo an even more comfortable place for those who count as part of the meritocracy? ^Z -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct
After reviewing the proposed CoC, I wonder if its good intent might boom-a-rang and have an opposite, chilling effect. I would respectfully suggest re-thinking the notion of a CoC for the PHP project. Some questions to consider: 1. Who is the CoC for, i.e. who should be its beneficiaries? Users, core contributors and maintainers? All of the above? 2. What should a CoC seek? Is it the elevation of PHP culture so that whether on the internals list or another forum there is less vulgarity and crudity and more respect? Or, is the purpose of the CoC really a device to control perceptions, i.e. protect the image of the PHP project and its citizens? If a CoC were to use language such as "guidelines" rather than the anonymous authoritative language contained in the current proposal, I think it would be more beneficial for encouraging productive discussions . We can have a more welcoming community and one in which people can feel free to share their technical thoughts even if they are far beyound the perimeter of the box if we emphasize the importance of each person taking personal responsibility for their deportment rather than attempting to dictate behavior. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Default constructors
Rather than being a bug, this matter is simply a "gotcha", one that Julien
Pauli' pointed out in his "PHP gotcha 2013" (see
https://gist.github.com/jpauli/8196145). After consulting with other
knowledgeable members of the PHP Community last year, I understand that this
is an optimization feature such that the generated opcode doesn't get
executed when the constructor is non-existent. One might not like this
"gotcha", but does it really merit being "fixed"? As a user, I like this
feature since it seems sensible if one is concerned with efficient code
execution. Whereas the undefined __construct {} permits the opcode to
execute even tho' the resulting value is useless for the class. If
anything needs to change, possibly it's the latter situation.
In sum, +1 for the option "carefully preserves it (by making a special case
for parent::__construct)"
-- SLevy
- Original Message -
From: "Rowan Collins"
To: "Stanislav Malyshev" ; "Marco Pivetta"
Cc: "PHP Internals List"
Sent: Wednesday, November 19, 2014 1:21 AM
Subject: Re: [PHP-DEV] [RFC] Default constructors
On 19 November 2014 01:50:33 GMT, Stanislav Malyshev
wrote:
Yes, that's a bug :-)
No, it is not :)
We can do it all day but I think I've explained what is going on there.
If you want to change it, feel free to do the RFC.
The point of this discussion is that there is an RFC on the table which
can be implemented in such a way that it fixes this behaviour (by
introducing a default parent, or injecting an empty constructor) or such
that it carefully preserves it (by making a special case for
parent::__construct).
If you are, as you seem to be, defending this as a feature, it implies we
should preserve (and, incidentally, standardise) it. If, as I and others
argue, it was only ever an unintended effect of the implementation, then
we should take the opportunity to correct it.
This reminds me of the recent discussion over multiple defaults in a
switch. Perhaps as with that we should phrase the question as "is there
any useful purpose to having the language standardised with this feature,
and conversely is there any realistic harm in altering it?"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
From: Andrey Andreev Sent: Sep 29, 2014 3:01 PM To: Sharon Levy Cc: Zeev Suraski , Derick Rethans , Andrea Faulds , PHP internals Subject: Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs? On Tue, Sep 30, 2014 at 12:28 AM, Sharon Levy wrote: > >> I think in all fairness, users should be required to learn C and pass a > >> test > >> demonstrating basic knowledge of PHP's internals in order to acquire voting > >> privileges. > > > >So, in order to vote, users should become (capable of being) core > >contributors? :) > >How does that change anything? > > > >Cheers, > >Andrey. "... the important truths, that knolege is power, that knolege is safety, and that knolege is happiness." -- Thomas Jefferson If more users were educated about PHP's internals, then there could be more substantive discussions between Userland and core contributors, including better ideas originating from Userland. More users might even consider becoming core contributors. It would change the status quo.
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
Last, the 2nd sub-bullet of the 2nd bullet ("regular participant of
internals discussions") is especially problematic - as it basically pulls
the barrier to entry to nothing, and is the opposite of well-defined.
When
we revise the Voting RFC, it should go IMHO. Talk is cheap - the way to
get
a vote with PHP is to contribute - be it with code, docs, testing,
frameworks or apps.
Zeev
Some years back I read the Voting RFC which stated:
"Changes made to the PHP language will affect millions of people, and
theoretically, each and every one of them should have a say in what we do.
For obvious reasons, though, this isn't a practical approach." So, Userland
is entitled but for some undelineated reason we are denied the vote.
This business of "Talk is cheap" actually means that it is far easier to say
that you're going to do something compared to actually following through and
doing it since the doing may involve quite a bit more labor, time and cost.
If talk were truly a waste of time, then there'd be little justification for
having an Internals List.
As a user myself, I feel that denying Userland voting privileges is wrong.
The truth is that while it would appear that PHP's fate lies in the hands of
its core contributors and maintainers, actually it is Userland that will
always have the final say. The worst thing is not forking PHP. What is
worst is if users were to stop using PHP.
I think in all fairness, users should be required to learn C and pass a test
demonstrating basic knowledge of PHP's internals in order to acquire voting
privileges.
S Levy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
Maybe the time has come for the adoption of some actual bylaws which succintly state who merits voting privileges and who may propose an RFC. If one reads 2.II.a of https://wiki.php.net/rfc/howto, that document indicates that the ability to propose an RFC does not automatically confer one with voting privileges, but the document is informational and and lacks the binding authority of an official bylaws. I respectfully suggest the adoption of bylaws so that it should be abundantly clear to every PHP user and contributor as to what rights each repectively has. SL - Original Message - From: "Ferenc Kovacs" To: "Hannes Magnusson" Cc: "Pierre Joye" ; "PHP Development" ; "Johannes Schlüter" ; "PHP Webmaster ML" ; "Peter Cowburn" ; "PHP Webmaster" ; "Fabien Potencier" ; "Derick Rethans" Sent: Friday, March 01, 2013 4:26 PM Subject: Re: [PHP-WEBMASTER] Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot 2013.03.01. 22:52, "Hannes Magnusson" ezt írta: On Fri, Mar 1, 2013 at 1:19 PM, Johannes Schlüter wrote: > > > Derick Rethans wrote: >>Exactly, this random apply rules nonsense needs to stop. I have nothing >> >>against Fabien voting but there is nowhere written who can vote or not >>(no, the voting RFC is too vague as well). I for one, would like to see >> >>a much stricter list of people who can vote. > > I often wonder about many names on the list of voters, there are names I have never seen ... which is really weird in my opinion. Either make it open for everybody and his dog or make a clear restriction. > Currently the easiest way to get voting karma is to say you'll be creating an RFC, as anyone with karma in that namespace can automatically vote because votes happen in that namespace. Anyones mother can create a RFC (and therefore vote on anything), but if you just want to vote then you need to get approval from internals@. That voting RFC is btw really weird, I don't know how it got accepted. "People with php.net SVN accounts that have contributed code to PHP" is particularly funny as it disqualifies everyone working on docs, websites, infrastructure and whatnot (we don't however have separate roles for your karma level, so anyone with VCS account has full wiki privileges and can therefore vote). And considering the next part: "Representatives from the PHP community, that will be chosen by those with php.net SVN accounts" Is even more awesome, as the people working on docs, websites and infrastructure can choose those community representatives - without being able to vote themselves. All they have to do is "I now pronounce you community representative. Hurray!" I like the old approach better. When no clear consensus were reached, we would vote. Anyone in the world could vote on the mailinglist, and votes were creatively interpreted grouping people with karma vs community. Doing the same with polling is however difficult. Its a whole lot easier to spot fraud emails then it is to spot people signing up with multiple wiki accounts with the intentions of skewing the results. -Hannes only people with people with php.net accounts or with manually granted voting wiki group membership can vote. I have no idea who or on what ground can hand out voting ground membership, last time when somebody requested that (William, lead of propel) went unanswered. this is how currently the wiki voting works. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Support negative indexes for arrays and strings
Greetings. >> The main problem arises from the ambiguity for $array[-1] for arrays.>> But this is easily solvable: just introduce a slice operator. >> >> $array[:-1] and the ambiguity is gone. >That would return an array containing the last item as the sole member, >not the last item itself. Which suggests a solution, namely either use another symbol or else attach to the colon a different meaning. Or, we can forget about applying this feature to arrays and hope that users will understand that this is a feature that only applies to strings and use a simple negative offset.SL
