Re: [PHP-DEV] Mailing list moderation

[Tony Marston]

"Thomas Punt"  wrote in message 
news:am4pr0901mb1265e675e7965065989892e5f9...@am4pr0901mb1265.eurprd09.prod.outlook.com...


Hi!


Hi,

This mail is going to both the systems group and internals mailing list.

I would like to request a mailing list suspension for the users
tonymars...@hotmail.com and li...@rhsoft.net, who have recently been
aggressively derailing the "Scalar Pseudo-type" thread, despite requests 
to

moderate their participation both in that thread, and on a number of
previous instances -- this is certainly not the first time these two 
users

have converted an RFC discussion into a dick measuring contest.


+1

They've generated so much unnecessary noise on this mailing list that
I've had to set up rules in Outlook to automatically mark their emails as
read in order to skip past them.

Let's keep discussions on the mailing list on topic and fruitful.

-Tom


You may not like what I have to say, but that is no reason to ban me from 
saying it. I believe in democracy and free speech, and by banning or 
suspending me you are effectively banning the right to free speech. As a 
long time user of PHP I earn a living by selling my software all over the 
world, so I have a vested interested in seeing that the language is not 
changed in a detrimental way. I have seen too many RFCs which do not provide 
genuine benefits for the greater PHP community, instead they pander to the 
personal whims of a vociferous minority who want to change the language to 
suit their personal coding style, or to fit their idea of purity.


As for all this so-called "dick measuring" if you bothered to read the posts 
you should see that I try to keep my comments as civil as possible, but when 
some prat attacks me personally on this list then I have the right to defend 
myself. You should focus your attention of those who make personal attacks 
and not those who are defending themselves.


--
Tony Marston


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

Re: [PHP-DEV] Mailing list moderation

[Stanislav Malyshev]

Hi!

> You may not like what I have to say, but that is no reason to ban me
> from saying it. I believe in democracy and free speech, and by banning
> or suspending me you are effectively banning the right to free speech.

This has nothing to do with free speech. You are welcome to exercise
your rights to free speech any way you like. But you don't have the
rights to be in the list if the community does not want it and if your
behavior is unhelpful and un-conductive to the discussion. In that case,
you'd have to exercise your rights to free speech somewhere else. I am
sure the world of democracy will survive this. This, of course, is not
specific to anybody personally - anybody who does not think they can
abide by the rules of civilized discussion on the list could exercise
their free speech rights in other venues, of which there's always an
abundance. Polite, substantial, productive discussion is welcome - we do
not have any barriers or prerequisites for participation. Noise is not
welcome.

Nobody wants to see the noise on the list, and nobody wants to see yet
more noise by discussing who started it and who kicked or spat first and
who broke whose sand castle. Everybody must behave, or take a time out
and relax and think about more pleasant matters until they are able to
be polite again. Again, not about anybody personally, applies to all.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Niklas Keller]

Hey Michael,

I don't think the BC break is acceptable. You argue that scalar type
declarations are relatively new, but in fact they're already years old now.
They're used in most PHP 7+ packages. Even if changing types might be
discouraged, it still happens a lot.

Regards, Niklas

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Wed, Jan 3, 2018 at 3:50 AM, Niklas Keller  wrote:

> Hey Michael,
>
> I don't think the BC break is acceptable. You argue that scalar type
> declarations are relatively new, but in fact they're already years old now.
> They're used in most PHP 7+ packages. Even if changing types might be
> discouraged, it still happens a lot.
>

Hmm.  Well, that aspect of this can be dropped. What about the rest of it?

Re: [PHP-DEV] Mailing list moderation

[Tony Marston]

"Stanislav Malyshev"  wrote in message 
news:cc1f4670-d201-5a06-7309-a2386f819...@gmail.com...


Hi!


You may not like what I have to say, but that is no reason to ban me
from saying it. I believe in democracy and free speech, and by banning
or suspending me you are effectively banning the right to free speech.


This has nothing to do with free speech. You are welcome to exercise
your rights to free speech any way you like. But you don't have the
rights to be in the list if the community does not want it and if your
behavior is unhelpful and un-conductive to the discussion.


I can understand you banning or suspending someone because of personal abuse 
or offensive/foul language, but banning someone simply because you don't 
like what they say is a step too far. If this is allowed to happen then soon 
you will get to stage where someone says "Anyone who disagrees with my point 
of view is an idiot and should be banned from this list".



In that case,
you'd have to exercise your rights to free speech somewhere else. I am
sure the world of democracy will survive this. This, of course, is not
specific to anybody personally - anybody who does not think they can
abide by the rules of civilized discussion


Define "civilised". Anything which does not use foul or abusive language 
should be regarded as civilised. Expressing an unpopular opinion is still 
civilised. Anyone who tries to ban unpopular opinions should not be welcome 
on any list as this prevents proper discussion.



on the list could exercise
their free speech rights in other venues, of which there's always an
abundance. Polite, substantial, productive discussion is welcome - we do
not have any barriers or prerequisites for participation. Noise is not
welcome.


There are too many delicate people on this list who regard any opinion which 
differs from theirs as "noise".



Nobody wants to see the noise on the list, and nobody wants to see yet
more noise by discussing who started it and who kicked or spat first and
who broke whose sand castle.


I suggest you start by aiming your wrath at those who move off-topic and 
start making personal attacks instead of those who defend themselves from 
such attacks.



Everybody must behave, or take a time out
and relax and think about more pleasant matters until they are able to
be polite again. Again, not about anybody personally, applies to all.



--
Tony Marston


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

Re: [PHP-DEV] Mailing list moderation

[Sanford Whiteman]

Tony, you have a point in the sense that a proposed Code of Conduct --
which would have been binding on posts to lists @php.net -- provoked a
fiery   debate  (to  put  it  mildly)  and  was  eventually  withdrawn
(http://news.php.net/php.internals/90726).

The  dominant  objections  to  the  CoC  did  not  focus on relatively
apolitical  cases  like  calling  someone  a habitual liar or implying
non-augmented  humans  can  write bug-free code. Yet the point remains
that there is no doc whose letter or spirit can be debated, AFAIK.

As  Stas  points  out,  having  a CoC for the list would not be a free
speech  issue  in  the  wider  sense.  But  in the *absence* of such a
yardstick,  I  do  agree  with  you  that  there's  nothing to justify
ejecting you from the list.

You  obviously  love using PHP and do not come here simply to bash the
language  (to me, that would be grounds for ejection because one would
not  legitimately be joining the community, in essence a spam signup).
While  I don't agree with your technical viewpoint in the recent flame
war,  perhaps  you  do still have the right to express it here without
fear of suspension/ejection.

But  consider this takeaway: while you may not realize it since you're
in  too  deep  at present, the (scalar-pseudo-type-related) war you're
currently  in  with  the  other  fellow  has  devolved into silliness.
Neither of you are in my killfile; more the reverse, as it's become so
over-the-top that it's funny.

I  know,  though,  that  you  take this topic seriously -- but the way
things are going are entirely comedic, with accusations of fabulism (I
don't  know  where  that's  from) met by accusations of lack of coding
skill  (just  as  unlikely  for  a  longtime  Internals  participant).
Assuming  you'd  rather  we  take  the technical aspects of the debate
seriously, for that reason alone it's worth a reset and a rethink.

—— S.

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

[PHP-DEV] Re: Mailing list moderation

[Rasmus Lerdorf]

Ok, both have been added to the ezmlm deny list for internals

On Tue, Jan 2, 2018 at 2:49 AM, Nikita Popov  wrote:

> Hi,
>
> This mail is going to both the systems group and internals mailing list.
>
> I would like to request a mailing list suspension for the users
> tonymars...@hotmail.com and li...@rhsoft.net, who have recently been
> aggressively derailing the "Scalar Pseudo-type" thread, despite requests to
> moderate their participation both in that thread, and on a number of
> previous instances -- this is certainly not the first time these two users
> have converted an RFC discussion into a dick measuring contest.
>
> If these users cannot be suspended, I would like to request specific
> instructions under what circumstances users can be suspended from the
> internals list, and what procedures need to be followed to achieve this.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] Mailing list moderation

