Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct

2016-01-24 Thread Sharon Levy
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

2016-01-24 Thread Sharon Levy
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

2014-11-19 Thread Sharon Levy
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?

2014-09-30 Thread Sharon Levy


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?

2014-09-29 Thread Sharon Levy

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

2013-03-02 Thread Sharon Levy
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

2012-09-04 Thread Sharon Levy

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