Re: [PHP-DEV] [RFC] Nullable Types

[Matt Prelude]

On 14/04/16 10:59, Davey Shafik wrote:

On Thu, Apr 14, 2016 at 2:00 AM, Derick Rethans  wrote:


On Wed, 13 Apr 2016, Levi Morrison wrote:


As alluded to in an earlier email today[1] I am now moving the
Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC
proposes syntax for declaring a type to alternatively be null.

There is a decision that needs to be made: does the question mark go
before or after the type name?

 function (?Foo $foo);
 function (Foo? $foo);

There are precedents in several languages for each position. Some
relevant issues to where the question mark goes are noted in the
RFC[3].

Please put it where HHVM puts it: in front of it. Other languages are
less of an issue than a syntax that's already used in a somewhat PHP
language.

As to the rest of the RFC: LGTM!


I much prefer the "Nullable Foo" (?Foo) to "Foo or Null"  (Foo?). I find it
easier to read.

However, I am not a fan of introducing both this and the "Null" type for
union types — this should be the only way to create nullable types. We
already have too many things that are possible in more than one way.

As it sits, this is purely syntactic sugar (when taken in tandem with union
types) and [if] we agree that it is good, then let us just forgo the other
syntax entirely. I'll add a little about that on the appropriate thread.

- Davey

Also agree, the "nullable foo" reads better and has the advantage of 
compatibility
with HHVM. The easier we make it for people to switch interpreters (and 
develop

software which works on both interpreters) the better for PHP as a whole.

Also agree that we don't need null union types if we have nullable types.

- Matt


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

Re: [PHP-DEV] [RFC Discussion] Typed Properties

[Matt Prelude]

Hi,

On 16/03/16 16:36, Phil Sturgeon wrote:

2. This whole temporary nullability situation, where unset properties
will error on attempted usage if not set. Should they instead error
after the constructor has been called if they are still not holding a
value?


I'd have the error at the time of attempted use, if only because it's
easier for people trying to introduce typing to existing code.

I'd support borrowing the "?" nullable annotation from HackLang for
people who want a less strict behavior:

public ?string $name;

This means that $name can either be a string or the NULL value. It could
be argued that this encourages bad practices (using NULL to represent
errors, for example) but I think the benefits in providing easier adoption
outweigh the negatives.

Massive thumbs up from me on typed properties. Might be worth looking at
Hack's implementation as they're already doing this.

- Matt.

Re: [PHP-DEV] Adopt Ruby Code of Conduct

[Matt Prelude]

Hi,

On 19/02/16 13:08, benjamin barber wrote:

The Ruby Community Conduct Guideline
We have picked the following conduct guideline based on an early draft of
the PostgreSQL CoC, for Ruby developers community for safe, productive
collaboration. Each Ruby related community (conference etc.) may pick their
own Code of Conduct.
This document provides community guidelines for a safe, respectful,
productive, and collaborative place for any person who is willing to
contribute to the Ruby community. It applies to all “collaborative space”,
which is defined as community communications channels (such as mailing
lists, submitted patches, commit comments, etc.).

- Participants will be tolerant of opposing views.


- Participants must ensure that their language and actions are free of
personal attacks and disparaging personal remarks.


- When interpreting the words and actions of others, participants
should always assume good intentions.


- Behaviour which can be reasonably considered harassment will not be
tolerated.

This is good because it doesn't try to legally redefine harassment, and

doesn't support blacklisting based on ideological views, which is something
considered illegal many US states (like California, Oregon, Washington).
More importantly it doesn't create a inquisition to police people's
politics, they are free to be a Men's rights activist or feminist, they can
support equal rights or affirmative action, and it wont effect their code
or work abilities. Most importantly it doesn't allow a persons feelings, to
override the technical merits of a persons arguments, as critics of the
SystemD have been labeled as violating the code of conduct.

https://lists.fedoraproject.org/pipermail/users/2014-July/451692.html



What can 'reasonably' be considered harassment differs from person to 
person.


What does 'will not be tolerated' mean? Does this CoC come with a set of
teeth? Where is it enforceable?

I support the intention to avoid creating a way to police peoples' politics,
but there is ambiguity here.

- Matt.

[PHP-DEV] Karma?

[Matt Prelude]

Hi,

Where can I find out how voting karma works?

I've searched but there appears to be little in the way of a clear guide.

Keen to get involved, but not sure where to start.