[Paul Jones]

> On Jan 2, 2018, at 12:29, Dustin Wheeler  wrote:
> 
> On Tue, Jan 2, 2018 at 12:19 PM, Levi Morrison  wrote:
>> 
>> I doubt we have any official procedures. I agree with the proposed
>> suspension as long as the suspension for a set amount of time; I
>> believe in giving people a chance to reform. If they can't reform...
>> well then I'm fine with an indefinite suspension.

I am not in favor of anyone else deciding for me that I am not allowed to see 
Tony's (or anyone else's) messages on this list. I can make that decision 
myself, and revisit that decision myself should I choose.

If someone dislikes Tony's commentary for any reason (or no reason!) they are 
free to filter his messages themselves -- and then unfilter his messages when 
they see fit.


-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php


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

Re: [PHP-DEV] Mailing list moderation

[Chase Peeler]

On Wed, Jan 3, 2018 at 10:49 AM Paul Jones  wrote:

>
> > On Jan 2, 2018, at 12:29, Dustin Wheeler  wrote:
> >
> > On Tue, Jan 2, 2018 at 12:19 PM, Levi Morrison  wrote:
> >>
> >> I doubt we have any official procedures. I agree with the proposed
> >> suspension as long as the suspension for a set amount of time; I
> >> believe in giving people a chance to reform. If they can't reform...
> >> well then I'm fine with an indefinite suspension.
>
> I am not in favor of anyone else deciding for me that I am not allowed to
> see Tony's (or anyone else's) messages on this list. I can make that
> decision myself, and revisit that decision myself should I choose.
>
> If someone dislikes Tony's commentary for any reason (or no reason!) they
> are free to filter his messages themselves -- and then unfilter his
> messages when they see fit.
>
>
> --
> Paul M. Jones
> pmjone...@gmail.com
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/ 




I agree with Paul. It would be different if email clients that allowed
filtering were expensive or hard to find. They aren’t, though. Pretty much
every email client not only allows filtering, but rather advanced filtering
as well.

Instead of suspending users, no matter how egregious their offenses may be,
let individual users filter them out as they see fit.

> 

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Mailing list moderation

[Andreas Heigl]

