Hi Anthony,
I sent you a copy of the messages I sent to Sara, asking for more details about
what you consider as 'deplorable' in them. I also sent another message to get
your opinion about the new ruleset I could propose. It seems you didn't have
time to reply. Just hope you don't refuse communication. If this was the case,
go on with vote now, no need to make it look like you're waiting for me if,
behind the scene, you're not ready to communicate.
As I didn't get the explanation I was looking for from you, I'll now ask
everyone interested to give an opinion. That's why I attached both messages. If
anyone understands the reaction it generated, please tell me, it will help me
not do the mistake again. As I told you, the only thing I see as potentially
offensive is 'you probably don't care'. I don't know how it is in English but,
in French, it is not considered as very offensive.
I would have preferred avoiding to disturb everyone with the subject again and
I took time to think about it but, while I may have been impolite in private,
you made it public and your message even contains terms that I consider as
public insults against me, my work, and my relationship with the community. So,
while you 'can't stress how deplorable my acts were', I won't qualify yours,
especially since it seems you wrote this without having read the messages in
question.
To be clear, Sara's reporting I did 'not-so-politely' ask her to stop work, is
technically wrong but the tone is correct. It just saddens me because I have
the biggest respect for her work, but I can live with it. You amplified it to
'sandbagged, sabotage, strong-armed' which is still more wrong, but also
insulting.
So, if anyone sees something incorrect in the attached messages, I'll apologize
again because it was not intended, and I do it in advance to Sara. But I am not
sure who should apologize most. Now, unless someone wants it to go on, I'm
afraid I won't have time for this anymore.
Regards
François
> -----Message d'origine-----
> De : Anthony Ferrara [mailto:ircmax...@gmail.com]
> Envoyé : jeudi 19 février 2015 14:24
> À : franc...@php.net
> Cc : Lester Caine; internals@lists.php.net
> Objet : Using Other Channels (was Scalar Type Declarations v0.5)
>
> Francois
>
> On Thu, Feb 19, 2015 at 6:58 AM, François Laupretre <franc...@php.net>
> wrote:
> >> De : Lester Caine [mailto:les...@lsces.co.uk]
> >>
> >> On 19/02/15 04:44, Dennis Birkholz wrote:
> >> > I just saw the reddit where you mention that v0.4 is practically
> >> > abandoned now, so I will just renounce my previous mail!
> >>
> >> DO NOT USE OTHER CHANNELS!
> >
> > Agreed.
>
> You mean like contacting another contributor in private asking them to
> not make a proposal and to stop work on it?
>
> > And the RFC was not abandoned at all. I and others have been working
> almost continuously on a 'compromise' single-mode approach during the last
> 3 days (and nights), as activity on the list shows with no doubt. So,
> pretending the RFC to be 'abandoned' is just a way to discard a disagreed
> work.
>
> Let me quote something that was said:
>
> "Ze'ev and François have not-so-politely asked [Sara] to not put 0.4
> forward since they have something they believe they have consensus
> on."
>
> So while it may not have been "abandoned", it was sandbagged
> (sabotaged, strong-armed, etc). I used abandoned as a light term to
> not point out to list what strong-arming happened behind the scenes.
> But since you apparently don't want "other channels used"...
>
> I can't stress how deplorable that act is. How harmful to the
> community it is to ask in private for a contributor to stop what they
> are doing because someone else "has a better idea". We had a proposal
> that *had* consensus (66%). It was withdrawn. With some minor changes,
> at least 25% of no-voters would have changed their mind (based on
> conversations around why the voted no).
>
> So rather than go for the 70-75% consensus that we **know** we have,
> we should drop all work for a magic vaporware proposal. Contributors
> should stand down and not contribute because "you know better".
>
> I'm sorry, I favor the proposal that's in writing and implemented
> rather than one that's yet to be seen. If yours does indeed prove to
> be as good as possible, then the votes will decide. Or if it convinces
> me early enough, I'll withdraw the current proposal. But based on
> everything I've seen in the discussion threads, I can't possibly see
> how that will happen. I hope you surprise me, but in case that you
> don't, I'm moving forward with the existing implementation that we
> know has support.
>
> > As long as she does not officially gives up (posting to the list), I'll keep
> considering Sara still has the lead on scalar type hinting. If she officially
> gives
> up, I'll immediately propose to take it over and, if we are several to want
> it,
> we'll discuss.
>
> I created a forked RFC. You can keep her as lead all you want, that
> doesn't mean I can't move forward with my RFC.
>
> > That's the rule and I encourage list members to explicitly show their
> support to the formal process we all agreed upon.
>
> What rule is that? Can you point me to anywhere in the Voting RFC that
> says that? https://wiki.php.net/rfc/voting
>
> It doesn't.
>
> That's fine. Let's let the votes decide rather than relying on strongarming.
>
> > For the rest, Lester summarized quite well my view about designing PHP
> for static analysis, instead of static analysis for PHP ;)
>
> Saying a problem doesn't exist doesn't make it go away.
>
> Anthony
--- Begin Message ---
Hi Sara,
OK. I won't say you don't care.
To explain, while it's not a reason, I read this at 2 AM after having spent
almost 24 hours working on this... I am happy to see I was wrong and apologize
if I have been unfair (I love 'bring it down a notch', I didn't know the
expression but I'll reuse it :). The good thing is that it made me go to bed,
when I would probably have spent the night again.
If you read 'Reviving scalar type hints' posts again, especially mine's and
Zeev's, between us and to other members, they will show you what we were aiming
to, but Zeev's summary is fine too (while 'details' are always important).
I am currently writing the changes I would do to the ZPP layers and
zend_parse_parameters(). Unfortunately, I don't consider arg_info because, IMO,
using zpp is much more powerful and consistent, in the case of a single-mode
approach. I agree that, in a dual-mode approach, it can be better to start with
untyped internal functions and set type hinting out of zpp but, in the single
mode case, keeping userland and internal available features in sync is an
essential benefit, IMO again.
The point of proposing to implement it via arg_info makes me afraid because
there was consensus here and, if people start arguing about zpp,
zend_parse_parameters(), or arg_info, as most don't understand the implications
very well, it can quickly go nowhere, and I understand that's not a good
argument, but we don't have much time. If it is accepted to postpone feature
freeze by one or two months, why not, but, by now, it is March 15, very soon.
Regards
François
> -----Message d'origine-----
> De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara
> Golemon
> Envoyé : mercredi 18 février 2015 05:26
> À : franc...@php.net
> Objet : Re: [PHP-DEV] Scalar Type Hints v0.4
>
> Woah there, buddy. Bring it down a notch.
>
> If you want to put forward a modified 0.1, go for it. I was stepping
> forward into what I saw as a vacuum, because I don't see this
> consensus you speak of.
>
> If you feel like I'm stepping on your toes, then I'll back off, but
> you don't need to accuse me of not caring. That's uncalled for.
>
>
> On Tue, Feb 17, 2015 at 7:00 PM, François Laupretre <franc...@php.net>
> wrote:
> > Hi Sara,
> >
> > I don't know if you read the posts I exchanged with others on the list about
> scalar type hinting, but we worked hard to build a consensus on a single
> mode approach that would satisfy, say, 90% of us. And I think we got it, step
> by step, both camps moving to a common position. To summarize, it was
> roughly based on 0.1, with zpp restrictions and a lot of important 'details',
> like
> support for additional strict-only types. Both camps seemed to agree. I had
> spent two days and two nights on it but, two hours ago, I was pretty sure of
> what I would put in the RFC, and I knew it had good chances if a FUD
> campaign didn't shoot it down.
> >
> > Unfortunately, what I read in your message is almost exactly the opposite
> of what we had in mind. I won't take it point by point because I'm a little
> bitter tonight. Maybe tomorrow.
> >
> > The only positive point is that it proposes other subjects than declare()
> endless bikesheding.
> >
> > The negative point is that it breaks everything and puts it on the table
> again. Even what everyone agreed, like alignment on ZPP will have to be
> endlessly discussed again. And, as most don't understand the difference and
> implications of using arg_info or ZPP, it will be toxic kindergarten again.
> >
> > With the 7.0 feature freeze approaching, I really don't understand why you
> did that.
> >
> > Anyway, you probably won't care but I find it a little unfair. I was the
> > first
> one to propose reviving scalar type hints (hence the thread subject). I didn't
> take over Andrea's RFC because I wanted to build something different and I
> naively considered that taking over would restrict me to cosmetic changes
> before running a new vote, as it remains Andrea's RFC, not mine. I realize I
> was naïve and too honest because you took it over formally and, now, you
> propose something really different. Now, as you know we won't probably
> propose two competing RFCs, given the last flame war, you're free to
> propose it the way you want. I will be less naïve next time.
> >
> > François
> >
> >> -----Message d'origine-----
> >> De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara
> >> Golemon
> >> Envoyé : mercredi 18 février 2015 02:56
> >> À : Nikita Popov
> >> Cc : Rasmus Lerdorf; PHP internals
> >> Objet : Re: [PHP-DEV] Scalar Type Hints v0.4
> >>
> >> On Tue, Feb 17, 2015 at 5:05 PM, Nikita Popov <nikita....@gmail.com>
> >> wrote:
> >> > This is exactly what I fear will happen with an arginfo based approach.
> >> > If
> >> > even fundamental aspects like the "123" vs 123 (or true vs 1) distinction
> >> > are suppressed for internal functions, this isn't a strict typing mode,
> >> > it's
> >> > just a weak typing mode with slightly different rules.
> >> >
> >> By the way, I realize I wasn't clear in my previous reply to you. I
> >> don't mean to dismiss your position and the proposal I put forth was
> >> just to get a feel for people's gut reactions to it. Your gut
> >> reaction is clearly negative and that will be taken into account when
> >> I put up 0.4 of the RFC which may or may not look like this proposal,
> >> depending on what others have to say about it.
> >>
> >> -Sara
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Hi Sara,
I don't know if you read the posts I exchanged with others on the list about
scalar type hinting, but we worked hard to build a consensus on a single mode
approach that would satisfy, say, 90% of us. And I think we got it, step by
step, both camps moving to a common position. To summarize, it was roughly
based on 0.1, with zpp restrictions and a lot of important 'details', like
support for additional strict-only types. Both camps seemed to agree. I had
spent two days and two nights on it but, two hours ago, I was pretty sure of
what I would put in the RFC, and I knew it had good chances if a FUD campaign
didn't shoot it down.
Unfortunately, what I read in your message is almost exactly the opposite of
what we had in mind. I won't take it point by point because I'm a little bitter
tonight. Maybe tomorrow.
The only positive point is that it proposes other subjects than declare()
endless bikesheding.
The negative point is that it breaks everything and puts it on the table again.
Even what everyone agreed, like alignment on ZPP will have to be endlessly
discussed again. And, as most don't understand the difference and implications
of using arg_info or ZPP, it will be toxic kindergarten again.
With the 7.0 feature freeze approaching, I really don't understand why you did
that.
Anyway, you probably won't care but I find it a little unfair. I was the first
one to propose reviving scalar type hints (hence the thread subject). I didn't
take over Andrea's RFC because I wanted to build something different and I
naively considered that taking over would restrict me to cosmetic changes
before running a new vote, as it remains Andrea's RFC, not mine. I realize I
was naïve and too honest because you took it over formally and, now, you
propose something really different. Now, as you know we won't probably propose
two competing RFCs, given the last flame war, you're free to propose it the way
you want. I will be less naïve next time.
François
> -----Message d'origine-----
> De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara
> Golemon
> Envoyé : mercredi 18 février 2015 02:56
> À : Nikita Popov
> Cc : Rasmus Lerdorf; PHP internals
> Objet : Re: [PHP-DEV] Scalar Type Hints v0.4
>
> On Tue, Feb 17, 2015 at 5:05 PM, Nikita Popov <nikita....@gmail.com>
> wrote:
> > This is exactly what I fear will happen with an arginfo based approach. If
> > even fundamental aspects like the "123" vs 123 (or true vs 1) distinction
> > are suppressed for internal functions, this isn't a strict typing mode, it's
> > just a weak typing mode with slightly different rules.
> >
> By the way, I realize I wasn't clear in my previous reply to you. I
> don't mean to dismiss your position and the proposal I put forth was
> just to get a feel for people's gut reactions to it. Your gut
> reaction is clearly negative and that will be taken into account when
> I put up 0.4 of the RFC which may or may not look like this proposal,
> depending on what others have to say about it.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