- Matt.


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

Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress

[Matt Prelude]

Hi,

On 09/02/16 14:32, Rowan Collins wrote:
Having procedures for violation and not using them could still have 
value. The most famous example of this is surely nuclear weapons, 
which are frequently cited as a deterrent, not intended for actual use.


A less violent example in the UK would be the phrase which came up 
when arranging a coalition government, "avoid embarrassing the Queen" 
- the Queen has the constitutional right to appoint a Prime Minister, 
but forcing her to do so would be a major failing of the normal 
processes. Her constitutional value lies, paradoxically, in her not 
exercising any of her constitutional powers, because it forces people 
to negotiate a solution which doesn't require them.


In the context of a CoC, having some escalation procedures for if 
people refuse to compromise sharpens the minds of those involved - 
they can't just half-heartedly reply to a complaint and carry on as 
they were, but have to at least engage with the issue raised. Thinking 
about it, the same happens in many civil court cases - nobody would 
agree to an "out of court settlement" if there was no court case to be 
avoided.


So insisting on having "teeth", but assuring people that they will 
probably never be used, is a justifiable position, not a contradiction.


Regards,

Taking your nuclear weapons analogy a little further, we are now (as a
world) very concerned about making sure that the wrong people do not get
access to nuclear weapons. Whilst we cannot go back and un-invent the
nuclear weapon, we can avoid creating a punitive process which we have
to 'play politics' around to try to keep it under control.

I don't object to the idea that people who are clearly being
unconstructive can be blocked from the project. What I object to is
the proposal to make this an opaque 'secret court' where a few 'judges'
have the ability to make secret decisions based on secret reports and
secret evidence.

The community has always had the means to remove people from the process
which has, to my knowledge, been invoked in the past a small number of
times. Therefore, we already have the 'teeth' to enforce the CoC in
borderline cases, but what's being proposed is an inexplicable move from
visible and transparent 'teeth' to an opaque and closed process.

In case I was getting this all wrong, I made a pull request to remove
this secrecy from the process, which was promptly closed:

https://github.com/derickr/php-community-health/pull/37

I'd suggest that we stick with the teeth we already have, rather than
creating a new set based on an issue which has occurred a couple of times
in a decade, and always been adequately resolved.

- Matt.


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

Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress

[Matt Prelude]

Hi,

On 09/02/16 12:33, Derick Rethans wrote:

[snip]

   - Texts should be void from ambiguity.

I couldn't agree more. Ambiguity has a chilling effect on speech, and will
damage the quality of discourse on internals.

Having said that, I think that the CoC being proposed is too wordy, and 
still

quite ambiguous, some examples of statements I think are problematic:

1. "Make sure you know what you are talking about." - ambiguous and hostile
   wording, which really isn't going to change anything.
2. "It is better to be descriptive than to be concise" is in clear conflict
   with "Write ... as little as you can get away with" and both address the
   same point.
3. "never attack a person's opinion" - challenging opinions is very 
important

   in technical discussion.

I will submit a pull request later with some suggested amendments to improve
clarity and remove duplicates.

   - Although their CWG dealt with plenty of cases, no punitive action
 has occured as parties would often step back themselves. In most
 cases, a gently reminder was all that was necessary.

   - A Code of Conduct without *any* 'teeth' would not be beneficial.

These statements appear to be in direct conflict with each other.

If the Drupal CWG have not needed to impose punishments as a result of 
their

CoC, and in the history of Internals you could count the bans on one hand,
then I really don't see why we need to go to the lengths of establishing
committees and punishment procedures.

I feel that the CoC has a much greater chance of achieving consensus if 
we don't
try to impose a 'court of law' alongside it, especially considering that 
most
proposals for a 'court' have been secretive and focused on privacy 
rather than

on transparency (the opposite of all well-functioning legal systems).

   - We should be reluctant to limit the scope of the Code of Conduct and
 Contributor Guidelines.
This is an ambiguous statement, do you mean scope of enforcement (i.e. 
spaces
outside of PHP technical spaces) or something else? Would you mind 
clarifying and

also providing a brief summary of what lead to this conclusion?

Again, I think that the CoC has a much greater chance of achieving 
consensus if we

aren't trying to use it to police behavior outside of our spaces.

I feel that the "Contributor Guidelines" are now in a reasonable shape
to do a quick poll to gauge acceptability. As this is not a formal RFC
vote, it's simply done through an online poll:
http://twtpoll.com/y6hs4ndsfiki485
I've submitted a vote, not sure if I should as I don't have karma to 
vote on RFCs.