Am 03.01.18 um 10:55 schrieb Sanford Whiteman:
> Tony, you have a point in the sense that a proposed Code of Conduct --
> which would have been binding on posts to lists @php.net -- provoked a
> fiery   debate  (to  put  it  mildly)  and  was  eventually  withdrawn
> (http://news.php.net/php.internals/90726).
> 
> The  dominant  objections  to  the  CoC  did  not  focus on relatively
> apolitical  cases  like  calling  someone  a habitual liar or implying
> non-augmented  humans  can  write bug-free code. Yet the point remains
> that there is no doc whose letter or spirit can be debated, AFAIK.

May I point to the headline "Mailing List Posting Guideline" at the
Mailing-List page[0]? Especially the references to the
README.MAILINGLIST_RULES[1] right at the end? Which in turn references
RFC 1855[2]?

So I'd say there actually *is* even more than one doc whose letter or
spirit can be debated. But debating is one thing, taking action is
another one.

Just my 0.02€

Cheers

Andreas

[0] http://php.net/mailing-lists.php
[1]
http://git.php.net/?p=php-src.git;a=blob_plain;f=README.MAILINGLIST_RULES;hb=HEAD
[2] http://www.faqs.org/rfcs/rfc1855.html
-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Mailing list moderation

[Johannes Schlüter]

On Di, 2018-01-02 at 11:49 +0100, Nikita Popov wrote:
> li...@rhsoft.net, who have recently been
> aggressively derailing 

He was blocked in 2012 already:

https://externals.io/message/59395#59421

johannes


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

Re: [PHP-DEV] Mailing list moderation

[Andrey Andreev]

Hi,

On Wed, Jan 3, 2018 at 6:05 PM, Chase Peeler  wrote:
>
> I agree with Paul. It would be different if email clients that allowed
> filtering were expensive or hard to find. They aren’t, though. Pretty much
> every email client not only allows filtering, but rather advanced filtering
> as well.
>
> Instead of suspending users, no matter how egregious their offenses may be,
> let individual users filter them out as they see fit.
>

You have a point, but also have it in mind that we're talking about
individuals participating in a discussion thread, and that's not the
same as filtering out spam email or a news category that you're not
interested in.

Cheers,
Andrey.

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

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Wed, Jan 3, 2018 at 3:26 PM, Rowan Collins 
wrote:

> Hi Michael,
>
> On 02/01/2018 10:35, Michael Morris wrote:
>
>> I would like to propose a clean way to add some strong typing to PHP in a
>> manner that is almost fully backward compatible (there is a behavior
>> change
>> with PHP 7 type declarations). As I don't have access to the add RFC's to
>> the wiki I'll place this here.
>>
>
> Thanks for putting this together. Perhaps unlike Andreas, I think it is
> good to look at typing changes as a unified framework, rather than
> considering "typed properties", "typed variables", etc, as separate
> concerns. If we don't, there is a real risk we'll end up making decisions
> now that hobble us for future changes, or over-complicating things in one
> area because we're not yet ready to make changes in another.
>

My thoughts exactly. PHP already has enough warts born of piecemeal design
- a cursory look at the PHP string functions shows this very well. We have
functions with haystack/needle and needle/haystack. Some function names are
_ delimited, some aren't (or were meant to be camel cased but since PHP
function labels aren't case sensitive), and so on.  When I see an RFC based
on types it worries me precisely because without a core plan of action we
are inviting more language fragmentation.


>
> My own thoughts on the subject from a while ago are here:
> http://rwec.co.uk/q/php-type-system In that post, I borrowed the term
> "container" from Perl6 for the conceptual thing that type constraints are
> stored against; in PHP's case, this would include variables, object
> properties, class static properties, function parameters, and return
> values. I think a good plan for introducing typing is one that considers
> all of these as equals.
>
>
That was one of the most enjoyable reads I've had in awhile and I can't
think of anything there I disagree with. I'm still working through your
references for how Python is handling things and the treatise on the nature
of types.


> The biggest issue with any proposal, though, is going to be performance. I
> don't think this is an incidental detail to be dealt with later, it is a
> fundamental issue with the way type hints in PHP have evolved. PHP is
> extremely unusual, if not unique, in exclusively enforcing type constraints
> at runtime. Other languages with "gradual typing" such as Python, Hack, and
> Dart, use the annotations only in separate static analysers and/or when a
> runtime debug flag is set (similar to enabling assertions).
>
>
Has the bus already left the station forever on this?

I think it's clear that what we are discussing here can't go into effect
before PHP 8. Further, it could very well be on of if not the key feature
of PHP 8. In majors backwards compatibility breaks are considered were
warranted.

I'm not familiar with the Zend Engine as I probably should be. I bring the
perspective of an end user. From what you've posted am I correct in stating
that PHP Type Hints / scalar Type Declarations are in truth syntactic sugar
for asserting the type checks.  Hence we read this

function foo( ClassA $a, ClassB $b, string $c ) {}

But the engine has to do the work of this...

function foo ( $a, $b, $c ) {
  assert( $a instanceof ClassA, TypeError );
  assert( $b instanceof ClassB, TypeError );
  assert( is_string($c), InvalidArgument );
}

If that is indeed the case, why not disable these checks according to the
zend.assertions flag, or if that's too bold a move create a php.ini flag
that allows them to be disabled in production.

Existing code would be unaffected if it has been fully debugged because, in
accordance with the principles of Design by Contract, a call with an
illegal type should be impossible. For code that isn't up to par though we
have the possibility of data corruption when the code proceeds past the
call to wherever the reason for that type hint is. I'll hazard that most of
the time that will be a call to method on non-object or something similar.

PHP programmers however would need to get used to the idea that their type
hints mean nothing when assertions are turned off (or if handled by a
separate flag, when that flag is turned off).  I'm ok with this, but I'm a
big proponent of Design by Contract methodology as a supplement to Test
Driven Design.

Another thing to consider is that if the existing type hints are so
expensive, this change might grant a welcome speed boost.

Extending that to all containers means every assignment operation would
> effectively need to check the value on the right-hand-side against the
> constraint on the left-hand-side. Some of those checks are non-trivial,
> e.g. class/interface constraints, callable; or in future maybe "array of
> Foo", "Foo | Bar | int", "Foo & Bar", etc. There are ways to ease this a
> bit, like passing around a cache of type constraints a value has passed,
> but I think we should consider whether the "always-on runtime assertions"
> model is the one we 

Re: [PHP-DEV][RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

Second Draft based on the feedback upstream.

Target version: PHP 8.

This is a proposal to strengthen the dynamic type checking of PHP during
development.

Note - this is not a proposal to change PHP to a statically typed language
or to remove PHP's current loose typing rules. PHP is a weakly typed
language for a reason, and will remain so subsequent to this RFC. This RFC
is concerned with providing tools to make controlling variable types
stronger when the programmer deems this necessary.



VARIABLE DECLARATION

PHP currently has no keyword to initialize a variable - it is simply
created when it is first referenced. The engine infers the appropriate type
for the variable, and this may be later cast to other types depending on
the context of the code. Objects can have magic functions to carry out this
casting such as __toString.

It is sometimes useful to explicitly state a variable's type. One case is
when the engine might incorrectly infer the type. For example "073117" is a
valid octal integer but also a date string in mmddyy format, so a
comparison with another date string in the same format could be... amusing.
While there is a string comparison function, that functions presence is
borne of the fact that we can't reliably compare "073117" with say,
"010216" because of the int casting possibility.

Since the scalar types have already been reserved as keywords they can be
used to declare variables in a manner not unlike C or Java.

int $a = 073117;

The var keyword is still around from PHP 4 days but is going unused.  In
JavaScript var is used to formally declare a variable though it isn't
required (It remains important because without it JavaScript will search
the scope chain of the current closure all the way to the top scope. If it
doesn't find the reference it only then creates one. This can lead to huge
headaches so the creation of variables without using var is strongly
discouraged in JavaScript).

Since the keyword is available, let's make use of it.

var $a = "123";

What I propose this will do is formally declare $a, infer it's type, then
LOCK the type from casting. If further assignments are made to the variable
the quantity being assigned will be cast to type desired if possible,
otherwise a type error will be raised.

var string $a = $_POST['date'];

This syntax allows the programmer to choose the type rather than allowing
the engine to infer it. Here $_POST['date'] might be provided in date
string that might be confused for an octal int.

This magical casting is suggested because it follows the spirit of PHP, but
it may not be strict enough. For those the type can be explicitly declared
without using the var keyword as follows.

int $a = 4;

In this event a type error will occur on any attempt to assign a value to
$a that isn't an int.

The variable can still be re-declared in both cases so.

var $a = 4;
string $a = "Hello";

The var keyword can be combined with the new keyword to lock an object
variable so it doesn't accidentally change

var $a = new SomeClass();

As noted above a deliberate redeclare can still change the type of $a.



ARRAYS
All members of an array can be cast to one type using this syntax

var string array $a = [ 'Mary', 'had', 'a', 'little', 'lamb' ];
int array $b = [1,2,3,5];

Or members can be individually cast

var $a = [ var 'Todd', var 'Alex' ];
$b = [string 'id' => int 1, 'name' => string 'Chad'];

Again, following rules similar to the above.  The main reason for doing
this is to insure smooth interaction with the pack and splat operators.

function foo (var string array $a = ...);

And speaking of functions, that's the next section.



FUNCTION DECLARATION

Variables are also declared as arguments to functions.  I propose using the
var keyword to lock the resulting variable and perform a cast if possible.

function foo( var string $a, var $b ) {}

Note that using var without explicitly calling type will be legal if rarely
used for consistency reasons. Also, someone might have a use for an
argument who's type could be anything, but won't change after it is
received.

The type can also be inferred from the default.

function foo( var $a = "hello" ) {}

This syntax is essentially doing a redeclare of the variable. This could be
very troublesome with references, so a Type error will result if this is
tried.

function foo ( var &$a = "Hello" ) {}

$b = 3;
foo($b);

With objects the var keyword can be used to prevent the function from
changing the object.

function foo ( var SomeClass $a ) {}





CLASS MEMBER DECLARATION

Variables also appear as object members. Following the pattern established
above their types can be locked. A couple note though

class SomeClass {

  var $a = '3';
  public var $b = 'hello';

}

For backwards compatibility the var keyword by itself must be equivalent to
"public". It is only when a scope operator is present that var takes on its
new meaning in this context.

Magic __set and __get cannot access variables with locked types because,

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Andreas Hennings]

This proposal contains some interesting ideas, which I see as separate:
1. A syntax to declare the type of local variables.
2. A syntax to declare the type of object properties.
3. Preventing local variables, object properties and parameters to
change their type after initialization/declaration.

For me the point 3 is the most interesting one.
I think the other points are already discussed elsewhere in some way,
although they are clearly related to 3.

Point 3 would be a BC break, if we would introduce it for parameters.
Current behavior: https://3v4l.org/bjaLQ

Local variables and object properties currently cannot be types, so
point 3 would not be a BC break for them, if we introduce it together
with 1 and 2.
But then we would have an inconsistency between parameters and local
vars / object properties.

What we could do to avoid BC break is to introduce
declare(fixed_parameter_types=1) in addition to
declare(strict_types=1).
For local variables and object properties, the type would always be fixed.
But for parameters, it would only be fixed if the
declare(fixed_parameter_types=1) is active.

Maybe to make it less verbose, we could say declare(strict_types=2),
which would mean the combination of both those things?
Or some other type of shortcut.
I think we will have to think about shortcuts like this if we
introduce more "modes" in the future.


> Currently the var keyword is used to formally declare a variable.

Are you talking about local variables?
In which PHP version? https://3v4l.org/o0PFg

Afaik, currently var is only used for class/object properties from the
time when people did not declare the visibility as
public/protected/private.


> If the type is omitted, scalar is assumed.  If Fleshgrinder's scalar RFC is
> accepted then it would make sense to allow programmers to explicitly
> declare the variable as a scalar, but in any event when the type is omitted
> scalar must be assumed for backwards compatibility.

If no type is specified, then "mixed" should be assumed, not "scalar".
Assuming "scalar" would be a BC break, and it would be confusing.


On 3 January 2018 at 10:03, Michael Morris  wrote:
> On Wed, Jan 3, 2018 at 3:50 AM, Niklas Keller  wrote:
>
>> Hey Michael,
>>
>> I don't think the BC break is acceptable. You argue that scalar type
>> declarations are relatively new, but in fact they're already years old now.
>> They're used in most PHP 7+ packages. Even if changing types might be
>> discouraged, it still happens a lot.
>>
>
> Hmm.  Well, that aspect of this can be dropped. What about the rest of it?

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

Re: [PHP-DEV] Mailing list moderation

[Chase Peeler]

On Wed, Jan 3, 2018 at 11:16 AM Andrey Andreev  wrote:

> Hi,
>
> On Wed, Jan 3, 2018 at 6:05 PM, Chase Peeler 
> wrote:
> >
> > I agree with Paul. It would be different if email clients that allowed
> > filtering were expensive or hard to find. They aren’t, though. Pretty
> much
> > every email client not only allows filtering, but rather advanced
> filtering
> > as well.
> >
> > Instead of suspending users, no matter how egregious their offenses may
> be,
> > let individual users filter them out as they see fit.
> >
>
> You have a point, but also have it in mind that we're talking about
> individuals participating in a discussion thread, and that's not the
> same as filtering out spam email or a news category that you're not
> interested in.
>
> Cheers,
> Andrey.
>

Are you saying you can't configure your client to delete/move to another
folder any emails with a subject beginning with [PHP-DEV] that are sent
from tonymars...@hotmail.com or li...@rhsoft.net?
-- 
-- Chase
chasepee...@gmail.com

Re: [PHP-DEV] Mailing list moderation

[Peter Lind]

On 3 Jan 2018 18:13, "Chase Peeler"  wrote:

On Wed, Jan 3, 2018 at 11:16 AM Andrey Andreev  wrote:

> Hi,
>
> On Wed, Jan 3, 2018 at 6:05 PM, Chase Peeler 
> wrote:
> >
> > I agree with Paul. It would be different if email clients that allowed
> > filtering were expensive or hard to find. They aren’t, though. Pretty
> much
> > every email client not only allows filtering, but rather advanced
> filtering
> > as well.
> >
> > Instead of suspending users, no matter how egregious their offenses may
> be,
> > let individual users filter them out as they see fit.
> >
>
> You have a point, but also have it in mind that we're talking about
> individuals participating in a discussion thread, and that's not the
> same as filtering out spam email or a news category that you're not
> interested in.
>
> Cheers,
> Andrey.
>

Are you saying you can't configure your client to delete/move to another
folder any emails with a subject beginning with [PHP-DEV] that are sent
from tonymars...@hotmail.com or li...@rhsoft.net?
--
-- Chase
chasepee...@gmail.com


Missing the point and going for personal attacks instead. You make the
point of the OP rather than your own.

Re: [PHP-DEV] Mailing list moderation

[Chase Peeler]

What personal attack did I make? I asked a serious question. The fact that
you could even take a serious question and interpret it as a personal
attack is exactly why I am very wary of any attempts to suspend users. It's
too easy to misunderstand what someone says.

On Wed, Jan 3, 2018 at 12:16 PM Peter Lind  wrote:

>
>
> On 3 Jan 2018 18:13, "Chase Peeler"  wrote:
>
> On Wed, Jan 3, 2018 at 11:16 AM Andrey Andreev  wrote:
>
> > Hi,
> >
> > On Wed, Jan 3, 2018 at 6:05 PM, Chase Peeler 
> > wrote:
> > >
> > > I agree with Paul. It would be different if email clients that allowed
> > > filtering were expensive or hard to find. They aren’t, though. Pretty
> > much
> > > every email client not only allows filtering, but rather advanced
> > filtering
> > > as well.
> > >
> > > Instead of suspending users, no matter how egregious their offenses may
> > be,
> > > let individual users filter them out as they see fit.
> > >
> >
> > You have a point, but also have it in mind that we're talking about
> > individuals participating in a discussion thread, and that's not the
> > same as filtering out spam email or a news category that you're not
> > interested in.
> >
> > Cheers,
> > Andrey.
> >
>
> Are you saying you can't configure your client to delete/move to another
> folder any emails with a subject beginning with [PHP-DEV] that are sent
> from tonymars...@hotmail.com or li...@rhsoft.net?
> --
> -- Chase
> chasepee...@gmail.com
>
>
> Missing the point and going for personal attacks instead. You make the
> point of the OP rather than your own.
>
-- 
-- Chase
chasepee...@gmail.com

Re: [PHP-DEV] Mailing list moderation

[Chase Peeler]

On Wed, Jan 3, 2018 at 12:18 PM Michael Morris  wrote:

> On Wed, Jan 3, 2018 at 11:05 AM, Chase Peeler 
> wrote:
>
> > On Wed, Jan 3, 2018 at 10:49 AM Paul Jones  wrote:
> > > > On Jan 2, 2018, at 12:29, Dustin Wheeler  wrote:
> > > > On Tue, Jan 2, 2018 at 12:19 PM, Levi Morrison 
> wrote:
> > >
> > > If someone dislikes Tony's commentary for any reason (or no reason!)
> they
> > > are free to filter his messages themselves -- and then unfilter his
> > > messages when they see fit.
> > >
> >
> > I agree with Paul. It would be different if email clients that allowed
> > filtering were expensive or hard to find. They aren’t, though. Pretty
> much
> > every email client not only allows filtering, but rather advanced
> filtering
> > as well.
> >
>
> All fine and well, but it doesn't work when people start quoting the
> offender. Also, filters don't stop the poison from affecting the mood of
> the posters who interact with him.
>
> In my experience loud and obnoxious voices drive off thoughtful and
> introspective ones every time. That is the consequence of giving a platform
> to them. As the saying goes, It's pointless to wrestle a pig - you'll just
> get muddy and the pig enjoys it. From a moderators standpoint, if you
> refuse to block jerks eventually all you'll be left with are jerks.
>
> I think self moderation still solves this. If the person is disruptive
enough, eventually enough people will block them and there won't be many
instances of them getting quoted or poisoning the thread.

If certain people decide to engage them, then others will start to block
them as well. In the end, they'll have to choose whether they want to
contribute in a positive way to the list, or, "wrestle with pigs." The two
options will be mutually exclusive, since you can't continue to pull
content others are trying to ignore back into the conversation without
getting ignored yourself.


> >
> > Instead of suspending users, no matter how egregious their offenses may
> be,
> > let individual users filter them out as they see fit.
> >
> >
> Again, in my experience people usually elect to simply leave altogether
> rather than set a long block list.  And frankly Tony isn't worth even one
> contributing coder.
>
> Tony has been asked multiple times by multiple people to behave.  He's been
> banned from other PHP related forums I know of. He's not here to contribute
> in any meaningful way, only complain and make passive agressive swipes at
> other users. I could go on, but I think that alone makes the case that he
> needs to be gone.
>

Maybe, maybe not. Either way, I don't want you making that decision for
me.  I should be allowed to determine at which point someone's negative
contributions outweigh their positive ones to a point that I no longer feel
they are productive.
-- 
-- Chase
chasepee...@gmail.com

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Wed, Jan 3, 2018 at 12:21 PM, Andreas Hennings 
wrote:

> Another idea I have when reading this proposal is "implicit" typing
> based on the initialization.
>
> E.g.
>
> $x = 5;
> $x = 'hello';  // -> Error: $x was initialized as integer, and cannot
> hold a string.
>
>
No, no no.  I don't think I'd like that always on approach. However, I just
had an idea.


Let's step back.  Way back.  PHP/FF days back.

Back in the day Ramus chose to put variables off on their own symbol table
for performance reasons.  This isn't as necessary now, but vars in PHP
continue to be always $something.

Now I don't know the implementation can of worms this would touch but what
if this was changed for the locked type variables.  That would distinguish
them greatly..

int x = 5;

Here x is a locked type variable of the integer type.  Since it's also on
the same symbol tables as the classes, functions, constants et al I presume
it is namespace bound as well.

var x = 5;

If allowed what would this mean?

And what to do with class members is an open question.


Anyway, I'm looking for an implementation that allows loose and strong
typing to coexist even within a given file. I use loosely typed variables
most of time myself.

Re: [PHP-DEV] Mailing list moderation

[Michael Morris]

On Wed, Jan 3, 2018 at 11:05 AM, Chase Peeler  wrote:

> On Wed, Jan 3, 2018 at 10:49 AM Paul Jones  wrote:
> > > On Jan 2, 2018, at 12:29, Dustin Wheeler  wrote:
> > > On Tue, Jan 2, 2018 at 12:19 PM, Levi Morrison  wrote:
> >
> > If someone dislikes Tony's commentary for any reason (or no reason!) they
> > are free to filter his messages themselves -- and then unfilter his
> > messages when they see fit.
> >
>
> I agree with Paul. It would be different if email clients that allowed
> filtering were expensive or hard to find. They aren’t, though. Pretty much
> every email client not only allows filtering, but rather advanced filtering
> as well.
>

All fine and well, but it doesn't work when people start quoting the
offender. Also, filters don't stop the poison from affecting the mood of
the posters who interact with him.

In my experience loud and obnoxious voices drive off thoughtful and
introspective ones every time. That is the consequence of giving a platform
to them. As the saying goes, It's pointless to wrestle a pig - you'll just
get muddy and the pig enjoys it. From a moderators standpoint, if you
refuse to block jerks eventually all you'll be left with are jerks.


>
> Instead of suspending users, no matter how egregious their offenses may be,
> let individual users filter them out as they see fit.
>
>
Again, in my experience people usually elect to simply leave altogether
rather than set a long block list.  And frankly Tony isn't worth even one
contributing coder.

Tony has been asked multiple times by multiple people to behave.  He's been
banned from other PHP related forums I know of. He's not here to contribute
in any meaningful way, only complain and make passive agressive swipes at
other users. I could go on, but I think that alone makes the case that he
needs to be gone.

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Andreas Hennings]

Another idea I have when reading this proposal is "implicit" typing
based on the initialization.

E.g.

$x = 5;
$x = 'hello';  // -> Error: $x was initialized as integer, and cannot
hold a string.

or

$x = $a + $b;
$x = 'hello';  // -> Error: $x was initialized as number (int|float),
and cannot hold a string.

To me this is only acceptable if the implicit type can be determined
at compile time.
So:

if ($weather_is_nice) {
  $x = 5;
}
else {
  $x = 'hello';  // -> Error: $x would be initialized as int
elsewhere, so cannot be initialized as string.
}


This change would be controversial and leave a lot of questions.
It would be a BC break, unless we introduce yet another declare()
setting, e.g. declare(implicit_types=1).

It could be tricky for global variables, or in combination with
include/require, where the variable can be seen from outside a
function body, and outside the range of the declare() statement.

I only mention it here because it relates to the proposal. I do not
have a strong opinion on it atm.


On 3 January 2018 at 18:10, Andreas Hennings  wrote:
> This proposal contains some interesting ideas, which I see as separate:
> 1. A syntax to declare the type of local variables.
> 2. A syntax to declare the type of object properties.
> 3. Preventing local variables, object properties and parameters to
> change their type after initialization/declaration.
>
> For me the point 3 is the most interesting one.
> I think the other points are already discussed elsewhere in some way,
> although they are clearly related to 3.
>
> Point 3 would be a BC break, if we would introduce it for parameters.
> Current behavior: https://3v4l.org/bjaLQ
>
> Local variables and object properties currently cannot be types, so
> point 3 would not be a BC break for them, if we introduce it together
> with 1 and 2.
> But then we would have an inconsistency between parameters and local
> vars / object properties.
>
> What we could do to avoid BC break is to introduce
> declare(fixed_parameter_types=1) in addition to
> declare(strict_types=1).
> For local variables and object properties, the type would always be fixed.
> But for parameters, it would only be fixed if the
> declare(fixed_parameter_types=1) is active.
>
> Maybe to make it less verbose, we could say declare(strict_types=2),
> which would mean the combination of both those things?
> Or some other type of shortcut.
> I think we will have to think about shortcuts like this if we
> introduce more "modes" in the future.
>
>
>> Currently the var keyword is used to formally declare a variable.
>
> Are you talking about local variables?
> In which PHP version? https://3v4l.org/o0PFg
>
> Afaik, currently var is only used for class/object properties from the
> time when people did not declare the visibility as
> public/protected/private.
>
>
>> If the type is omitted, scalar is assumed.  If Fleshgrinder's scalar RFC is
>> accepted then it would make sense to allow programmers to explicitly
>> declare the variable as a scalar, but in any event when the type is omitted
>> scalar must be assumed for backwards compatibility.
>
> If no type is specified, then "mixed" should be assumed, not "scalar".
> Assuming "scalar" would be a BC break, and it would be confusing.
>
>
> On 3 January 2018 at 10:03, Michael Morris  wrote:
>> On Wed, Jan 3, 2018 at 3:50 AM, Niklas Keller  wrote:
>>
>>> Hey Michael,
>>>
>>> I don't think the BC break is acceptable. You argue that scalar type
>>> declarations are relatively new, but in fact they're already years old now.
>>> They're used in most PHP 7+ packages. Even if changing types might be
>>> discouraged, it still happens a lot.
>>>
>>
>> Hmm.  Well, that aspect of this can be dropped. What about the rest of it?

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