I think this is a lot better (and more technically-focused) than the 
Contributer
Covenant, so it's a step in the right direction, but I still think it 
needs some

refining to be 'production-ready'.

- Matt Prelude.




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

Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress

[Matt Prelude]

Hi Rowan,

On 09/02/16 15:24, Rowan Collins wrote:

That said, I am not convinced either
a) that the current process has any guarantee of transparency - who 
exactly has the right to block people from the list, or revoke other 
karma? what transparent process are they obliged to follow when doing so?


Here, we agree.

Nowhere in the documents does it limit the extent to which evidence can be
truncated or redacted in the name of 'privacy'.

Nowhere in the documents does it guarantee the accused a right to face the
evidence which has been brought against him/her.

Nowhere in the documents does it specify a standard of evidence, or explain
legitimate defences against accusations.

On 09/02/16 15:24, Rowan Collins wrote:
or b) that the current draft entail a "secret court" - the wording you 
filed a PR to remove talks only about anonymity of witnesses (which, 
admittedly, includes "accusers"), and makes no mention of "secret 
decisions based on secret reports and secret evidence"


These speculations are from the prior discussion of the RFC when it was
proposed by Anthony. The Contributor Covenant (which is the basis of the
Code of Conduct document) is designed to protect the identity of the
accuser, rather than the right of the accused to face the evidence against
him/her. I see these priorities as backwards.

The current wording of the 'Code of Conduct' contains the following text:

"Maintainers are obligated to maintain confidentiality with regard to both
the reporter of an incident, and the accused, and expect all parties to
assist in ensuring this."

In addition, the 'Mediation' document contains the following:

"Reasonable efforts should be taken to ensure the privacy of the reporting
party. The only two exceptions are if the incident was public or if the
reporting party agrees to be identified."

In common law (probably the most functional legal system on the planet), a
core right of the accused is to 'face his accuser', i.e. to see exactly
what he is being accused of and by whom. I would be very reluctant to
support any process which does not respect this *core* legal right.

Without the right to face the accuser, the accusation, or a guarantee that
all supporting AND contradictory evidence and testimony will be published,
this is a 'secret court' proposal.

On 09/02/16 15:24, Rowan Collins wrote:
Again, this is jumping ahead to the details of the implementation, 
which Derrick has said will be discussed at a later date.


The principle at discussion right now, is that on the face of it, 
there should be some definition of enforcement mechanism. If you 
consider the status quo to include such an enforcement mechanism, and 
do not wish to remove it, then you agree with that general principle.


With respect, I don't think that disagreeing that there is any need for a
new enforcement process is 'agreeing with' the new RFC.

- Matt.


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

Re: [PHP-DEV] Re: Karma?

[Matt Prelude]

On 09/02/16 15:31, Christoph Becker wrote:

On 09.02.2016 at 15:50 Matt Prelude wrote:


Where can I find out how voting karma works?

I've searched but there appears to be little in the way of a clear guide.

Keen to get involved, but not sure where to start.

Who can vote is described in <https://wiki.php.net/rfc/voting#who_can_vote>.


Thanks Christoph,

I was wondering more, how someone without karma can obtain karma.


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

Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress

[Matt Prelude]

Hi,

On 09/02/16 15:23, David Zuelke wrote:
I agree with Zeev here. It would be good to simplify this, and adding 
an explicit note about the inverse as well. Something like: "Debate 
issues and ideas, not the person holding them. Regardless of what side 
of a discussion you're on, realize that criticism of ideas or actions 
is distinct from criticism of a person." David 


Just my $0.02:

https://github.com/derickr/php-community-health/pull/40

I feel like we could do with something on the other side too, suggesting 
people not to act offended when people don't like their suggestions.


- Matt.


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

Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress

[Matt Prelude]

Hi,
So, rather than putting words in your mouth, I will ask the question 
directly: you say above that you do not agree that there is a need for 
a *new* enforcement process, but do you agree that there is a need for 
the *old* enforcement process to be recognised as such?


Yes, have no issue with codifying the process as long as it remains 
public & transparent.



Regards,




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

Re: [PHP-DEV] Proposal for a new array function

[Matt Prelude]

On 08/02/16 17:36, Markus Fischer wrote:

Hi,