Re: [PHP-DEV] Mailing list moderation

[Rowan Collins]

On 3 January 2018 at 15:49, Paul Jones  wrote:

>
> I am not in favor of anyone else deciding for me that I am not allowed to
> see Tony's (or anyone else's) messages on this list. I can make that
> decision myself, and revisit that decision myself should I choose.
>
> If someone dislikes Tony's commentary for any reason (or no reason!) they
> are free to filter his messages themselves -- and then unfilter his
> messages when they see fit.
>


The problem is that off-topic and insensitive messages tend to draw in
other people, and distract energy away from what we're all here for.

If enough people ignore someone, it's basically a "shadowban", which are
generally highly controversial, because they give the illusion of allowing
someone to participate without any of the actual value. On the other hand,
if enough people engage with someone who's ignored, the flamewars show up
anyway - filtering systems are rarely sophisticated enough to block replies
to a blocked message.

I'm sure everyone would agree that the best course of action would be for
everyone to take a deep breath, step away from any arguments they're in
(something I've had to do myself), and concentrate on positive proposals
and listening respectfully to people with differing opinions. But sometimes
an enforced timeout is the best way to get someone to take that deep breath.

Moderation is always tricky, but pretty much every forum I've ever used has
had it in some form.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Michael Morris]

On Wed, Jan 3, 2018 at 12:10 PM, Andreas Hennings 
wrote:

> This proposal contains some interesting ideas, which I see as separate:
> 1. A syntax to declare the type of local variables.
> 2. A syntax to declare the type of object properties.
> 3. Preventing local variables, object properties and parameters to
> change their type after initialization/declaration.
>
> For me the point 3 is the most interesting one.
> I think the other points are already discussed elsewhere in some way,
> although they are clearly related to 3.
>
> Point 3 would be a BC break, if we would introduce it for parameters.
> Current behavior: https://3v4l.org/bjaLQ
>
> Local variables and object properties currently cannot be types, so
> point 3 would not be a BC break for them, if we introduce it together
> with 1 and 2.
> But then we would have an inconsistency between parameters and local
> vars / object properties.
>
> What we could do to avoid BC break is to introduce
> declare(fixed_parameter_types=1) in addition to
> declare(strict_types=1).
> For local variables and object properties, the type would always be fixed.
> But for parameters, it would only be fixed if the
> declare(fixed_parameter_types=1) is active.
>
> Maybe to make it less verbose, we could say declare(strict_types=2),
> which would mean the combination of both those things?
> Or some other type of shortcut.
> I think we will have to think about shortcuts like this if we
> introduce more "modes" in the future.
>
>
There will be occasions where having an unfixed variable alongside normal
ones will be desirable.


>
> > Currently the var keyword is used to formally declare a variable.
>
> Are you talking about local variables?
> In which PHP version? https://3v4l.org/o0PFg
>
>
Sorry, I'm confusing PHP for JavaScript. I forgot that the var keyword was
only used in PHP 4 for class members. For some reason my brain assumed it
was usable in a local scope.


> Afaik, currently var is only used for class/object properties from the
> time when people did not declare the visibility as
> public/protected/private.
>
>

>
> If no type is specified, then "mixed" should be assumed, not "scalar".
> Assuming "scalar" would be a BC break, and it would be confusing.
>
>
Ok. I'm misusing the term scalar to mean "variable who's type can be
changed at will depending on context." Sorry.

Re: [PHP-DEV] Mailing list moderation

[Rowan Collins]

On 3 January 2018 at 17:28, Chase Peeler  wrote:

> I think self moderation still solves this. If the person is disruptive
> enough, eventually enough people will block them and there won't be many
> instances of them getting quoted or poisoning the thread.
>
> If certain people decide to engage them, then others will start to block
> them as well.



That all sounds like a lot of wasted effort. If we're not careful,
endorsing that behaviour would end up with people sharing mail filter
definitions, proxying the list through a shared filter, or just setting up
a rival discussion forum. All of which just distract us further from making
PHP better.



> Maybe, maybe not. Either way, I don't want you making that decision for
> me.  I should be allowed to determine at which point someone's negative
> contributions outweigh their positive ones to a point that I no longer feel
> they are productive.
>


I think maybe we have a different view of what a list like this is. To me,
it's a forum where we're collaborating to a common aim; it has an existence
in its own right, and we collectively shape that existence. I may be
misunderstanding, but it sounds like you view it more as a public space
where you can find individuals to communicate with, and you retain the
right to shape those communications. Does that sound a reasonable
characterisation? I'm not seeking to criticise, only to understand where
this idea of "making the decision for me" comes from, because to me,
moderation doesn't seem like a personal decision which is being taken away.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Mailing list moderation

[Daniel Brown]

On Wed, Jan 3, 2018 at 11:16 AM, Johannes Schlüter  wrote:
> On Di, 2018-01-02 at 11:49 +0100, Nikita Popov wrote:
>> li...@rhsoft.net, who have recently been
>> aggressively derailing
>
> He was blocked in 2012 already:
>
> https://externals.io/message/59395#59421

I hadn't even noticed this thread until the flurry of activity
kept throwing it to the top of my inbox, but if you remember, that
2012 ban by Rasmus was far from the only time he caused issues.  And
it's not just with PHP either.

Reindl Harald has an established pattern of foul
language and harassment of community members in a number of open
source projects.  In the notes I keep on people who abuse our
services, I have his first entry coming up on eight years ago, in
July, 2010, where he devolved into profanity and personal attacks
because he didn't like something that was being discussed.

He's had a number of opportunities to correct his abusive
behavior.  I, too, agree in second - and even third - chances, but
when this pattern of behavior spans the better part of a decade, and
racks-up enough entries in my notes that I can remember who he is
right off the top of my head, I think enough is enough.

I, for one, say permanently ban him and move on.

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

Re: [PHP-DEV] Mailing list moderation

[Paul Jones]

> On Jan 3, 2018, at 12:59, Joe Watkins  wrote:
> 
> Let's remember that there are a large number of people on the sidelines that 
> are not subscribed to the list directly, but choose to use news readers, or 
> the excellent externals.io; They may not able to filter messages from any 
> individuals, so they are in effect forced to navigate through these 
> "contributions" from problematic posters. That's not fair to them, at all. 
> All of the conversations here are a matter of public record, not only 
> existing in your mail client, or inbox, or whatever ... We can and should be 
> eliminating noise from that public record.

It is indeed excellent. Perhaps this is an opportunity to create 
"expurgated.externals.io" that is under the control of whoever creates & 
manages it, to filter "noise" there so that others may peruse it in what they 
consider to be peace.

That's three postings for me on this topic today, which is probably a bit much; 
I'll leave it at that for now.


-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




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

Re: [PHP-DEV] Mailing list moderation

[Andrey Andreev]

Hi,