On 08.02.16 18:06, Cesar Rodas wrote:

return array_keys($arr) !== range(0, count($arr) - 1);

`array_keys($array) === range(0, count($array)-1)`

That approach would fall flat when the numeric keys are not consecutive:

$array = [1=>"a", 3=>"b"];

Disclaimer: AFAIK complete goal of the function wasn't yet stated, thus
this could be considered /acceptable/.

cheers,
- Markus


I would read 'has_numeric_keys' as accepting any keys of type int or float.

Not sure if this was the intention, but would be my expectation from the 
method name.


- Matt.


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

Re: [PHP-DEV] Proposal for a new array function

[Matt Prelude]

Hi,

I want to propose a new PHP array method, called has_numeric_keys (or
something similar/better), that would have the following method signature:

bool has_numeric_keys(array $array)

The reason for it is to check if the array passed to it only had numeric
keys.

Why this method, when you could do it in userland PHP? Answer? Convenience.
I found, recently, that I had to perform this kind of check, when patching
Zend\Db\Sql\Insert.php. The approach I took was this:

return array_keys($arr) !== range(0, count($arr) - 1);

Not sure of my approach, I took to Twitter and received the following
suggestions, amongst others:

function isArrNum($arr) {
   foreach($arr as $i =>$v){
 if (!is_int($i)) {
   return false;
 }
   }
   return true;
}

count(array_filter(array_keys($array), 'is_string')) > 0

array_filter([...], 'is_int', ARRAY_FILTER_USE_KEY)

This convinced me that it wasn't just me seeing a valid use case for it,
and that others have implemented differing solutions when presented with
the same situation. Given that, I believe a simple, utility, function such
as this would be of help.

As for who would implement it, that would be me.
I like it. Would like to see it be a bit more generic though, something 
like (ignore the name, I can't name functions):


array_validate_keys($array, is_int);

I say this because it allows for more potential uses (that and I've done 
exactly the same to check all keys are strings before).


- Matt.


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

Re: [PHP-DEV] [RFC] Add PHP_ENGINE Constant

[Matt Prelude]

Hi,

On 03/02/16 16:54, Dan Ackroyd wrote:

On 3 February 2016 at 09:03, Davey Shafik  wrote:

Hi all,

It's actually very difficult to be able to reliably determine that you are
running the _real_ PHP runtime and not something mimicking it.

The underlying problem seems to be caused by HHVM deliberately
'faking' the results of calls to zend_version() and the existing
constants. What is there to stop any other PHP implementations from
returning 'fake' data for that function or these new constants?

And just to play devils advocate, why isn't this a problem that should
be solved in those other versions of PHP? They're the ones re-using
version strings and so causing confusion.

I can see how this could be usefulI just can't see how this would
be a permanent solution to the problem. As someone else said, this
sounds like the old detecting browsers via "user agent headers" for
browser detection. That became a complete nightmare as browsers kept
imitating each other, and so the rules about strings became less and
less useful.

Perhaps it might be helpful to justify the RFC, if you can give some
more context as to why code needs to know about what VM it is running
on?

cheers
Dan

I think Dan raises some interesting points, although I think 
zend_version() is often used for feature detection so they try to put a 
zend version in there to be helpful i.e. HHVM x.y.z === PHP a.b 
(feature-wise).


I can see how this could be useful. Would get my +1 if I had a vote.


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

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

[Matt Prelude]

Hi all,

This is my first mail to the list so please let me know if I do anything 
wrong or if there's a better channel by which to have this kind of 
discussion.


I'd like to propose adoption of an alternative code of conduct, the Go 
Code: https://golang.org/conduct


The primary reasons for suggesting this code are:

- The Go Code focuses primarily on desired behaviours ('be patient', 'be 
respectful') and only secondarily on 'avoiding destructive behaviours'.
- The Go Code explicitly notes that it "is not a mechanism for people to 
silence others with whom they disagree." - this was a major concern on 
the ML, so codifying that this usage will not be accepted in the CoC 
itself is a step in the right direction.
- The Go Code encourages everybody to follow the code in all spaces, but 
limits explicit enforcement to Go spaces.

- The Go Code is far more clear in defining prohibited behaviours.

I've already proposed this idea over at GitHub, but it strikes me that 
the correct channel for discussion is PHP internals.


- Matt


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

[PHP-DEV] VCS Account Request: mprelude

[Matt Prelude]

To contribute bugfixes to PHP.


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