On Wed, Jan 3, 2018 at 7:13 PM, Chase Peeler  wrote:
>
>
> On Wed, Jan 3, 2018 at 11:16 AM Andrey Andreev  wrote:
>>
>> Hi,
>>
>> On Wed, Jan 3, 2018 at 6:05 PM, Chase Peeler 
>> wrote:
>> >
>> > I agree with Paul. It would be different if email clients that allowed
>> > filtering were expensive or hard to find. They aren’t, though. Pretty
>> > much
>> > every email client not only allows filtering, but rather advanced
>> > filtering
>> > as well.
>> >
>> > Instead of suspending users, no matter how egregious their offenses may
>> > be,
>> > let individual users filter them out as they see fit.
>> >
>>
>> You have a point, but also have it in mind that we're talking about
>> individuals participating in a discussion thread, and that's not the
>> same as filtering out spam email or a news category that you're not
>> interested in.
>>
>> Cheers,
>> Andrey.
>
>
> Are you saying you can't configure your client to delete/move to another
> folder any emails with a subject beginning with [PHP-DEV] that are sent from
> tonymars...@hotmail.com or li...@rhsoft.net?

No, what I am saying is that it results in parts missing from a
conversation, making it hard to follow. And I would still receive all
replies and quoted text, thus rendering the filter ineffective.

Cheers,
Andrey.

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

Re: [PHP-DEV] Mailing list moderation

[Aaron Piotrowski]

> On Jan 3, 2018, at 12:59 PM, Joe Watkins  wrote:
> 
> The precedent has been set already: One of these users was already kicked
> off the list and decided to resubscribe and continue to conduct themselves
> in an unacceptable manner.
> 
> This is a forum for technical discussion regarding the development of PHP:
> We must be able to keep conversation focused and one of the tools we have
> to do that is restricting who is able to post. It seems perfectly
> reasonable to exercise that power in order to improve the quality of
> conversation and keep it focused.
> 
> Banning or suspending these users, and anyone else incapable of conducting
> themselves reasonably, will serve that purpose.
> 
> Let's remember that there are a large number of people on the sidelines
> that are not subscribed to the list directly, but choose to use news
> readers, or the excellent externals.io; They may not able to filter
> messages from any individuals, so they are in effect forced to navigate
> through these "contributions" from problematic posters. That's not fair to
> them, at all. All of the conversations here are a matter of public record,
> not only existing in your mail client, or inbox, or whatever ... We can and
> should be eliminating noise from that public record.
> 
> Cheers
> Joe

Exactly. There needs to be consequences when someone cannot conduct themselves 
in a manner that's fitting to a technical discussion. It's infuriating when 
people on this list make personal attacks and then act as though nothing wrong 
has been done. Clearly either they don't understand or do not care. Either way 
they need to know there are consequences for such actions.

This is not at all about silencing those whose opinions differ from the 
majority. Those viewpoints are important and must be heard. However 
relentlessly pushing a particular viewpoint and resorting to personal attacks 
becomes a problem. At some point it is no longer constructive and is just spam.

I and many others avoid participating on the list unless absolutely necessary. 
There is no time or energy to wade through the noise to find the actual 
discussion of the topic at hand.

> 
> On Wed, Jan 3, 2018 at 7:45 PM, Paul Jones  wrote:
> 
>> 
>>> On Jan 3, 2018, at 12:35, Joe Watkins  wrote:
>>> 
>>> You don't get to conduct yourself however you want without consequence.
>> 
>> Sure. The question then, is, what is the proper consequence? I hold that
>> it is not "banning" or "suspension" (which may or may not actually be
>> within the delegated powers of anyone on this list). Instead, it is "to be
>> ignored, by those who choose to ignore you."
>> 

Trying to filter out all messages from certain users is untenable. Either too 
much is filtered because a banned person is CC'ed on a constructive comment, or 
too little is filtered and there's still noise from those replying to the 
filtered user. Banning or suspension should not be used lightly, but I think 
we've reached a point where it is warranted.

I think a simple PHP CoC similar to the JS Foundation [1] would be helpful by 
providing a basis for what is deemed acceptable.

Aaron Piotrowski

[1] https://js.foundation/community/code-of-conduct



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

Re: [PHP-DEV] Mailing list moderation

[Joe Watkins]

+1

It's true that everyone can setup their own filters, but why should they
have too.

You don't get to conduct yourself however you want without consequence.

Cheers
Joe

On Wed, Jan 3, 2018 at 6:52 PM, Rowan Collins 
wrote:

> On 3 January 2018 at 17:28, Chase Peeler  wrote:
>
> > I think self moderation still solves this. If the person is disruptive
> > enough, eventually enough people will block them and there won't be many
> > instances of them getting quoted or poisoning the thread.
> >
> > If certain people decide to engage them, then others will start to block
> > them as well.
>
>
>
> That all sounds like a lot of wasted effort. If we're not careful,
> endorsing that behaviour would end up with people sharing mail filter
> definitions, proxying the list through a shared filter, or just setting up
> a rival discussion forum. All of which just distract us further from making
> PHP better.
>
>
>
> > Maybe, maybe not. Either way, I don't want you making that decision for
> > me.  I should be allowed to determine at which point someone's negative
> > contributions outweigh their positive ones to a point that I no longer
> feel
> > they are productive.
> >
>
>
> I think maybe we have a different view of what a list like this is. To me,
> it's a forum where we're collaborating to a common aim; it has an existence
> in its own right, and we collectively shape that existence. I may be
> misunderstanding, but it sounds like you view it more as a public space
> where you can find individuals to communicate with, and you retain the
> right to shape those communications. Does that sound a reasonable
> characterisation? I'm not seeking to criticise, only to understand where
> this idea of "making the decision for me" comes from, because to me,
> moderation doesn't seem like a personal decision which is being taken away.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Mailing list moderation

[Paul Jones]

> On Jan 3, 2018, at 12:35, Joe Watkins  wrote:
> 
> You don't get to conduct yourself however you want without consequence.

Sure. The question then, is, what is the proper consequence? I hold that it is 
not "banning" or "suspension" (which may or may not actually be within the 
delegated powers of anyone on this list). Instead, it is "to be ignored, by 
those who choose to ignore you."


-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php


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

Re: [PHP-DEV] Mailing list moderation

[Joe Watkins]

The precedent has been set already: One of these users was already kicked
off the list and decided to resubscribe and continue to conduct themselves
in an unacceptable manner.

This is a forum for technical discussion regarding the development of PHP:
We must be able to keep conversation focused and one of the tools we have
to do that is restricting who is able to post. It seems perfectly
reasonable to exercise that power in order to improve the quality of
conversation and keep it focused.

Banning or suspending these users, and anyone else incapable of conducting
themselves reasonably, will serve that purpose.

Let's remember that there are a large number of people on the sidelines
that are not subscribed to the list directly, but choose to use news
readers, or the excellent externals.io; They may not able to filter
messages from any individuals, so they are in effect forced to navigate
through these "contributions" from problematic posters. That's not fair to
them, at all. All of the conversations here are a matter of public record,
not only existing in your mail client, or inbox, or whatever ... We can and
should be eliminating noise from that public record.

Cheers
Joe



On Wed, Jan 3, 2018 at 7:45 PM, Paul Jones  wrote:

>
> > On Jan 3, 2018, at 12:35, Joe Watkins  wrote:
> >
> > You don't get to conduct yourself however you want without consequence.
>
> Sure. The question then, is, what is the proper consequence? I hold that
> it is not "banning" or "suspension" (which may or may not actually be
> within the delegated powers of anyone on this list). Instead, it is "to be
> ignored, by those who choose to ignore you."
>
>
> --
> Paul M. Jones
> pmjone...@gmail.com
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Rowan Collins]

Hi Michael,

On 02/01/2018 10:35, Michael Morris wrote:

I would like to propose a clean way to add some strong typing to PHP in a
manner that is almost fully backward compatible (there is a behavior change
with PHP 7 type declarations). As I don't have access to the add RFC's to
the wiki I'll place this here.


Thanks for putting this together. Perhaps unlike Andreas, I think it is 
good to look at typing changes as a unified framework, rather than 
considering "typed properties", "typed variables", etc, as separate 
concerns. If we don't, there is a real risk we'll end up making 
decisions now that hobble us for future changes, or over-complicating 
things in one area because we're not yet ready to make changes in another.


My own thoughts on the subject from a while ago are here: 
http://rwec.co.uk/q/php-type-system In that post, I borrowed the term 
"container" from Perl6 for the conceptual thing that type constraints 
are stored against; in PHP's case, this would include variables, object 
properties, class static properties, function parameters, and return 
values. I think a good plan for introducing typing is one that considers 
all of these as equals.


The biggest issue with any proposal, though, is going to be performance. 
I don't think this is an incidental detail to be dealt with later, it is 
a fundamental issue with the way type hints in PHP have evolved. PHP is 
extremely unusual, if not unique, in exclusively enforcing type 
constraints at runtime. Other languages with "gradual typing" such as 
Python, Hack, and Dart, use the annotations only in separate static 
analysers and/or when a runtime debug flag is set (similar to enabling 
assertions).


Extending that to all containers means every assignment operation would 
effectively need to check the value on the right-hand-side against the 
constraint on the left-hand-side. Some of those checks are non-trivial, 
e.g. class/interface constraints, callable; or in future maybe "array of 
Foo", "Foo | Bar | int", "Foo & Bar", etc. There are ways to ease this a 
bit, like passing around a cache of type constraints a value has passed, 
but I think we should consider whether the "always-on runtime 
assertions" model is the one we want in the long term.




If the type is omitted, scalar is assumed.


As Andreas pointed out, you mean "mixed" here (accepts any value), 
rather than "scalar" (accepts int, string, float, and bool).




The variables created by this pattern auto cast anything assigned to them
without pitching an error.


My initial thought was that this makes the assignment operator a bit too 
magic for my taste. It's conceptually similar to the "weak mode" for 
scalar type hints (and could perhaps use the same setting), but those 
feel less magic because they happen at a clear scope boundary, and the 
cast only happens once. But on reflection, the consistency makes sense, 
and assigning to an object property defined by another library is 
similar to calling a method defined by another library, so the 
separation of caller and callee has similar justification.




PHP 7 introduced type declarations.


This is incorrect, and leads you to a false conclusion. PHP 7 introduced 
*scalar* type declarations, which extended an existing system which had 
been there for years, supporting classes, interfaces, the generic 
"array" constraint, and later pseudo-types like "callable".


I don't think it's tenable to change the meaning of this syntax, but it 
would certainly be possible to bikeshed some modifier to simultaneously 
declare "check type on function call, and declare corresponding local 
variable as fixed type".




OBJECT TYPE LOCKING

[...]

QUESTION: How do we handle the second auto casting case? $a is not allowed
to not be a SomeClass() object, but there are no casting rules.


There are actually more than just object and scalar type hints - 
"callable" is a particularly complex check - but currently they all just 
act as assertions, so it would be perfectly consistent for "locking" to 
also only have the one mode.




COMPARISON BEHAVIOR
When a strongly typed variable (autocasting or not) is compared to a scalar
variable only the scalar switches types. The strict comparison operator is
allowed though it only blocks the movement of the scalar.

Comparisons between strongly typed variables are always strict and a
TypeError results if their types don't match. This actually provides a way
to force the greater than, lesser than, and spaceship operation to be
strict.


I like this idea. The over-eager coercion in comparisons is a common 
criticism of PHP.



In general I really like the outline of this; there's a lot of details 
to work out, but we have to start somewhere.



Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Mailing list moderation

[Larry Garfield]

On Wednesday, January 3, 2018 11:17:53 AM CST Michael Morris wrote:
> On Wed, Jan 3, 2018 at 11:05 AM, Chase Peeler  wrote:
> > On Wed, Jan 3, 2018 at 10:49 AM Paul Jones  wrote:
> > > > On Jan 2, 2018, at 12:29, Dustin Wheeler  wrote:
> > > 
> > > > On Tue, Jan 2, 2018 at 12:19 PM, Levi Morrison  wrote:
> > > If someone dislikes Tony's commentary for any reason (or no reason!)
> > > they
> > > are free to filter his messages themselves -- and then unfilter his
> > > messages when they see fit.
> > 
> > I agree with Paul. It would be different if email clients that allowed
> > filtering were expensive or hard to find. They aren’t, though. Pretty much
> > every email client not only allows filtering, but rather advanced
> > filtering
> > as well.
> 
> All fine and well, but it doesn't work when people start quoting the
> offender. Also, filters don't stop the poison from affecting the mood of
> the posters who interact with him.
> 
> In my experience loud and obnoxious voices drive off thoughtful and
> introspective ones every time. That is the consequence of giving a platform
> to them. As the saying goes, It's pointless to wrestle a pig - you'll just
> get muddy and the pig enjoys it. From a moderators standpoint, if you
> refuse to block jerks eventually all you'll be left with are jerks.

^^ That.  Exactly that.  Active refusal to police a community results in a 
race to the bottom.  Every time.  Every single time.  Add up the amount of 
time we're even discussing it, multiply by hour hourly rate...  That's how 
much it's costing us to even have this discussion about whether or not we 
should expel a long time troll.

> > Instead of suspending users, no matter how egregious their offenses may
> > be,
> > let individual users filter them out as they see fit.
> 
> Again, in my experience people usually elect to simply leave altogether
> rather than set a long block list.  And frankly Tony isn't worth even one
> contributing coder.

Precisely.

"Instead of banning abusive users on Twitter, no matter how egregious their 
offenses may be, let individual users do the work of blocking them as they see 
fit."

Because putting all of the penalty on the people being attacked, belittled, 
and distracted is a great idea.  Or they'll just self-filter and leave.

> Tony has been asked multiple times by multiple people to behave.  He's been
> banned from other PHP related forums I know of. He's not here to contribute
> in any meaningful way, only complain and make passive agressive swipes at
> other users. I could go on, but I think that alone makes the case that he
> needs to be gone.

+1 for outright removal of both, but Tony in particular.  In my 10 years on 
this list I haven't seen Tony post constructively once.  I've seen him insult, 
gaslight, and whataboutism a hundred times.  Please, whoever runs this list, 
put him out of our misery.

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.