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

[Pavel Kouřil]

On Mon, Jan 25, 2016 at 6:05 AM, Stanislav Malyshev  wrote:
> Hi!
>
>> Now, if we are still adamant on coming up with a CoC first I would like
>> to put forward the following 3 documents as alternatives for the
>> Contributor Covenant:
>>
>>
>> [A contribution policy for open source that
>> works](https://medium.com/@jmaynard/a-contribution-policy-for-open-source-that-works-bfc4600c9d83#.d53666v7u)
>
> This one deals with code contributions, but our discussion is wider. In
> fact, we never, as far as I could remember, had code contribution which
> was per se controversial. We did have ones that were controversial in
> that we disagreed on whether or not that code is doing what we actually
> want to do, but the code usually is not a problem.
>
>>
>> [The Code of
>> Merit](https://github.com/rosarior/Code-of-Merit/blob/master/CODE_OF_MERIT.md)
>
> I don't particularly like this approach, it sounds too defensive.
>

I already submitted it here once, so I'm skipping it - but I do
personally like how it says the project is about code.

>> [The Pragmatists Code of
>> Conduct](https://github.com/amacgregor/Pragmatists-Code-of-Conduct/blob/master/Prag-Code-of-Conduct.md)
>
>
> This one basically can be TLDRed as "behave as an adult". Which is nice
> if we were to agree what it means, but that is in no way automatic, thus
> I am afraid it is not enough :) Assuming good faith is a nice touch
> though, I like it.

Actually, IMHO it is totally enough. The best CoC would be just a CoC
with one point:
1. Be polite and behave like an adult.

This is still the second best approach though, the _best_ one is no CoC at all.

People need to realize one thing - not having a CoC doesn't make you
not welcoming or whatever; not listing all the SJW buzzwords in the
rules doesn't make something it unsafe place. Basically, I don't think
projects should act like a support group, but it seems it is the
direction the CoCs try to push them.

If somebody harrases you or something, you can always sue him - and
it's much more effective approach than reporting him to the projects
he is a part of.

Regards
Pavel Kouril

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

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

[Pavel Kouřil]

On Wed, Jan 20, 2016 at 10:20 PM, Derick Rethans <der...@php.net> wrote:
> On Wed, 20 Jan 2016, Pavel Kouřil wrote:
>
>> On Wed, Jan 20, 2016 at 8:04 PM, Derick Rethans <der...@derickrethans.nl> 
>> wrote:
>> >
>> > I've decided to re-propose the CoC RFC. There are many reasons for it,
>> > but there are a few points I want to make.
>>
>> if you still insists on some CoC, maybe you could at least look into
>> something else than the "Contributor Covenant"?
>>
>> For example, http://code-of-merit.org/ seems much more reasonable in
>> "getting the things done" than the Covenant.
>
> Sure - I would very much appreciate a list of things to look at. Would
> you have time to suggest a list with C of C's? It is unlikely that one
> will cover it all anyway. Something that (stolen the idea from twitter)
> has a good list of *positive* core values is also in my opinion
> important to have.
>
> cheers,
> Derick

Hi,

unfortunately, I don't have time for that (or at least not now). :(

The other thing is, I honestly don't believe you even need a CoC - and
if you really DO need it, it should be as short as possible, basically
something like "write code/rfcs, politely discuss it and don't discuss
anything not related to project on project forums/mailing lists/etc."
should be totally enough. The longer the CoC gets, the more "clutter"
it will have - as you can see in the Covenant.

(This is why I find the Code of Merit much better than Covenant, even
though it is IMHO still too long - and the fact it doesn't have
approximately 1/3 or 1/4 of the text dedicated to listing abusive
behavior and the general equality stuff, like Covenant does. And that
it doesn't try to control people outside of the project.)

Regards
PK

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

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

[Pavel Kouřil]

On Wed, Jan 20, 2016 at 8:04 PM, Derick Rethans  wrote:
> Hi,
>
> I've decided to re-propose the CoC RFC. There are many reasons for it,
> but there are a few points I want to make.
>
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Hello,

if you still insists on some CoC, maybe you could at least look into
something else than the "Contributor Covenant"?

For example, http://code-of-merit.org/ seems much more reasonable in
"getting the things done" than the Covenant.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] [DISCUSSION]: Closure from callable

[Pavel Kouřil]

On Sun, Oct 4, 2015 at 12:41 PM, Marco Pivetta <ocram...@gmail.com> wrote:
> As mentioned already by Andrea: why not just a named constructor on the
> closure class, like `Closure::fromCallable(callable $callable)`?
> Much simpler, easier to find, etc etc...
> On Sep 29, 2015 11:23, "Dan Ackroyd" <dan...@basereality.com> wrote:
>
>> Hello internals,
>>
>> I'd like to start a discussion of a proposal to allow closures to be
>> created in user-land without having to use a whole lot of reflection
>> code.
>>
>> https://wiki.php.net/rfc/closurefromcallable
>>
>> Thanks to Joe and Bob for the assistance in the patch.
>>
>> cheers
>> Dan
>> Ack
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

Hello,

and what about changing the empty ctor of Closure to
__construct(callable $callable)?

And the usage would be new Closure([$this, 'abc']);?

Regards
Pavel Kouřil

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

Re: [PHP-DEV] [RFC] Arrow Functions

[Pavel Kouřil]

On Sat, Oct 3, 2015 at 1:17 AM, Levi Morrison <morrison.l...@gmail.com> wrote:
> I messaged the list about this feature before I had the RFC written up
> for it. The RFC[1] is slightly different from what I proposed in the
> previous thread, so please read the RFC to make sure you understand
> what is being proposed before replying here.
>
> Here's a small example:
>
> $y = 10;
> $result = array_map(function($x) => $x + $y, [1, 2, 3]);
>
> // $result is [11, 12, 13]
>
> Thanks for people who have participated in conversation so far, as
> well as those who participated in Bob's short closures proposal as
> well.
>
>   [1]: https://wiki.php.net/rfc/arrow_functions
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello,

thanks for another proposal on this feature. :)

As I said in the previous e-mails, I'm not really fan of the
"function" prefix - because it has the same prefix as the "long
declarations". Just by removing the { } for =>, the autobinding also
goes into place* and also only one expression is allowed, but the
"beggining" stays the same (that being function ($x)).

The function keyword also "collides" with the future scope with
multiple statements.

function ($x) use ($a, $b, $c) { $z = foo($a, $b); return $c($z, $x); }
function ($x) => { $z = foo($a, $b); return $c($z, $x); }

Now the possible confussion with the different scoping rules would be
even bigger, IMHO. (Disclaimer: I am huge fan of those autoimports and
think that without them, the RFC doesn't technically bring anything
important.)

Also, I'm not a fan of the "fn" prefix, because then you would have
two ways of writing "function", and people would probably want being
able to use "fn" for named functions as well, bringing inconsistency
into language. Also, this would requiring making "fn" a reserved word,
breaking some applications - wouldn't it?

Personally  I'd prefer the \ prefix you also mention as possible in
your RFC. It's also AFAIK used to denote lamba expression in another
languages already, so it might be familiar for some developers?

\(int $x) => $x * $y;
\() => foo()
\($x) => \($y) => \($z)

Yeah, this looks pretty nice.

Althought I'd honestly really prefer the Bob's syntax, but I
understand that you don't want to make some engine hacks to make it
working - but from userland developer's POV, that one was the best
(speaking as someone, who would use the syntax daily).

--

Regards
Pavel Kouřil

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

Re: [PHP-DEV] Arrow function expressions in PHP

[Pavel Kouřil]

On Tue, Sep 29, 2015 at 11:55 PM, Levi Morrison  wrote:

> Reading over the list I don't think people "are torn about" it. There
> are some detractors, sure, but there seem to be more detractors about
> symbol choice (~) and lack of type declarations.

Personally, I feel that without the auto import, the feature would be
totally useless. But yes, more people are not happy with the ~ choice.

> I disagree that `(int $x) => $x * 2` is vastly better than `fn (int
> $x) => $x * 2`. It *might* be better but so much better we should
> introduce backtracking into it? In my opinion that is very clear: no.
> Especially because this also makes it harder to write other tools for
> PHP.

The issue I have with the fn() prefix is that it looks "weird" in case
you are chaining multiples. And it looks like a function call, but it
isn't one.

fn($x) => fn($y) => fn($z)

How does hack solve this? Do they have backtracking in their parser?

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

Fwd: [PHP-DEV] Arrow function expressions in PHP

[Pavel Kouřil]

>
> How does hack solve this? Do they have backtracking in their parser?
>
> It was discussed earlier & Bob answered it, a T_LAMDA_OP is inserted
> by a token token-pre-parser before hitting the real parser, see:
>
> Subject: Re: [PHP-DEV] [RFC] [Discussion] Short Closures
> Date: Sun, 6 Sep 2015 17:59:57 -0700
> From: Sara Golemon 
> To: Bob Weinand 
> Copy: Björn Larsson , PHP Internals
> 
>
> Regards //Björn Larsson
>

(Resending, because I accidentally forgot to "Reply All".)

So, if I'm understanding this correctly - this approach wouldn't
require backtracking, and would make the simplest syntax possible?

Regards
PK

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

Re: [PHP-DEV] Arrow function expressions in PHP

[Pavel Kouřil]

On Tue, Sep 29, 2015 at 12:52 AM, Levi Morrison  wrote:
>
> I do not think it is feasible to make the parser do backtracking or
> anything of that sort. How do others feel?
>
>> PS: the [fn($x) => $x * 2] seems ambigous, from reader's POV; key of
>> the item is result of fn($x) and value is $x * 2? Also, it would be a
>> huge BC break with not allowing you to name functions fn(), wouldn't
>> it?
>
> This is not a huge backwards compatibility break, no. It is a small
> break. This is one reason `fn` is not necessarily what I will be
> proposing and want to hear more feedback. Note that the `function`
> version wouldn't be possible to be confused *at all*:
>
> // function($x) isn't allowed for function name
> // so this is very unambiguous
> [function($x) => $x * 2];
>
> Also note that using closures in array literals is not really that common.

When you choose the function($x) ~> $x * 2 (or with ==> or =>
operator), you end up saving around 5 or 6 characters from the "long
declaration", ending up with "not-so-short closures" instead. You save
a little bit more if you have the implicit "use", but that's one thing
people are torn about, by looking at the discussion about the RFC, but
I think it's too long, for "short closures".

Would making the parser do some backtracking be really that bad -
especially since the option would end up with the IMHO most convenient
option for actual users of the feature?

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

Re: [PHP-DEV] Arrow function expressions in PHP

[Pavel Kouřil]

On Sat, Sep 26, 2015 at 6:17 PM, Levi Morrison <le...@php.net> wrote:
> (Email in gist format:
> https://gist.github.com/morrisonlevi/fa7984c04ff176b5a87c)
>
> In EcmaScript 2015 (ES6) the expression `(x) => x * 2` means to create
> an anonymous function with one parameter `x` that will return `x * 2`.
> For example:
>
> (x) => x * 2
> // is equivalent to:
> function(x) { return x * 2; }
>
> A modified example from [documentation by Mozilla Developer
> Network][1] page demonstrates how they are useful:
>
> var a = [
> "Hydrogen",
> "Helium",
> "Lithium",
> "Beryl­lium"
> ];
>
> var a2 = a.map(function(s){ return s.length }); // pre-ES6
>
> var a3 = a.map((s) => s.length); // ES6
>
> There has been some talk about how we can use arrow function
> expressions in PHP. In PHP using the same syntax would have some
> ambiguities:
>
> // Does this mean:
> //   1. Create an array key with the result of `($x)` and a value
> with `$x * 2`
> //   2. Create an array with one value that is an anonymous function
> [($x) => $x * 2]
>
> // Does this mean:
> //   1. Yield a key with the result of `($x)` and a value with `$x * 2`
> //   2. Yield an anonymous function
> yield ($x) => $x * 2;
>
> This is why Bob Weinand [proposed][2] using `~>` instead of `=>`.
> However, if we allow type declarations there is another issue. In the
> definition `(Type &$x) => expr` the `(Type &$var)` part can parse as
> "take constant `Type` and variable `$var` and do a bitwise and `&`
> operation." After that the `=>` will be an unexpected token. Even
> though the rule would be invalid the parser doesn't know that far
> ahead it will error and it doesn't know which rule to pick. Changing
> the token from `=>` to `~>` doesn't affect this issue.
>
> We could solve the first ambiguities with prefering the current
> meaning with `key => value` and requiring the meaning with closures to
> wrap them in `()`. We could solve the latter ambiguity with a
> backtracking parser since it will eventually error and then know to
> pick the other rule. However, I really think this is a bad idea.
>
> So how can we have shorter closures without this mess? One simple way
> is to require the `function` prefix:
>
> // clearly an array with an anonymous function
> [function($x) => $x * 2];
>
> // clearly yields an anonymous function
> yield function($x) => $x * 2;
>
> // clearly an anonymous function
> function(Type &$x) => expr;
>
> Requiring the `function` prefix mitigates one of the value parts of
> arrow functions: they are short.
>
> Another option would be to resolve the ambiguities with keys and
> values but to change the type information in parameters:
>
> (&$input: array) => expr
>
> By putting the type after the variable (similar to how we declare
> return types) we no longer have the issues with mis-parsing. Of
> course, that's not how we declare parameter types currently. I think
> we would need to permit it everywhere and deprecate the current syntax
> with the type being prefixed. (By deprecate I mean in PHP 8 and not
> remove it until PHP 9 or later)
>
> I would prefer that we shorten the `function` keyword to `fn`:
>
> [fn($x) => $x * 2]
>
> This preserves the shortness of the expression while providing
> unambiguous, simple parsing. Of course, now we have a similar issue:
> we have both `fn` and `function`.
>
> What concerns do you have about `fn($x) => $x * 2` or `function($x) =>
> $x * 2`? I will be writing a proper RFC later but I wanted to get
> discussion going now.
>
>   [1]: 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
>   [2]: https://wiki.php.net/rfc/short_closures
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


Hello,

personally, as a purely userland dev, I feel that the correct syntax
would be the "simplest" one - and that's imho the (Type &$x) ==> expr

Or the version with ~> operator - I don't care which one gets in,
althought I would rather see the ==> one. :)

I understand that there might be some ambiguity in the parser that
would need to be solved by backtracking, but for using the language,
the "simplest" option should IMHO be the correct one. Also not
introducing any more "stuff" (like new parameter types syntax) would
be a plus.

For the need to have a single parameter enclosed with ( ) - by
thinking more and m

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

[Pavel Kouřil]

On Tue, Sep 22, 2015 at 3:59 AM, Bob Weinand <bobw...@hotmail.com> wrote:
> Hey,
>
> Thanks for all your feedback in the discussion thread!
>
> So, before I start the vote, just two quick notes:
> I've added two notes about the statement syntax and the single variable use.
> Though a few people complained, I'm not switching to the ==> operator, as I 
> noticed many people expected typehints to work (they don't due to parser 
> limitations) when they compared to Hack's short Closures. It also allows us 
> to differ syntax-wise [e.g. for typehints] from Hack without causing any 
> confusion later. Which should be the smartest choice: Avoid conflicts. (If 
> anyone strongly feels against that, he may vote no, but I would like to not 
> bikeshed that in this Vote thread, but leave it free for eventual actual 
> issues.)
>
> Now, the link to the RFC about Short Closures:
> https://wiki.php.net/rfc/short_closures
> or straight ahead to the vote:
> https://wiki.php.net/rfc/short_closures#vote
>
> Thanks,
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello,

since the RFC doesn't look like it will pass, I have a question about
RFC process - will you be able to "fix" the RFC and submit it for vote
again with targeting PHP 7.1?

The biggest issues seem to be
- ~> operator instead of ==>
- missing type hints
- auto imports

If probably the first two would be resolved, then maybe the RFC could
get accepted? I personally don't understand the 3rd complain, since
having to use() everything would make it "not-so-short closures".

I also remember people not liking the option not to have parenthesis
with single parameter. I was thinking about this, and with the type
hints, it would be probably better anyways to have the ( ) required,
so that would be just a single use case where they wouldn't be
required - so is there a point in keeping this special use case?

Regards
Pavel Kouřil

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

Re: [PHP-DEV] Implementing Generics, and none scalar default properties.

[Pavel Kouřil]

On Fri, Sep 25, 2015 at 11:53 PM, Stanislav Malyshev
<smalys...@gmail.com> wrote:
> Hi!
>
>> I'm thinking primarily of the benefit to base or abstract classes.  For
>
> Both can have constructors.
>
>> base classes which expect certain properties be set, they are exposed to
>> the danger of remaining unset if the derived class overrides the
>> constructor without calling the parent.
>
> You should always call the parent ctor. There's pretty much no reason to
> ever not to call parent ctor.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>

Since there is no reason not to call parent ctor, maybe PHP should
somehow make every class have default empty ctor, if it doesn't have
one defined already - so you can write automatically
parent::__construct() everywhere?

Regards
Pavel Kouřil

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

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

[Pavel Kouřil]

On Fri, Sep 25, 2015 at 9:44 PM, Bishop Bettini <bis...@php.net> wrote:
> Hi,
>
> On Mon, Sep 21, 2015 at 9:59 PM, Bob Weinand <bobw...@hotmail.com> wrote:
>
>> So, before I start the vote, just two quick notes:
>> I've added two notes about the statement syntax and the single variable
>> use.
>> Though a few people complained, I'm not switching to the ==> operator, as
>> I noticed many people expected typehints to work (they don't due to parser
>> limitations) when they compared to Hack's short Closures. It also allows us
>> to differ syntax-wise [e.g. for typehints] from Hack without causing any
>> confusion later. Which should be the smartest choice: Avoid conflicts. (If
>> anyone strongly feels against that, he may vote no, but I would like to not
>> bikeshed that in this Vote thread, but leave it free for eventual actual
>> issues.)
>>
>
> I voted "no" because I'm against the automatic use () and introducing a new
> symbol.
>
> An earlier short closure RFC [1] supports explicit import, and I would want
> to see explicit import mandated.  And rather than inventing a new symbol,
> why not just re-purpose 'as' in this context?
>
> function sumEventScores($events, $scores) {
> $types = array_map($event as $event['type'], $events);
> return array_reduce($types, ($sum, $type) as $sum + $scores[$type]);
> }
>
> 'use' is already purposed in three places, I don't see why 'as' can't also
> be in three places.  Though I've not checked the engine source to see the
> actual effort, so this just may be astronaut architecting.
>
> Anyway, thanks to Bob for his hard work pulling this together and everyone
> for arguing it out.  That's what makes PHP great.
>
> Sincerely,
> bishop
>
> [1]: https://wiki.php.net/rfc/short-syntax-for-anonymous-function

Hello,

I can't grasp the "intent" behind the "as". Reading it like "parameter
$sum and parameter type as $sum + $scores[$type]" seems pretty
confusing to me.

Also, if we look at the example from RFC - with your "as" suggestion,
it would look like this:

function reduce(callable $fn) {
return $initial as $input as {
$accumulator = $initial;
foreach ($input as $value) {
$accumulator = $fn($accumulator, $value);
}
return $accumulator;
};
}

This doesn't seem like the right way to me. :(

Regards
Pavel Kouřil

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

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

[Pavel Kouřil]

On Sat, Sep 26, 2015 at 9:57 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi!
>
>> since the RFC doesn't look like it will pass, I have a question about
>> RFC process - will you be able to "fix" the RFC and submit it for vote
>> again with targeting PHP 7.1?
>
> Yes, but see:
> https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals
>
> So, to make another try, the RFC needs to be substantially amended or
> resubmitted in 6 months.
>
>> The biggest issues seem to be
>> - ~> operator instead of ==>
>> - missing type hints
>> - auto imports
>
> I would say changing these would be substantial. Just changing the
> operator - not sure, maybe if it is clear that with this change vote
> would pass (which currently isn't clear at all).
> --
> Stas Malyshev
> smalys...@gmail.com

Seems you are right it's not clear after all; I skimmed through all
the e-mails in this thread and found only around 5 people stating that
the ~> operator was their reason to vote "no"; while I was writing the
previous e-mail, I really thought more people stated that here; on the
other hand, we don't know why the rest of those ~30 people voted no,
so it's really hard to say.

Anyways, thanks for sending the Ressurecting rejected proposals info. :)

Regards
Pavel Kouřil

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

Re: [PHP-DEV] Let's discuss enums!

[Pavel Kouřil]

On Fri, Sep 18, 2015 at 1:06 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> Hi All,
>
> This has come up in passing a few times recently, but I'm not sure there's
> ever been a dedicated discussion of it: would it be useful for PHP to have a
> built-in Enumeration type, and if so, how should it look?
>
> Many other languages have enum types, with varying functionality. The
> central concept is always that there's some declared type with a bunch of
> named constants, but beyond that there's a lot of variability: for starters,
> is it a type of object, a special way of naming integers, or an uncomparable
> type more like booleans and nulls?
>
>
> So, what are anyone's thoughts? Am I rambling on too much as usual? ;)
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>

Hi,

personally, I feel that you should be able to assign numeric value to
each element (and have them implicit if not specified).

This is imho better for serialization (but it can be done with names
as well, yeah) - but more importantly, it also allows usage with
bitwise operators, so you could use them as a "flags" (ie. $weekend =
Days::SATURDAY | Days::SUNDAY).

Regards
Pavel Kouřil

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

Re: [PHP-DEV] Re: [RFC] [Discussion] Short Closures

[Pavel Kouřil]

On Mon, Sep 7, 2015 at 8:24 AM, Marco Pivetta  wrote:
>
> The same usually applies to ~, {, }, [ and ].
> I personally stopped buying non-en_US keyboards and that's it.
> Basically, if you code you kinda want to use en_US layout anyway (or dvorak
> if you had too much free time).
> I realize that this is unfriendly to beginners, but the ~ already is part of
> the syntax of the language anyway.
>
> Marco Pivetta
>

Hi,

I know this is a problem with more symbols that just ~, and can be
really keyboard layout specific.

That's why I didn't mean it as a "blocker" for the ~ symbol, but more
like a thing to consider for the case the discussion would end up with
deciding between ==> and ~> with no real "preference". I'm sorry if it
did look differently. :)

Personally, I don't have an issue with writing either of those
variants and would be fine with either in the end (I can write ==> a
little bit faster and comfortably - since I can write it with just one
hand - but the difference is not THAT big), but I thought it's worth
mentioning.


PK

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

Re: [PHP-DEV] Re: [RFC] [Discussion] Short Closures

[Pavel Kouřil]

On Sun, Sep 6, 2015 at 11:54 PM, Andrea Faulds  wrote:
> Hi Bob,
>
> This has probably already come up, but I'd like to weigh in on the symbol
> choice.
>
> On the subject of syntax, ~> (let's call it the squiggle arrow) seems like a
> very poor choice compared to ==> (let's call it Hack's arrow).
>
> I think it's been mentioned that ==>, Hack's arrow, was thought to be likely
> to be confused with =>, the key/value separator in array() and foreach().
> But I'd argue this is actually rather unlikely, for two reasons.
>
> The first of these is that ==> is a whole column wider. So, if there's a
> smudge on the screen or something, you could still clearly distinguish ==>
> from =>. They're visually distinct, much like =, == and === are, which I'm
> sure any PHP programmer can tell apart.
>
> Second, => is only used in very limited contexts. You can't use => in a
> normal expression or statement. You can't mistake ($t ==> $f ==> $t) for ($t
> => $f => $t) for long, because the latter would never be a valid expression.
> And in the contexts where => does work, it's unlikely you'd be using a
> closure – at least, I can't think of a case where you'd want to create a
> numeric array of closures using a literal.
>
> For those two reasons, I don't agree that confusing ==> with => would be a
> big problem.
>
> Now ~>, the squiggle arrow, was supposedly chosen to reduce the likelihood
> of confusion. However, I would argue that it is actually *more* likely to
> cause confusion. In this case the potential confusion would be with ->, the
> object property dereference operator. I have two reasons for why the two
> operators would be confused, and they're the respective inverses of the
> reasons why => and ==> wouldn't.
>
> First, ~> visually takes up the same amount of space as ->, so if you have a
> small character size, a blurry or low-resolution screen, or poor eyesight,
> there's nothing aside from the very slight curvature (and maybe syntax
> highlighting, which does not yet exist) to distinguish ~> from ->.
>
> Second, ->, the object property dereference operator, is used in a wide
> range of contexts. It's a valid expression (and thus statement), and so
> would crop up in many places where ~>, the squiggle arrow, also would. A
> realistic example of this is the Church Booleans, an encoding of the boolean
> values "true" and "false" in the lambda calculus: "true" is a function that
> takes two arguments and returns the first, and "false" is a function that
> takes two arguments and returns the second. The "true" function would be
> written, using squiggle arrows, as ($a ~> $b ~> $a). Now, if you squint, can
> you tell that apart from ($a ~> $b -> $a)? Did you even notice the
> difference in that second expression? (The second squiggle arrow become a
> dereference operator.) I wouldn't be surprised if you didn't. And the
> difference wouldn't always be immediately obvious from context. Here, the
> unusual spacing might give it away (a variable property access would usually
> be $b->$a), but not everyone is going to put spaces around their squiggle
> arrows.
>
> For those two reasons alone, I think ~> is a poor choice. And that's without
> the ugliness issue: in some fonts, particularly Japanese ones, ~ is rendered
> at the top of the character box, like an overline. In such a font, ~> will
> not look like an arrow.
>
> You did mention that the HHVM team might find things easier if you chose ~>
> instead of ==>, given Hack already has ==>. Surely, though, that only
> matters if ==> has different semantics in PHP and Hack, yet this proposal
> matches Hack's implementation exactly, so far as I can tell. Also, it would
> be nice if PHP and Hack don't diverge when implementing the same features,
> unless there's a particularly good reason... it's not very kind to people
> who use both languages.
>
> So, to conclude, I would urge you to change the RFC to use ==> instead of
> ~>.
>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello,

these are all good points.

Also, I realized it's definitely harder to write ~ than =. On my
keyboard layout (Czech Qwerty) I have to do "right alt + shift + (key
above Tab)". I'm not sure how it is with other non-US keyboard
layouts, but it might be worth exploring before deciding on a symbol;
or maybe there's a possibility that my keyboard layout is just an
anomaly and you can write ~ on most keyboard layouts with a single key
(or double).

Regards
PK

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Pavel Kouřil]

On Fri, Sep 4, 2015 at 8:57 AM, Peter Lind <peter.e.l...@gmail.com> wrote:
> On 4 September 2015 at 08:44, Pavel Kouřil <pajou...@gmail.com> wrote:
>
> You're arguing that, subjectively, to you - parentheses make things harder
> to read. For others they clarify things.
> It should be obvious to everyone that this particular path of the discussion
> has about as much merit as tabs vs spaces.

Sure, it is subjective - but what isn't?

> That being the case, I would argue for consistency and simplicity. If you
> need parentheses for other variants of this, require parentheses all the way
> through. It will be simpler to learn and trip fewer people up.

Depends how you define simplicity. Because $a ~> $b ~> $c ~> $d is
IMHO more simple than ($a) ~> ((($b) ~> (($c) ~> $d($foo))) - which is
a result of the combination of amendments #2 and #3. I honestly do not
know if I wrote the parenthesis right now or not (probably not),
because there's simply just too many of them.

Sure, parenthesis can help people understand things, but I'd say that
at the same time, too many of them can be a problem as well (as the
fun name for LISP - "lost in stupid parenthesis" - suggests).

> Just think, if whoever constructed the if conditional hadnt thought "hey,
> let's be clever and save some keystrokes by making the curlies optional in
> some cases" we wouldn't have the multitude of bugs and security holes we
> know to exist, we wouldn't have to warn the young'uns against improper use
> of if, we wouldn't have to write codesniffer rules against single line ifs,
> etc, etc.
>
> Any argument to the effect of "let's be clever" or "it'll save some
> keystrokes" is void. Period.

This is not about saving characters, it's about not overcomplicating things.

>
> Regards
> Peter
>

Regards
PK

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Pavel Kouřil]

On Thu, Sep 3, 2015 at 11:56 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> Pavel Kouřil wrote on 03/09/2015 07:32:
>>
>> Amendment 2. Make the ~> operator non-associative
>
>
>> Why? Once you read documentation about how the operator works and what
>> it does, you will know it and writing the extra brackets seems
>> superfluos. And woudn't this complicate the parser even more? Also, if
>> you have no idea about functional programming whatsoever, this will be
>> hard to grasp in any syntax form, but the syntax isn't the problem in
>> that case (as I already said in previous email).
>
>
> Yeah, maybe this one is just me - I just find right-associativity really
> hard to read, whatever it's purpose. Maybe it's because I've only ever read
> left-to-right languages.
>
> As mentioned in a previous e-mail, when I look at "$a ~> $b ~> $c" it makes
> me think of a single chain where all the terms are somehow related, like "$a
> = $b = $c", rather than any kind of nesting. Maybe I'd get used to it, maybe
> it would be rare enough that I'd never need to.

Yeah, my guess is that most developers would use this just for more
simple array_map/array_filter/etc. usage, so you probably wouldn't
encounter this use case "in the wild" much.

But imagine having something like this (combined with your #3):

function partial($cb) { return ($left) ~> (($right) ~> $cb($left, $right)); }

I hope I got the parenthesination correct, because now there's a ton
of parenthesis and it's even harder to read (and write). If I had to
choose between amendments #3 and #2, I'd go with #3 just for the sake
of consistency - but I definitely wouldn't choose both of them
simultaneously.

But even just #3 seems kinda "harder" to read than the form without
any parenthesis.

function partial($cb) { return ($left) ~> ($right) ~> $cb($left, $right); }

I know the parenthesis are optional in just one scenario, but I'd
argue it's probably the most common one.

>> So you are taking a syntax that's supposed to be short and "clean" and
>> making it more complex by the amedments 3 and 4?
>
>
> No, I'm trying to think of compromises which address constructive criticisms
> people have made of the current proposal, such as the variety of syntax
> forms, and the implicit scoping of variables.
>
> To be clear, these are not demands or anything like that, just suggestions
> of how to move the discussion beyond "here's the proposal, take it or leave
> it".
>

Yes, I hope everyone is trying to move the discussion forwards,
because I would love to see this in some reasonable form in PHP.

In my personal order of "most reasonable" ammendments, it would be #1
> #3 > #2 > #4. The #1 I could even see getting positive feedback,
because for everything longer than one statement, people can use the
function () { ... } declaration (unlike in some other languages).

>
>> Btw. about your previous email and this syntax ending your career -
>> why would it?
>
>
> That wasn't my e-mail, it was one I replied to. I'm not against this
> proposal, I'm genuinely trying to find ways forward with it.
>

Oh, really sorry! I read a lot of those emails at the same time and
somehow got two emails mixed up together! :)


Regards
PK

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Pavel Kouřil]

On Thu, Sep 3, 2015 at 12:48 AM, Rowan Collins  wrote:
>
> So I would like to put forward for consideration these amendments to the
> proposal, in the spirit of compromise (in no particular order; numbers are
> just for reference in future discussion):
>
> Amendment 1. Only allow the single-expression form of the short syntax; full
> function bodies must be declared with the existing function(){ ... } syntax.
> This gives a clearer distinction between how the two syntaxes can be used.

This one sounds reasonable, but you'll probably get a RFC for almost
every upcoming version to allow the more complex bodies.

> Amendment 2. Make the ~> operator non-associative, so that lambdas returning
> lambdas would need an extra pair of brackets making the nesting explicit. To
> take one of Anthony's examples:
>
> function partial(callable $cb) {
> return $left ~> ( $right ~> $cb($left, $right) );
> }
>
> It's now at least clearer that there are two different anonymous functions
> here, even if it's not entirely clear what they're trying to achieve...
>

Why? Once you read documentation about how the operator works and what
it does, you will know it and writing the extra brackets seems
superfluos. And woudn't this complicate the parser even more? Also, if
you have no idea about functional programming whatsoever, this will be
hard to grasp in any syntax form, but the syntax isn't the problem in
that case (as I already said in previous email).

> Amendment 3. Make the parentheses around the argument list mandatory so that
> (if Amendment 1 is also adopted) there is only a single variant of the
> syntax, namely "( param list ) ~> expression".
>
>
> Amendment 4. Consider a syntax involving an explicit "use". This one
> requires a bit more exploration, but maybe something like:
> ( $a use $b ) ~> $a + $b
> or:
> ( $a ) use ( $b ) ~> $a + $b
>

So you are taking a syntax that's supposed to be short and "clean" and
making it more complex by the amedments 3 and 4? I wouldn't mind the
mandatory ( ) around parameters, but at the same time I think that
it's an useless rule and makes the written code more "cluttered" (too
much ( and ) imho make the code less readable).


Btw. about your previous email and this syntax ending your career -
why would it? Reading the documentation and doing a mental note of
"simplified anonymous function declaration with optional ( ) if
there's just one paramater and automatically returning the expression
or having a whole function body enclosed in { }" shouldn't be a
problem? This is definitely not a "write-only" code.

If you are afraid the syntax will make the code less readable - look
at other languages (not for the sake of "they do it too", but for "how
does the code using it look like"). I can only speak about C#, and it
feels like it fits there - even though the language has more verbose
constructs and stuff. This should IMHO be a natural fit for PHP.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Pavel Kouřil]

On Tue, Sep 1, 2015 at 10:45 AM, Tony Marston  wrote:
>
> This argument is irrelevant for several reasons:
> (1) I am not familiar with any of those languages, nor are many PHP users.
> (2) Just because other languages have such a feature is not a good reason
> for adding it into PHP.
> (3) Introducing write-only (less readable or completely unreadable) code
> will ALWAYS be a barrier to those who have used nothing but PHP for the last
> 10+ years.
>
> As H. Abelson and G. Sussman wrote in 1984: "Programs must be written for
> people to read, and only incidentally for machines to execute." Writing
> compact code which has several functions compressed into a single line may
> be clever where you come from, but it leaves new readers scratching their
> heads saying "WTF!!".
>
> As a follower of the KISS principle I always aim to write simple, readable
> code, and my critics always say "It is too simple. Proper OO is supposed to
> be more complex than that".  The mark of genius is to achieve complex things
> in a simple manner, not to achieve simple things in a complex manner.
>

The thing is, every feature and syntax can be used to create some
unreadable "monstrosity". And often, at the same time, they can be
used to create readable elegant code. :)

Sure, "elegant" and "readable" is subjective, and for someone who
never heard of FP, this might be befuddling. But so is probably the
entire concept of anonymous functions and high order functions. Does
it mean PHP shouldn't support passing functions to functions at all? I
think not.

Also, once you know ~> is a syntax sugar for anonymous functions (and
understand them), I don't think there's any general readability
problem, and in some cases, it makes the code even more readable
(subjective experience from other languages). And if the programmer
doesn't understand the concept of anonymous functions at all, he will
be lost anyways and shorter or longer syntax doesn't matter.

I personally wouldn't even mind just having a version that supports
[variables] ~> [single expression], but since other languages support
having whole function body with return statement, I think it's worth
considering adding it too.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Pavel Kouřil]

On Tue, Sep 1, 2015 at 10:44 AM, Anthony Ferrara  wrote:
>> I'm not sure about the "auto using" of all variables though; wouldnt
>> it be possible to statically check for the used variables and only
>> import what's needed, for performance reasons?
>
> That's precisely what's happening. Not all variables are bound, only
> those that are used. Somehow somewhere in this thread the confusion
> was implied that the entire scope is copied.
>

Oh, nice - thanks for explaining that. :)

>> Also, how hard would it be to add type hints (only for parameters)?
>> Sometimes they are needed to make the IDE know the variable type
>> because it can't be guessed automatically. I know about your note in
>> RFC,this is just a question to other internal members.Return type can
>> be infered by IDEs from the simple expresion quite easily.
>>
>> PS: would "() ~> foo()" work? I think it should, but I couldn't find a
>> mention about it in RFC. :)
>
> Typing on closures is outside the scope of this RFC.
>
> With that said, I'd love to hear and see examples of this. It's
> something I definitely want to do, just haven't come up with a good
> enough way to do it...
>

Yeah, I know it's outside of the scope of the RFC, it was more of a
general question whether or not it would be possible in the future.
Also, exactly what examples would you want to see?

Pavel

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Pavel Kouřil]

On Mon, Aug 31, 2015 at 9:29 PM, Bob Weinand  wrote:
> I had this RFC in draft since some time, but delayed it due to all the 
> ongoing PHP 7 discussions. Also we have no master branch to merge features in 
> until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be 
> the next version ;-)):
>
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>
> Hoping for constructive feedback,
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hi,

as a purely userland developer, I would definitely appreciate the
shorthand function for anonymous functions; having tons of stuff like
"function ($x) { return $x * 2; }"  makes the code less readable in
the end.

I'm not sure about the "auto using" of all variables though; wouldnt
it be possible to statically check for the used variables and only
import what's needed, for performance reasons?

Also, how hard would it be to add type hints (only for parameters)?
Sometimes they are needed to make the IDE know the variable type
because it can't be guessed automatically. I know about your note in
RFC,this is just a question to other internal members.Return type can
be infered by IDEs from the simple expresion quite easily.

PS: would "() ~> foo()" work? I think it should, but I couldn't find a
mention about it in RFC. :)

Regards
Pavel Kouril

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

Re: [PHP-DEV] Generic classes and methods RFC

[Pavel Kouřil]

On Mon, Aug 31, 2015 at 10:31 PM, Ben Scholzen 'DASPRiD'
 wrote:
> Hello,
>
> I've written up an RFC for supporting generic classes and methods in PHP,
> and I'd love to hear your thoughts about it.
>
> https://wiki.php.net/rfc/generics
>
> Cheers,
> --
> Ben Scholzen 'DASPRiD'
> Community Review Team Member | m...@dasprids.de
> Zend Framework   | http://www.dasprids.de
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello,

I would love to see generics in PHP, but I have a few questions for your RFC.

class Bazz

Why did you use this syntax for forcing extending/implementation? I
know this is the syntax C# uses, but it doesn't fit PHP. I think it
should be "extends" or "implements", because in PHP : has a different
meaning.

Also, how do you specify multiple constraints?

Do you have any idea how it would work internally and if there was
some performance hit while using generics, and if it would also slow
down existing apps that don't use generics?

I hope this RFC will have positive comments, and someone who is
capable of writing C will help you out with it so there's a patch for
people to review - because I'm not sure if this RFC can get anywhere
without a patch. :(

Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Exceptions in the engine

[Pavel Kouřil]

On Wed, May 13, 2015 at 9:38 AM, Sebastian Bergmann sebast...@php.net wrote:
 Am 13.05.2015 um 08:30 schrieb Pierre Joye:
 Why don't you do it? You have access and you are a very good writer.
 No big C knowledge required either in this case :)

  There was/is consensus on what I proposed back in February:

* Introduce a Throwable interface
* Let Exception implement the Throwable interface
* Introduce an Error class that implements the Throwable interface
* Use Error class as base class for exceptions raised by the engine

  But as simple as the above sounds it is complicated (at least for
  me) to implement (properly). Here's what I was able to come up with:

https://github.com/php/php-src/pull/1274

  This should give us the following:

interface Throwable {}
abstract class BaseException implements Throwable {}
class Exception extends BaseException {}
class Error extends BaseException {}
class EngineError extends Error {}
class ParseError extends Error {}
class TypeError extends Error {}

  I am not sure whether we still want the abstract BaseException
  class. I left it in because I couldn't figure out how to remove
  it without breaking Exception and Error.

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


Hello,

I personally dislike the BaseException. Does it have to be there?

If it's just for sharing some behavior between Exception and Error,
wouldn't trait be an acceptable (but definitely not perfect) solution?

Regards
Pavel Kouril

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

Re: [PHP-DEV] Naming of 'weak' type hints

[Pavel Kouřil]

On Mon, Mar 30, 2015 at 4:16 PM, Zeev Suraski z...@zend.com wrote:
 All,



 One thing that I think we should change is how we refer to the ‘weak’ type
 hints.  The word ‘weak’ has a negative ring to it, and considering this is
 how the language behaves across the board it’s a pretty bad name for this
 feature.



 Personally I think we should go for ‘dynamic’ when we document it, as this
 is the common way to refer to this behavior (dynamic languages).  We could
 also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’,
 although I think we can easily do without introducing a new word into the
 vocabulary here.



 Thoughts?



 Zeev


Hello,

I would definitely stick with weak; it is common naming used across
many languages and textbooks.

Also, why is the strongly typed mode named strict anyways? If
anything should change, it should be strict to strong, so PHP doesn't
look like a special snowflake.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[Pavel Kouřil]

On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com wrote:
 All,

 Voting has been closed on the scalar type declarations v0.5 RFC:

 https://wiki.php.net/rfc/scalar_type_hints_v5

 At a final score of 108:48, it has been accepted for PHP 7.

 Thank you.

 Anthony

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


Hello,

how will these examples work btw?

// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};

// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });



// c.php
?php
function foo($fn) {
$fn(1);
};

// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });

I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.

But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/


Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[Pavel Kouřil]

On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com wrote:

 On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:

 On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com
 wrote:
  All,
 
  Voting has been closed on the scalar type declarations v0.5 RFC:
 
  https://wiki.php.net/rfc/scalar_type_hints_v5
 
  At a final score of 108:48, it has been accepted for PHP 7.
 
  Thank you.
 
  Anthony
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 

 Hello,

 how will these examples work btw?

 // a.php
 ?php
 declare(strict_types=1);
 function foo($fn) {
 $fn(1);
 };

 // b.php
 ?php
 require 'a.php';
 foo(function (int $a) { return $a * 2; });



 // c.php
 ?php
 function foo($fn) {
 $fn(1);
 };

 // d.php
 ?php
 declare(strict_types=1);
 require 'c.php';
 foo(function (int $a) { return $a * 2; });

 I can't find this in the RFC. I'd intuitively expect error in the
 first example and the second one to work OK.

 But at the same time, if there will be an error in the first example,
 it is IMHO a huge flaw with this RFC. :/

 Git clone, compile, try, report.

 It sounds pretty straight forward to me instead of asking the same questions
 (in various form but it ends to the same answer).

 And the patch should be applied sooner rather than later. So we can fix bugs
 if there are actual ones in the current implementation.

Hello,

if I had time to set up the compilation of PHP on Windows, I'd do it -
but I don't. I wanted to try it myself via http://3v4l.org/, but it
unfortunately doesn't support multiple files.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[Pavel Kouřil]

On Wednesday, March 18, 2015, Patrick ALLAERT patrickalla...@php.net
wrote:
 Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajou...@gmail.com a écrit :

 Hello,

 how will these examples work btw?

 // a.php
 ?php
 declare(strict_types=1);
 function foo($fn) {
 $fn(1);
 };

 // b.php
 ?php
 require 'a.php';
 foo(function (int $a) { return $a * 2; });



 // c.php
 ?php
 function foo($fn) {
 $fn(1);
 };

 // d.php
 ?php
 declare(strict_types=1);
 require 'c.php';
 foo(function (int $a) { return $a * 2; });

 I can't find this in the RFC. I'd intuitively expect error in the
 first example and the second one to work OK.

 Your intuition is correct.


 But at the same time, if there will be an error in the first example,
 it is IMHO a huge flaw with this RFC. :/

 Flaw vs. design choice. This is one of the reason that this aspect,
amongst others, has been very debated.

But if it works this way, the strict mode isn't optional and users of a
library NEED to care which mode the library uses?

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[Pavel Kouřil]

On Wed, Mar 18, 2015 at 1:47 PM, Anatol Belski anatol@belski.net wrote:
 Pavel,

 On Wed, March 18, 2015 11:05, Pavel Kouřil wrote:
 On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com
 wrote:


 On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:


 On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara
 ircmax...@gmail.com
 wrote:

 All,


 Voting has been closed on the scalar type declarations v0.5 RFC:


 https://wiki.php.net/rfc/scalar_type_hints_v5


 At a final score of 108:48, it has been accepted for PHP 7.


 Thank you.


 Anthony


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



 Hello,


 how will these examples work btw?

 // a.php
 ?php
 declare(strict_types=1); function foo($fn) { $fn(1);
 };


 // b.php
 ?php
 require 'a.php'; foo(function (int $a) { return $a * 2; });



 // c.php
 ?php
 function foo($fn) { $fn(1);
 };


 // d.php
 ?php
 declare(strict_types=1); require 'c.php'; foo(function (int $a) { return
 $a * 2; });


 I can't find this in the RFC. I'd intuitively expect error in the
 first example and the second one to work OK.

 But at the same time, if there will be an error in the first example,
  it is IMHO a huge flaw with this RFC. :/

 Git clone, compile, try, report.


 It sounds pretty straight forward to me instead of asking the same
 questions (in various form but it ends to the same answer).


 And the patch should be applied sooner rather than later. So we can fix
  bugs if there are actual ones in the current implementation.

 Hello,


 if I had time to set up the compilation of PHP on Windows, I'd do it - but
 I don't. I wanted to try it myself via http://3v4l.org/, but it
 unfortunately doesn't support multiple files.


 for anyone needing to test on Windows, there was builds for an older RFC
 version

 http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_2_strict_mode/

 but I just made quick builds for the current as well

 http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_v5/

 So you've got the choice.

 Cheers

 Anatol


Hello,

thanks a lot, I'll play with it this evening. :)

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[Pavel Kouřil]

On Wed, Mar 18, 2015 at 1:47 PM, Anatol Belski anatol@belski.net wrote:
 Pavel,

 On Wed, March 18, 2015 11:05, Pavel Kouřil wrote:
 On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com
 wrote:


 On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:


 On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara
 ircmax...@gmail.com
 wrote:

 All,


 Voting has been closed on the scalar type declarations v0.5 RFC:


 https://wiki.php.net/rfc/scalar_type_hints_v5


 At a final score of 108:48, it has been accepted for PHP 7.


 Thank you.


 Anthony


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



 Hello,


 how will these examples work btw?

 // a.php
 ?php
 declare(strict_types=1); function foo($fn) { $fn(1);
 };


 // b.php
 ?php
 require 'a.php'; foo(function (int $a) { return $a * 2; });



 // c.php
 ?php
 function foo($fn) { $fn(1);
 };


 // d.php
 ?php
 declare(strict_types=1); require 'c.php'; foo(function (int $a) { return
 $a * 2; });


 I can't find this in the RFC. I'd intuitively expect error in the
 first example and the second one to work OK.

 But at the same time, if there will be an error in the first example,
  it is IMHO a huge flaw with this RFC. :/

 Git clone, compile, try, report.


 It sounds pretty straight forward to me instead of asking the same
 questions (in various form but it ends to the same answer).


 And the patch should be applied sooner rather than later. So we can fix
  bugs if there are actual ones in the current implementation.

 Hello,


 if I had time to set up the compilation of PHP on Windows, I'd do it - but
 I don't. I wanted to try it myself via http://3v4l.org/, but it
 unfortunately doesn't support multiple files.


 for anyone needing to test on Windows, there was builds for an older RFC
 version

 http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_2_strict_mode/

 but I just made quick builds for the current as well

 http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_v5/

 So you've got the choice.

 Cheers

 Anatol


Hello,

I've tried the build, and it seems like it's in the strict mode 100%
by default, and the declare statement doesn't recognize strict_types
(PHP Warning: Unsupported declare 'strict_types'). Is this
intentional?

Regards
Pavel Koruil

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

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[Pavel Kouřil]

On Wed, Mar 18, 2015 at 1:13 PM, Nikita Nefedov inefe...@gmail.com wrote:

 On 18 Mar 2015 14:32, Pavel Kouřil pajou...@gmail.com wrote:

 On Wednesday, March 18, 2015, Patrick ALLAERT patrickalla...@php.net
 wrote:
  Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajou...@gmail.com a écrit
  :
 
  Hello,
 
  how will these examples work btw?
 
  // a.php
  ?php
  declare(strict_types=1);
  function foo($fn) {
  $fn(1);
  };
 
  // b.php
  ?php
  require 'a.php';
  foo(function (int $a) { return $a * 2; });
 
 
 
  // c.php
  ?php
  function foo($fn) {
  $fn(1);
  };
 
  // d.php
  ?php
  declare(strict_types=1);
  require 'c.php';
  foo(function (int $a) { return $a * 2; });
 
  I can't find this in the RFC. I'd intuitively expect error in the
  first example and the second one to work OK.
 
  Your intuition is correct.
 
 
  But at the same time, if there will be an error in the first example,
  it is IMHO a huge flaw with this RFC. :/
 
  Flaw vs. design choice. This is one of the reason that this aspect,
 amongst others, has been very debated.

 But if it works this way, the strict mode isn't optional and users of a
 library NEED to care which mode the library uses?

 If library chose to use strict mode then the odds are it will take care of
 passing right types to callbacks and interfaced methods.

 Saying that strict mode isn't optional is not true, I don't see why you have
 made this conclusion.

Hello,

I made that conclusion because in the first example, the library kinda
forces strict mode rules on the caller, even if he doesn't want to use
strict mode - this makes the interoperability of the two modes
problematic.

Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[Pavel Kouřil]

On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com wrote:
 On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:

 Hello,

 I made that conclusion because in the first example, the library kinda
 forces strict mode rules on the caller, even if he doesn't want to use
 strict mode - this makes the interoperability of the two modes
 problematic.

 This is incorrect, library force itself to use right types, not you. I don't
 see any problems here. The only thing that for sure lacks in PHP and that
 would make STH better is callable signature types.


Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?

 Also, the other possible outcome of the scenario (respecting the mode
 of the place where the callback is declared), is IMHO problematic as
 well, because it does not respect the strict mode of the place where
 it is called, making it inconsistent with how the dual mode RFC works
 in general.

 It doesn't matter where the callback or function was declared, it only
 matters where it was called. It pretty much is consistent.

This was just a comment about how it would be (also) wrong to solve it
the other way around.

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

Re: [PHP-DEV] strict_types should be renamed raise_type_error. WAS: About declare(strict_types = 1)

[Pavel Kouřil]

On Mon, Mar 16, 2015 at 8:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi all,

 I think this is important, but not many people realize the importance.
 Therefore I created this as a new thread at the last minutes of vote.

 On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz den...@birkholz.biz
  wrote:

 Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
   lib.php
   ?php
 declare(strict_types = 1);
 function add(int $a, int $b) {
 }
 
   ?php
add($_GET['a'], $_GET['b']);
 
   that means, I need to add a lots of (int) while I try to call a
  function in a library which is not written by myself.

 that is not right and has been discussed a thousand times over.
 The declare changes the rules only for function calls in the file it is
 declared in.

 so:
 lib.php:
 ?php
 declare(strict_types = 1);
 function foo(int $a) {
 // no function call here
 }
 ?
 The declare here does just nothing.

 ?php
 require lib.php;
 foo(123); // will work
 ?

 ?php
 declare(strict_types = 1);
 require lib.php;
 foo(123); // will give an error
 ?


 If this kind of behavior is allowed, why strict mode is called strict?
 It's not
 strict at all if mode could be overridden.

 strict_mode is just controlling errors, then it should be named as error
 controlling directive and raise E_WARNING/E_TYPE or whatever.

 Even if what its controlling is error that can be overridden by caller, yet
 calling it strict_types is not correct. Proper name would be something
 like raise_type_error.

 Let's see how it looks if strict_types is renamed to raise_type_error

 ?php
 declare(raise_type_error = 1);
 function foo(int $a) {
 // no function call here
 }
 ?
 The declare here does just nothing.

 ?php
 require lib.php;
 foo(123); // will work
 ?

 ?php
 declare(raise_type_error = 1);
 require lib.php;
 foo(123); // will give an error
 ?

 Is everyone feel OK with this??

 There are other things I would like to mention, but this would be enough
 to change decision hopefully.

 Regards,

 P.S. If we are going to introduce strict types for basic types, what we
 really need is type affinity for inputs. e.g. $_GET/$_POST/$_COOKIE.
 https://www.sqlite.org/datatype3.html

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net

Hello,

this would make more sense than strict types, which is a bad name
anyways (as I already mentioned in some other email) - because the
concept of non-week typing is usually called strongly typed in any
other language I can think of. Does PHP have to be a special
snowflake?

Regards
Pavel Kouril

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

Re: [PHP-DEV] About declare(strict_types = 1)

[Pavel Kouřil]

 This RFC will have serious consequence. We made mistake with
 safe_mode. The main reason it failed is it did not force caller to
 have responsibility to make it work as it should. This RFC does the
 same for how declare(strict_types=1) works.

 Aren't we learned from safe_mode lessons?

 I am not sure why you mention safe_mode as this has absolutely nothing
 to do with scalar type hints. Not feature wise, not implementation wise.

 safe_mode, first of all, was a global INI setting. The developer
 couldn't turn it off easily. That was probably at least 80% of the pain.
 The second part was the name, as it indicated that it made your scripts
 safe: It didn't.

 STHv5 does not suffer from either issue — developers can pick and choose
 the best solution for *them* (give them some credit, most developers are
 actually smart!). Library authors always get the right type if they type
 hint, which is *their* main pain point. And the type names have always
 already been used for casts anyway, and don't include safe in their
 name.

 cheers,

Hello,

it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the intent is the same - a switch changing how code
behaves.

When I talked about the Dual Mode with some friends who are userland
PHP devs (either current or former, because they switched to other
stuff), none of them called the Dual Mode a great idea. The responses
I got were mostly along the lines of wow, this seems really weird to
WTF are those developers smoking. Everyone of them (sure, ~10 people
isn't really representative number) said that they think PHP needs
STH, but not this Dual Mode stuff.

Seriously, think about it for a while - when some setting that changes
how code behaves was a good idea?

(IMHO never.)

Regards
Pavel Kouril

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

Re: [PHP-DEV] About declare(strict_types = 1)

[Pavel Kouřil]

On Mon, Mar 16, 2015 at 1:04 PM, Dan Ackroyd dan...@basereality.com wrote:
 On 16 March 2015 at 11:49, Pavel Kouřil pajou...@gmail.com wrote:


 Seriously, think about it for a while - when some setting that changes
 how code behaves was a good idea?


 The problem is that there are two irreconcilable camps - some people
 want weak STHs, other people want strict STHs.

 This RFC gives both camps what they want, at the cost of having the dual mode.

 I personally would prefer a single mode, with strict STHs but I can
 see that would piss off the other camp. And so to me, this RFC even
 with the ickiness of the setting, is an an acceptable cost to giving
 both sides what they want. Oh, and people who don't want to use scalar
 type hints at all, can still continue to not use scalar type hints,
 and their code will continue to keep working.

 Anyone who is voting no, isn't doing so because they are missing out
 on a feature, they're doing it to block other people from getting what
 they want in PHP, which is just a terrible way to vote.

 And if the strict camp are wrong and strict scalars are just not used
 by a large proportion of the PHP community, it would be trivial to
 remove support for the strict mode in a future version of PHP, as all
 code that runs in strict mode, will automatically work in weak mode.

 cheers
 Dan

I can't speak for anyone who voted, but personally, if I could vote, I
would voted no - not because I don't want to block people from
getting what they want, but because I sincerely think that having ANY
setting that changes code's behavior is bad in the long run (and that
removing the feature might not be really easy, once people realize
that the feature is really bad, as people realized with safe_mode and
register_globals after few years).

I work on multiple projects for multiple clients - some have great
code base, some have a bad one. Different typing contexts in different
projects isn't going to help anything at all - it will only bring a
mental overhead.

It's really a shame the other way around wasn't put to vote - to add
weak types, and if there's still enough momentum for strict* types,
add them with the Dual Mode (although I would love to see PHP without
Dual Mode completly).

*) I also hate the name strict types, because this behavior is
called strongly typed in every other language I stumbled upon; why
does PHP have to be a special snowflake? But it's just an aesthetic
thing, so it doesn't matter THAT much.

PS: Also, I personally don't have a preference between strict or weak
typing. I wished from the first moment the Dual Mode was RFC'd that
just ONE ruleset would be chosen, and people would adapt to it. (Given
the weak nature of PHP, the weak types probably fit more, but I
personally could lived with either of those - just not at the same
time.)

Regards
Pavel Kouril

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

Re: [PHP-DEV] About declare(strict_types = 1)

[Pavel Kouřil]

On Mon, Mar 16, 2015 at 11:04 PM, Pierre Joye pierre@gmail.com wrote:

 On Mar 16, 2015 11:16 PM, Pavel Kouřil pajou...@gmail.com wrote:

 I can't speak for anyone who voted, but personally, if I could vote, I
 would voted no - not because I don't want to block people from
 getting what they want, but because I sincerely think that having ANY
 setting that changes code's behavior is bad in the long run (and that
 removing the feature might not be really easy, once people realize
 that the feature is really bad, as people realized with safe_mode and
 register_globals after few years).

 I work on multiple projects for multiple clients - some have great
 code base, some have a bad one. Different typing contexts in different
 projects isn't going to help anything at all - it will only bring a
 mental overhead.

 So you would have voted no on namespaces?

You will probably have to try to explain the similiarity between a
setting that conceptually changes how language works and namespace. I
guess Derick wanted to do so, but his example doesn't make sense and I
didn't understand it, tbh.

Regards
Pavel Kouril

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

Re: [PHP-DEV] About declare(strict_types = 1)

[Pavel Kouřil]

On Monday, March 16, 2015, Derick Rethans der...@php.net wrote:
 On Mon, 16 Mar 2015, Jordi Boggiano wrote:

 On 16/03/2015 11:49, Pavel Kouřil wrote:
  it's similiar to the safe_mode though. Sure, it's not as bad as INI
  setting, but the intent is the same - a switch changing how code
  behaves.

 ini_set('memory_limit', 10); also changes how your code behave

 And so does namespace Foo; use Foo/DateTime as DateTime; - on exactly
 the same level as declare...

 cheers,
 Derick



Hello,

sorry, but your comparison doesn't make ANY sense whatsoever.

Regards
Pavel Kouril

Re: [PHP-DEV] Re: A plea for unity on scalar types

[Pavel Kouřil]

On Fri, Mar 13, 2015 at 8:51 PM, Scott Arciszewski sc...@arciszewski.me wrote:
  Pavel_Kouřil wrote:

 - It is a setting that changes the language's behavior; I don't
 think that it matters whether or not it would be an INI setting or the
 declare() one, because both of them are bad.

 It allows people who want strict typing to declare it on a per-PHP-file
 basis. An INI setting cannot offer this guarantee. This is required if weak
 and strict are to be both supported.

 - It does not unite different usages of PHP into a single group; it
 does exactly the opposite, splitting PHP usage into TWO groups.

 It also allows the two groups to work together rather than forking PHP
 into separate languages: PHPstrict and PHPweak.

 - Once this dual mode would be introduced to PHP, there would probably
 be no way of removing it later without massive BC break, once most
 people would realize that it is really awful to have it in the
 language.

 What is really awful about this? Moving forward, everything could move
 towards strict typing. I could see PHP 8 or 9 having strict be the default,
 if everyone wanted that. And then the declare() being deprecated and
 removed as major versions increase.

 Scott

Hello,

I'm sorry, I totally overlooked your email, so I'm replying with a little delay.

Sure, per-file is better than ini setting, but better doesn't mean
good (because it is still a pretty bad approach). The ini setting at
least has the option to be turned off in code once everyone realizes
it was a bad idea (register_globals via htaccess, for instance), but
PHP would be stuck with the declare for a long time - this is not an
easily revertable change, once PHP ships with it.

The two groups (people who want strong typing and weak typing) will
not work *together* though. And it will be a nightmare for everyone
working on multiple projects from mulitple clients or so.

PHP will IMHO never be strongly-typed by default. It would break BC so
much it's not just possible. The best approach to have some reasonable
type rules is to progressively strenghten the rules (as Zeev's RFC
tried to do so, but he probably did two steps in one RFC and that's
what people dislike about it?). I think that PHP's type system would
get to some equilibrium by this - people wanting stronger typing
would tried to introduce it and people wanting weaker one would
balance it and eventually there could be a point on which both sides
could agree on.

I sincerely hope the Dual Mode RFC doesn't pass. I can't imagine the
RFC being good for the userland developers in the long run.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC][PRE-VOTE] Reserving More Types in PHP 7

[Pavel Kouřil]

On Sat, Mar 14, 2015 at 12:38 PM, Bob Weinand bobw...@hotmail.com wrote:
 Am 14.03.2015 um 10:21 schrieb Pavel Kouřil pajou...@gmail.com:

 On Saturday, March 14, 2015, Levi Morrison le...@php.net wrote:
 RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7

 The proposal has changed from the original. It no longer reserves the
 aliases out of the interest of reserving the smallest useful,
 uncontroversial subset. Some people want to remove aliases for these
 types so in the interest of being as uncontroversial as possible I am
 no longer proposing to remove them.

 This will go into voting on March 15th unless something comes up
 between now and then to persuade me otherwise.

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



 Hello,

 why do you consider a true and false as a type? It's not a type. it's a
 value?

 Regards
 Pavel Kouril

 These aren't types. But useful for e.g. union types (int|false). [By the way 
 they're internally handled as different types… but that's an implementation 
 detail…]

 Also, he doesn't call them anywhere types, it's just the title.

 Bob

Hello,

a union type would be an union of types - so it should be int|bool,
shouldn't it? (Also, I don't personally like the idea of union types
in general, but it's not relevant to the current RFC, so I won't
comment more on that issue.)

Still, maybe the title of the RFC should change to Reserve More
Keywords in PHP 7, so it's not misleading?

PS: Thanks for the info about internal stuff, didn't know about that. :)

Regards
Pavel Kouril

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

Re: [PHP-DEV] Re: A plea for unity on scalar types

[Pavel Kouřil]

On Sun, Mar 15, 2015 at 9:56 AM, Leigh lei...@gmail.com wrote:

 On 15 March 2015 at 08:42, Pavel Kouřil pajou...@gmail.com wrote:

 Sure, per-file is better than ini setting, but better doesn't mean
 good (because it is still a pretty bad approach). The ini setting at
 least has the option to be turned off in code once everyone realizes
 it was a bad idea (register_globals via htaccess, for instance), but
 PHP would be stuck with the declare for a long time - this is not an
 easily revertable change, once PHP ships with it.


 The declaration is turned on with code. This is no different to changing an
 ini setting with code, except that it can't be configured globally in
 advance.

 Existing code is unaffected. I'm not sure where your not easily revertible
 argument is grounded. It's incredibly easy to add/remove declarations at the
 top of a file.


So - are you saying that it would be easy to remove this feature from
the language once people would realize it's register_globals (and any
other settings that change how code behaves) all over again?

 The two groups (people who want strong typing and weak typing) will
 not work *together* though. And it will be a nightmare for everyone
 working on multiple projects from mulitple clients or so.


 Pure FUD. Sorry but there is no evidence to back this up.


Well, how can there be evidence when the feature isn't released yet?
But if you read through the discussions about the Dual Mode RFCs,
you'll see that I'm definitely not the only userland developer with
this opinion.

Also, I can't think of any other language (apart from JS) which has
some settings that change how the code behaves. I'd guess most
languages don't do this for good reasons, but who knows, can't say for
sure.



 The best approach to have some reasonable
 type rules is to progressively strenghten the rules (as Zeev's RFC
 tried to do so, but he probably did two steps in one RFC and that's
 what people dislike about it?).


 You think the best approach is to progressively and continually break
 working code between versions? How is this approach acceptable ever?


This of course doesn't mean breaking existing code in every version. I
doubt there would be more than 2 or 3 changes to the conversion rules
in foreseeable future with this approach. But I do agree that this
isn't ideal way to do things, but I'd say it's the right one.


 I think that PHP's type system would
 get to some equilibrium by this - people wanting stronger typing
 would tried to introduce it and people wanting weaker one would
 balance it and eventually there could be a point on which both sides
 could agree on.


 No, they would never reach agreement.


Pure FUD. Sorry but there is no evidence to back this up. 

(Sorry, I had to - I really do believe that some consensus would be
reached after a while, though.)

 I sincerely hope the Dual Mode RFC doesn't pass. I can't imagine the
 RFC being good for the userland developers in the long run.


 Apologies again, but I think you don't really understand what is being
 proposed in this RFC. Proponents of strict typing get exactly what they
 want, they can develop their library or entire project in strict mode if
 they want, and if someone wants to use this project or library, but
 themselves want to use weak mode, _nothing breaks_.


Why does everyone reply to the disagreeing opinions with I think you
don't understand the RFC? I've seen this happen multiple times in the
discussions with Dual Mode RFC, even when the person understood the
RFC. I am 100% aware that the caller decides the rules, not the callee
and that there's supposed to be interoperability - and yet, I still
strongly disagree with it, mostly because it makes managing multiple
projects (each working with different mode) harder.

I would generally love to have type hints in PHP 7.0 (with any
reasonable ruleset, be it strongly typed, weakly typed or some middle
ground, I don't care as long as it's only *one* ruleset), but I would
rather have none than the Dual Mode one.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Exceptions in the engine

[Pavel Kouřil]

On Sun, Mar 15, 2015 at 8:27 AM, Sebastian Bergmann sebast...@php.net wrote:
 Am 15.03.2015 um 08:07 schrieb Sebastian Bergmann:
  So who will draft the RFC for

* Introduce a Throwable interface
* Let Exception implement the Throwable interface
* Introduce an Error class that implements the Throwable interface
* Use Error class as base class for exceptions raised by the engine

  ?

  It was my idea, after all, only fair that I invest the time to make
  it into an RFC: https://wiki.php.net/rfc/throwable

  Please let me know if there is anything missing.

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



Hello,

why global namespace? Why not just starting using namespaces for PHP
stuff? The global namespace gets more and more polluted by this IMHO.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] Basic Scalar Types

[Pavel Kouřil]

On Sun, Mar 15, 2015 at 6:48 PM, Anthony Ferrara ircmax...@gmail.com wrote:
 Zeev,

 Zeev, allow me to understand how this goes. Bob's discussions on the RFC
 started 2 days ago. Based on the current rules, the RFC can only go to
 vote
 after 2 weeks. That means in 12 days starting now.

 So we are either violating the RFC rules by pushing the vote tomorrow or
 we're delaying PHP7 for another 2 weeks maybe yet another TH RFC passes?

 Bob's RFC is effectively Andrea's v0.1 RFC which was discussed in detail and
 introduced well over two weeks ago.
 I hope we're not going to go into more and more extremes of playing a law
 firm and not an OS project.

 We have minimum discussion periods for a reason. To allow people the
 time to review proposals as much as to discuss them.

 On the surface, yes, this looks like Andrea's 0.1 RFC. However, after
 looking at it, it's definitely different. There's a very significant
 behavior difference between the two:

 Andrea's RFC had the following wording:

 The only exception to this is the handling of NULL: in order to be 
 consistent with our existing type hints for classes, callables and arrays, 
 NULL is not accepted by default, unless the parameter is explicitly given a 
 default value of NULL. This would work well with the draft Declaring 
 Nullable Types RFC.

 This proposal has a different behavior here. It explicitly allows
 nulls for types:

 function foo(int $abc) { var_dump($abc); }

 Unlike my proposal and any of Andrea's, calling foo(null) will be
 int(0) instead of an error.

 This is an important distinction as it basically undermines any
 attempt at a nullable RFC, since it makes primitives implicitly
 nullable.

 So it's not effectively the original proposal. It does differ in a
 very significant detail. This is why we have mandatory discussion
 periods. Not for playing law firm but for being fair to each other.

 Anthony.

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


Hello,

good catch. Nullable RFC would IMHO help PHP, and underminding it isn't good.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types

[Pavel Kouřil]

On Sun, Mar 15, 2015 at 5:55 PM, Zeev Suraski z...@zend.com wrote:
 Bob,

 Thanks for the update.  This time, though, although I completely respect
 your decision not to put your RFC into a vote unless the Dual STH mode
 fails, I'd like to either (with your permission) take over the RFC or
 propose my own copy and move it to voting as soon as allowed.  This, under
 a commitment that if I see that Basic STH is failing to garner a clear
 majority, I'll retract it and move to support the Dual STH RFC instead for
 the sake of unity.

 Why am I making this admittedly big move?  I think that waiting until we
 know for certain whether the Dual Mode STH would win is very problematic,
 for two reasons.

 The bigger one that it runs a serious risk we have no STH at all for 7.0.
 It's not an unlikely scenario either - it's probably 50/50% that the Dual
 STH RFC would fail, only to find later - when it's too late - that Strict
 campers have enough votes to block the Basic one.  Personally, I find that
 the worst possible outcome, given how clearly it is that the users at
 large want *something*.  If the Basic RFC is put to a vote but retracted
 if  when we see it stands no chance to pass - combined with my commitment
 to support the Dual STH in such a case (and my belief that move will be
 able to influence others as well), the chances that we'd be left with no
 STH at all for 7.0 goes down significantly.

 There's also a secondary reason - I do think it's unfair that in a very
 likely scenario - we won't be giving people who prefer Basic STH only - at
 least at this point - a chance to vote at the proposal they think is best.
 I don't think it's a matter of voting for who's going to win;  In fact
 with a commitment to retract it if it fails to win, it's not about that at
 all.  It's being able to vote for what you truly believe in, as opposed to
 a compromise that you find bad but better than nothing.  And in my case
 (and perhaps others) - it's about being willing to vote for something I
 actually don't believe it at all for the sake of unity, but only once the
 alternative options have been explored.

 Before Dual STH supporters dissect my move to pieces, please realize this:
 If you're right - that Basic STH stands no chance to gain 2/3 majority -
 you have absolutely NOTHING to lose, and in fact, you're increasing your
 chances of passing that vote through from apparently 50/50 to 80/20 (not
 talking about votes, but chances), and as a bonus, you get to prove your
 point.
 If you're wrong - and Basic STH is more popular than Dual STH (at this
 point in time) - we would have given the community at large something
 that's closer to what it really wants.

 Zeev



 -Original Message-
 From: Bob Weinand [mailto:bobw...@hotmail.com]
 Sent: Sunday, March 15, 2015 5:51 PM
 To: PHP Internals
 Subject: [PHP-DEV] [RFC] [INFO] Basic Scalar Types

 Hey, to clarify what the way to go with this RFC is.

 This RFC is a FALLBACK. It's about the common part of both other RFCs.
 That way it *only* will go to vote after Anthonys RFC ends. And *only*
 if it
 fails.

 That means, I will go by the voting RFC and wait until discussion period
 ends
 and put it to vote after Anthony closes his RFC in case it fails.

 I'm aware that a few people have said, they will change their vote
 depending
 on what ever might pass. And that they asked for this RFC going into
 direct
 competition against Anthonys RFC. No. Know what you want. If you dislike
 Anthonys RFC, vote no on it. If you like it, vote yes on it. But don't
 switch
 your votes back and forth depending on what might win.
 That's why I decided to not have the vote on this running concurrently
 with
 Anthonys.

 But, in any case this RFC will go to vote on the 24th if Anthonys RFC
 couldn't
 gather a 2/3 supermajority.

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

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


Hello,

I like your idea, but there's a problem with this (apart from the
thing that it's not supposed to be in vote for 7.0 if you go by the
rules, based on opinion of some people here).

You are saying we would have given the community at large something
that's closer to what it really wants, but the people maintaining PHP
vote on that, not the community and userland developers (and that's a
problem with most of the features here, that the direction in which
PHP evolves is basically chosen by C programmers*).

*) Don't take it too literally or offensively please, but I hope
you'll get what I mean. :)

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types

[Pavel Kouřil]

On Sun, Mar 15, 2015 at 10:11 PM, Philip Sturgeon pjsturg...@gmail.com wrote:

 I am sorry for hurting your feelings but you are being manipulative
 and I am not a fan of that. I have no agenda, I just want to see you
 put an end to this weird rule bending, definition changing, rule
 ignoring convenient interpretations of policies that stop Dual STH
 going through by any means possible.

 Are there some special rules for a backup
 plan anywhere in the Voting RFC or the Timeline RFC that I missed?

 Yeah Bob specifically said it would go to vote if Dual STH failed, so
 that makes it a backup plan. :)

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


Hello,

if Zeev didn't want to make Dual STH go through by any means possible,
he could have just retracted his RFC few hours ago when the Dual STH
wasn't passing, effectively ending both RFCs as not passing, given I
understand the voting process correctly. (Sure, it would be a textbook
example of a so-called dick move, but that's not the point.)

If you realize this (in combination with the statement that if
everything else fails, he'll go with the Dual one, even if he
disagrees with it, so the end users at least have SOME type hints in
PHP 7.0), then you'll probably see all the attempts to bring another
competing RFC as an honest attempt at making the language better by
bringing another look on STHs to vote on, and not as pushing some
agenda.

Or at least that's my point of view.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC][PRE-VOTE] Reserving More Types in PHP 7

[Pavel Kouřil]

On Saturday, March 14, 2015, Levi Morrison le...@php.net wrote:
 RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7

 The proposal has changed from the original. It no longer reserves the
 aliases out of the interest of reserving the smallest useful,
 uncontroversial subset. Some people want to remove aliases for these
 types so in the interest of being as uncontroversial as possible I am
 no longer proposing to remove them.

 This will go into voting on March 15th unless something comes up
 between now and then to persuade me otherwise.

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



Hello,

why do you consider a true and false as a type? It's not a type. it's a
value?

Regards
Pavel Kouril

Re: [PHP-DEV] A plea for unity on scalar types

[Pavel Kouřil]

On Fri, Mar 13, 2015 at 10:01 PM, Philip Sturgeon pjsturg...@gmail.com wrote:
 Pavel,

 On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajou...@gmail.com wrote:
 On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com wrote:

 But for today, I firmly believe that the Dual-Mode proposal is the
 only one that stands a chance of passing. I think it's the best chance
 for the language, and it's the only one that tries to unite the
 different usages of PHP into a single group, rather than alienating
 users.


 Hello,

 I see (as a userland developer) these problems with dual mode:
 - It is a setting that changes the language's behavior; I don't
 think that it matters whether or not it would be an INI setting or the
 declare() one, because both of them are bad.
 - It does not unite different usages of PHP into a single group; it
 does exactly the opposite, splitting PHP usage into TWO groups.
 - Once this dual mode would be introduced to PHP, there would probably
 be no way of removing it later without massive BC break, once most
 people would realize that it is really awful to have it in the
 language.

 (There's probably more of them, but these are the biggest issues I
 currently have.)

 Regards
 Pavel Kouril

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


 Hang on. This is not the time to nitpick things in various RFCs that
 have already been answered time and time again.

 An ini setting would be insane because taking an app that works on one
 machine and putting it on another would completely break the app.
 Hello anything using Composer, hello any CMS, hello any system moving
 to a new host that doesn't let you change ini settings, or you dont
 know how.

 A declare statement in the top of the file changing how that file
 handles things is hardly a problem, and is exactly how a lot of other
 languages do things. Hello JavaScript.

 It seems like you didn't read anything now you're just saying it's
 bad a lot. Please don't do that.


Hello,

there may maybe be some misinterpretation of what I'm saying, but I
read everything from the scalar types discussions in the past 2 or 3
months, actually.

I know ini setting is much much worse than this, but this is imho
still bad - the intent is pretty much similiar (aka some directive
that changes how code behaves); I've been saying that I disagree with
this approach ever since the Andrea's first Dual Mode was published as
a RFC and I feel I need to bring it up again.

Regards
Pavel Kouril

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

Re: [PHP-DEV] A plea for unity on scalar types

[Pavel Kouřil]

On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com wrote:

 But for today, I firmly believe that the Dual-Mode proposal is the
 only one that stands a chance of passing. I think it's the best chance
 for the language, and it's the only one that tries to unite the
 different usages of PHP into a single group, rather than alienating
 users.


Hello,

I see (as a userland developer) these problems with dual mode:
- It is a setting that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or the
declare() one, because both of them are bad.
- It does not unite different usages of PHP into a single group; it
does exactly the opposite, splitting PHP usage into TWO groups.
- Once this dual mode would be introduced to PHP, there would probably
be no way of removing it later without massive BC break, once most
people would realize that it is really awful to have it in the
language.

(There's probably more of them, but these are the biggest issues I
currently have.)

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] Basic Scalar Types

[Pavel Kouřil]

 It shouldn't prevent any future improvements and still give use all the
 advantages of scalar types.

 Besides what I think of proposing yet another RFC, -1 because it is
 basically what the initial idea from the opponents of optional strict mode
 wanted before they go with the latest one. It also totally ignore what the
 Anthony's proposes.


Hello,

I'd say that this is definitely better than the dual mode RFC, but
worse than the coercive one - I can't find a single reason why some
modes switch should be good. I can only see negative outcomes from
this, and a painful experience when developing with PHP in the long
run as a userland developer.

Basically goes with what I've been saying from the beggining of the
introduction of the dual mode - I don't care if strong or weak
typing wins, but I want only on in the language. PHP is inconsistent,
there's no need to make even more inconsistencies and stuff.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] Basic Scalar Types

[Pavel Kouřil]

On Wednesday, March 11, 2015, Bob Weinand bobw...@hotmail.com wrote:
 Am 11.03.2015 um 23:29 schrieb Pavel Kouřil pajou...@gmail.com:

 It shouldn't prevent any future improvements and still give use all the
 advantages of scalar types.

 Besides what I think of proposing yet another RFC, -1 because it is
 basically what the initial idea from the opponents of optional strict
mode
 wanted before they go with the latest one. It also totally ignore what
the
 Anthony's proposes.


 Hello,

 I'd say that this is definitely better than the dual mode RFC, but
 worse than the coercive one - I can't find a single reason why some
 modes switch should be good. I can only see negative outcomes from
 this, and a painful experience when developing with PHP in the long
 run as a userland developer.

 Basically goes with what I've been saying from the beggining of the
 introduction of the dual mode - I don't care if strong or weak
 typing wins, but I want only on in the language. PHP is inconsistent,
 there's no need to make even more inconsistencies and stuff.

 Regards
 Pavel Kouril

 It's not worse than the coercive one. It's just doing less. It doesn't
change ZPP.
 We always still can change ZPP later in future.

 If you like the coercive one, you also should like this one.

 Bob

Yeah, I like this one - but I slightly prefer the coercive one. I feel like
this one is just too weak (yes, because it doesn't change the ZPP), but it
is still better than no hints at all - and infinitely better than
introducing two modes.

Hopefully you understand my POV now. :)

Regards
Pavel Kouřil

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

[Pavel Kouřil]

On Fri, Feb 20, 2015 at 8:01 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi all,

 On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez ric...@gmail.com wrote:

 I think that naming the new parent exception something like Throwable or
 Catchable (as Nikita previously suggested) would be a bit more concise in
 meaning than BaseException. You may not have even meant that name as a
 formal proposal, but I figured I'd weigh in regardless. :P


 I think they probably should use namespace...

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net

Hello,

yes, finally introducing namespaces into PHP core stuff would
definitely be beneficial. Polluting the global namespace more and more
should be avoided.

I would gladly see something like this:
Php\Throwable
- Php\Exception
- Php\ParseException
- Php\EngineException

Of course, the \Exception would need to be kept (maybe as an alias to
\Php\Exception?), for backwards compability.

Regards
Pavel Kouril

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

Re: [PHP-DEV] The Game Theory of Scalar Type Hint Voting

[Pavel Kouřil]

On Wed, Feb 25, 2015 at 10:09 AM, Zeev Suraski z...@zend.com wrote:
 -Original Message From: Leigh [mailto:lei...@gmail.com]
 Sent: Tuesday, February 24, 2015 2:56 PM
 To: Albert Casademont Filella
 Cc: Benjamin Eberlei; PHP Internals
 Subject: Re: [PHP-DEV] The Game Theory of Scalar Type Hint Voting

 On 23 February 2015 at 21:15, Albert Casademont Filella
 albertcasadem...@gmail.com wrote:
  I like it! That's what I proposed to Anthony (and Andrea before)
  before Zeev presented their alternative, to held a double vote on the
  strict vs weak feature. It was not met with much enthusiasm, hope they
  change their minds with your proposal!

 Except a dual vote is probably not going to work in favour of strict vs.
 weak.

 Why would anyone who wants purely strict vote for Yes (strict), when
 they
 know that Yes (weak) is going to have the majority. It boils down to
 voting
 Yes for something you don't want. I don't think it will convert votes at
 all.
 _If_ I wanted _strict only_ and I was presented with Yes (strict), Yes
 (weak), and No and could see the weak vote winning by a clear margin, I
 would vote No.

 Leigh,

 There isn't a weak-only proposal on the table.  There's the original one
 (dual mode) and the coercive one.  Both have both strict and dynamic
 elements in them.
 I think that what Anthony proposed about a week or so ago, of having both
 votes, and if both pass 2/3 - have another vote to choose between them
 (where a simple majority wins) - makes the most sense in this uncharted
 territory.
 I think that opening the votes at the same time is probably a good idea.

 Zeev

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



Well, one thing that would help apart from opening them at the same
time is also making the results not public until the voting ends (but
I'm not sure if this isn't prohibited by the RFC voting process
guidelines).

Regards
Pavel Kouril

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

Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

[Pavel Kouřil]

On Tue, Feb 24, 2015 at 8:48 AM, Alexander Lisachenko
lisachenko...@gmail.com wrote:
 Morning!

 I want to ask this question one more time before PHP7 feature freeze: can
 we  the engine case sensitive from PHP=7.0?

 There is a draft for that: https://wiki.php.net/rfc/case-sensitivity
 (mostly empty), so I decided to ask this question in the internals mail
 list.

 Pros: more simple O(1) hash table checks for properties, functions,
 methods, classes without strtolower normalization on the engine/parser
 level. Consistency with unicode class names (yes, they are case sensitive,
 check http://3v4l.org/ia0pc), consistency with exisiting PSR0,4 standards
 (case sensitive mapping of class names to the file names)

 From my experience, all modern PHP framework don't use case-insensitive
 code, so chance to break anything for them is really low.

 Cons: on the extension level things aren't so good and can be some BC
 breaks (like with phpng)

 Possible ways:

 1) Keep PHP engine case-insensitive for PHP7
 2) Make PHP engine case-sensitive since PHP7 with possible minor BC breaks
 in the extensions (this breaks can be easily fixed)
 3) Add a compile-time switch, eg. --with-case-sensitivity to the
 configuration to have an ability to build PHP with sensitivity and make
 this option enabled by default since next major version (PHP=8.0). Add
 deprecation notices in 7.x

 Thoughts?

Hello,

I'd personally LOVE PHP being case-sensitive, but I think it's not possible.

Sure, frameworks and newer code will won't be broken, but what about
the tons of legacy code? Personally, I saw too much code (and even
examples in tutorials!) using stuff like MySQL_Query(). And case
sensitivity would break this code without a doubt. (I know mysql ext
is deprecated, but that's relevant right now, this is just one of many
examples - the most common one I can think of, actually).

On the other hand, this could be fixed by running some migration
scripts over code base, so maybe it's not THAT bad? Who knows.

Regards
Pavel Kouril

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

Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

[Pavel Kouřil]

On Mon, Feb 23, 2015 at 10:28 AM, Joe Watkins pthre...@pthreads.org wrote:
 Zeev,

  If you can infer the type with confidence, you can do away with coercion
 code altogether.

 Maybe I'm ignorant of something, but isn't the only way you can begin to
 infer the type with real confidence is by having strict typed parameters ?

 This sounds like the kind of strict mode we're talking about, where no
 coercion is necessary because inference is so reliable given a good
 starting place (function entry with strictly typed parameters).

  If you can't, then you're not obligated to generate optimized paths for
 every possible input - you can just defer to the relevant coerce() function.

 If the parameters aren't strict but are typed then you need to travel
 coercion code paths somewhere, optimized inline, calling an API function,
 it makes no real difference.

 I guess we are hedging our bets that having to travel those paths will suck
 away so much performance, that it will make all of the effort required to
 make any of this a reality seem, somehow ... wasted.

 JIT might end up being about making PHP viable for more CPU-bound use
 cases ...

 This is probably quite realistic.

 In case anyone is reading and thinks I'm using any of this to justify dual
 mode, I'm not doing that. The original RFC justified it well enough, I just
 happen to disagree with some of the assertions made in this thread and or
 RFC.


Hello,

if I understand the issue correctly, not even strongly typed
parameters won't help you infer types of variables with real
confidence?

Imagine this piece of code:
function foo(int $x) { $x = fnThatReturnsRandomScalarType(); return $x; }

Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Exceptions in the engine

[Pavel Kouřil]

On Tue, Feb 24, 2015 at 12:03 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi Nikita,

 On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov nikita@gmail.com wrote:

 Voting on the engine exceptions RFC, which proposes to convert existing
 fatal and recoverable fatal errors into exceptions, has opened:

 https://wiki.php.net/rfc/engine_exceptions_for_php7#vote

 The primary vote requires a 2/3 majority, as this is a language change.

 A second vote will decide whether to use a BaseException based inheritance
 hierarchy. This vote uses a simple majority.


 Although, AbstractException sounds better to me. I voted yes for it now.

 We probably need more specific coding standard for class/interface names
 for internal
 classes/interfaces.

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net

Hello,

I personally find both BaseException and AbstractException ugly. The
Throwable is IMHO much better.

Regards
Pavel Kouril

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

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

[Pavel Kouřil]

On Sun, Feb 22, 2015 at 2:09 PM, Robert Stoll p...@tutteli.ch wrote:

 I see the migration plan roughly as follows:

 PHP 7.0:
   - reserve keywords: bool, int, float including alternatives
   - deprecate alternative type names such as boolean, integer etc.

   - introduce new conversion functions which reflect the current behaviour of 
 (bool), (int) etc.
   -- as mentioned above, they could be named oldSchoolBoolConversion etc.
   -- Encourage users to use this function instead of (bool), (int) etc 
 since (bool) etc. will change with PHP 8.0. Also mention, that this function 
 should only be used if the weakness is really required otherwise use the new 
 conversion functions from below

   - introduce new conversion functions which reflect the new defined 
 conversion rule set (which shall be the only one encouraged in the future) 
 Those functions shall trigger an E_RECOVERABLE_ERROR
 -- encourage users to use this functions instead of (bool), (int) and 
 oldSchoolBoolConversion etc.  (unless the weakness is really required, then 
 use oldSchoolBoolConversion)

   - update the docs in order to reflect the new encouraged way. Also mention 
 that:
  - (bool), (int) etc. will change their behaviour in PHP 8.0
  - internal functions will use the new conversion rules if not already 
 done this way in PHP 8.0 (for instance, strstr will no longer accept a scalar 
 as third parameter in the case where we do not support implicit casts to bool)
  - operators will use the new conversion rules if not already done this 
 way in PHP 8.0
  - (control structures will use the new conversion rules if not already 
 done this way in PHP 8.0) =Maybe this is too strict for most of you and goes 
 against the spirit of PHP (I suppose some of you will say that - fair enough, 
 I guess you are right). In this case, I would at least use the term loose 
 comparison as mentioned here: 
 http://php.net/manual/en/types.comparisons.php#types.comparisions-loose 
 instead of using the term conversion, then it is compatible with the 
 changes introduced in PHP 8.0

 PHP 7.1: necessary bug-fixes introduced with PHP 7.0
 PHP 7.x: deprecate even more if required
 PHP 8:
   - introduce scalar type hints which reflect the conversion rules as defined 
 (adding strict type hints as well is possible of course, whether with an 
 ini-setting, a declare statement or individually with a modifier something 
 like strict int for a single parameter or strict function for all 
 parameters incl. return type or strict class for every type defined in the 
 class is up to discussion)
   - exchange the behaviour of (bool), (int) etc. - use the new conversion 
 rules instead
   - change internal functions which do not yet obey to the new conversion 
 rules
   - change the operators which do not yet obey to the new conversion rules 
 (for instance, + would also emit an E_RECOVERABLE_ERROR for a + 1)
   - (change the control structures in order that they obey the new conversion 
 rules as well) = as mentioned above, probably too strict for PHP

 Back to this RFC.  think this RFC goes in the right direction with the 
 specified conversion rules. Only thing to get rid of are the implicit 
 conversions to bool from string, float and int IMO.
 Moreover, I like that the RFC already has different steps for adding the new 
 behaviour. Yet, I think it should slow down a little bit as shown. I think we 
 need more time to come up with a very good strategic solution.


Hello,

Am I understanding correctly that you are suggesting changes to type
casting? This seems like a bad idea. Explicit and implicit conversions
are something really different. Generally, implicit conversions are OK
only when no data is lost and explicit conversions (casts) are used
when you realize some information can get lost and you still want to
proceed with the conversion. Having only one type of conversion is
IMHO weird.

Also, I'm not a fan of having to wait for scalar type hints for few
more years. :(

Regards
Pavel Kouril

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

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

[Pavel Kouřil]

On Sun, Feb 22, 2015 at 7:30 PM, Robert Stoll p...@tutteli.ch wrote:
 Hi Pavel,

 Yes, I am suggesting to make conversions behave the same regardless if it is 
 implicit or explicit. The only difference between the two should be that one 
 is stated explicitly by the user where the other is applied implicitly. Other 
 programming languages behave like this and are more predictable for users as 
 well as developers because one does not need to learn two sets of conversion 
 rules.


Actually this is not true. Other languages have differences between
explicit conversions (aka casting) and implicit conversions as well.
C# is the language I use the most after PHP, so I'll bring that one up
(see https://msdn.microsoft.com/en-us/library/ms173105.aspx), but I
believe other languages (probably Java?) act the same way.

Regards
Pavel Kouril

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

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

[Pavel Kouřil]

On Sun, Feb 22, 2015 at 9:42 PM, Robert Stoll p...@tutteli.ch wrote:

 Probably it is a philosophical question how to look at it. IMO the only 
 difference in C# (as well as in Java) lies in the way the conversions are 
 applied. Implicit conversions are applied automatically by the compiler where 
 explicit conversions are applied by the user. The difference lies in the fact 
 that C# is statically typed and implicit conversions are only applied when it 
 is certainly safe to apply one. However, Implicit conversions in C# behave 
 the same as explicit conversion since implicit conversion which fail simply 
 do not exist (there is no implicit conversion from double to int for 
 instance). That is the way I look at it. You probably look at it from another 
 point of view and would claim an implicit conversion from double to int in C# 
 exists but just fails all the time = ergo implicit and explicit are 
 different (that is my interpretation of your statement above). In this sense 
 I would agree. But even when you think in this terms then you have to admit, 
 they are fundamentally different in the way that implicit conversion which 
 are different than explicit conversion always fail, in all cases - pretty 
 much as if they do not exist. There are no cases, neither in C# nor in Java 
 which I am aware of, where an implicit cast succeeds in certain cases but not 
 in all and an explicit conversion succeeds in at least more cases than the 
 implicit conversion. Hence, something like a should also not work in an 
 explicit conversion in PHP IMO if it is not supported by the implicit 
 conversion (otherwise strict mode is useless btw.)

 Try out the following C# code:
 dynamic d1 = 1.0;
 int d = d1;
 You will get the error Cannot implicitly convert type `double` to `int` at 
 runtime.

 We see a fundamental difference between C# and PHP here. PHP is dynamically 
 typed an relies on values rather than types (in contrast to C#). Therefore, 
 the above code emits a runtime error even though the data could be converted 
 to int without precision loss.
 This shall be different in PHP according to this RFC and I think that is 
 perfectly fine. Yet, even more important it seems to me that 
 implicit/explicit conversions behave the same way.
 At first it might seem strange to have just one conversion rule set in PHP 
 since PHP is not known to be a language which shines due to its consistency...
 OK, I am serious again. If you think about it from the following point of 
 view: A user writes an explicit conversion in order to state explicitly that 
 some value will be converted (this is something which will be necessary in a 
 strict mode). Why should this explicit conversion be different from the 
 implicit one? There should not be any difference between explicit knowledge 
 and implicit one. That is my opinion. If you really do not care about data 
 loss and just want to squeeze a float/string into an int no matter what the 
 value really is then you can use the @ in conjunction with ?? and provide the 
 desired default value to fall back on if the conversion fails. If conversions 
 like a to int really matters that much to the users of PHP then we could 
 keep the oldSchoolIntConversion function (as propose in my first email) even 
 in PHP 10 (I would probably get rid of them at some point).

 Cheers,
 Robert


Well,

I look at it this way (in a simplified manner). Hopefully this will
make you understand my point of view more.

- Implicit conversions work only when you are sure you won't lose stuff
- Explicit conversions are for forcing (casting) variable to become
another type, and when you are explicitely as user calling it, you are
aware you can lose values

Sure, the literal meaning in C# and PHP differs a little bit (because
of static and dynamic typed language differences and stuff), but the
*intent* is IMHO the same; implicit conversions can happen in the
background safely, while for dangerous conversions, you have to
cast by hand. And I see use cases for both of these types of
conversions.

Also, you are assuming that there will be a strict mode; I sincerely
hope there won't. Ssince introduction of 2 modes, I was always
saying that there should be only one mode - I don't really care
whether it would be strict or weak, but just only one.

Regards
Pavel Kouril

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

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

[Pavel Kouřil]

On Sat, Feb 21, 2015 at 11:25 PM, Zeev Suraski z...@zend.com wrote:
 There’s a fundamental difference between the two RFCs that goes beyond
 whether using a global INI setting and the other per-file setting.  The
 fundamental difference is that the endgame of the Dual Mode RFC is having
 two modes – and whatever syntax we’ll add, will be with us forever;  and in
 the Coercive STH RFC – the endgame is a single mode with no INI entries,
 and opening the door to changing the rest of PHP to be consistent with the
 same rule-set as well (implicit casts).   The challenge with the Coercive
 STH RFC is figuring out the best transition strategy, but the endgame is
 superior IMHO.

Hello,

the two modes was something that I didn't like, at all, as a userland
developer. It seems really scary that decision to add 2 modes would
mean that every PHP code could have been written in any of these 2
ways and it would stick forever with PHP, because removing it again if
it proved to be a bad feature would be IMHO really painful.

So a single mode is infinitely better than 2 modes.

Also, personally, I would prefer #1 or #2 version for internal
functions, but definitely without an INI switch. Not being able to
change it on some hostings could make development for the transition
period kinda painful.

Regards
Pavel Kouril

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

Re: [PHP-DEV] Reviving scalar type hints

[Pavel Kouřil]

On Mon, Feb 16, 2015 at 9:50 PM, François Laupretre franc...@php.net wrote:
 De : Pavel Kouril [mailto:pajou...@gmail.com]

 Hello,

 I know this is probably a pretty unpopular opinion in PHP (based on
 the replies I got in the other thread), but different values for
 parameters should be IMHO solved by method overloading and such.

 The question is not that it's unpopular, it's that 1. It requires strict 
 types, and 2. If we want to solve this by polymorphism, we must also support 
 polymorphism on functions. Now, tell me how you would solve the 
 tan(int|float) case with polymorphism ? One 'tan' function for int, one for 
 float ? str_replace(string|array, string|array, string|array, int ) is also 
 a nice case to study if you can't sleep...

 Sorry but polymorphism on scalar types is possible with strict types only, 
 which is out of scope for the next RFC.

 François


Hello,

finally got to this, after a while of thinking - the first part was
answered before, so I'll get only to the str_replace now. :)

Basically, each of the 8 different version based on parameters does
different thing, if I'm counting it correctly. So having 8 different
declarations is IMHO valid. I know it sounds a little bit weird, but
if you really realize the amount of things the function is doing based
on the passed parameters, why would having one declaration with
multiple argument types and if statements deciding what to do based on
an argument types be better than 8 different declarations, where each
one does one predictable thing and can be documented separately? :)


PS: I know there's something like a declined RFC for method
overloading in the wiki (actually, just a 7 years old email), but if
there would be someone who would be interested in having method
overloading in PHP and understands PHP's internals (I don't) so he'd
be able to make the implementation, I'd like to discuss this idea with
him more and contribute somehow to a possible RFC.

Regards
Pavel Kouril

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

Re: [PHP-DEV] Annotations in PHP7

[Pavel Kouřil]

On Wed, Feb 18, 2015 at 9:45 PM, Benjamin Eberlei kont...@beberlei.de wrote:


 On Wed, Feb 18, 2015 at 9:29 PM, Pavel Kouřil pajou...@gmail.com wrote:

 As a Doctrine user, I find this way worse than current state. This
 syntax looks UGLY and contains a lot of useless clutter. And yeah,
 adding named parameters to PHP be pretty helpful to make annotations
 more readable. :(


 This is in no way related, only by the choice of guilherme's syntax. You
 could
 pass an array of options to the constructor to simulate named easily.

Sorry, but I find passing an array with fields instead of proper named
parameters as a hack, not as a solution. :(


 And to what Francois said (Anyway, I don't like the OO features
 people want to add everywhere. They can get strings and inject them to
 OO, but that's not the role of the annotation layer, IMHO. I
 definitely prefer the KISS approach.). What's exactly wrong with
 doing annotations in an object oriented manner? Both Doctrine
 Annotations and C# have them as objects, and it works well. Having
 annotations as just array of expressions/strings/whatever and needing
 another library to parse them is not really that great upgrade from
 current state. :(


 PHP is not primarily an OOP language. As a user of Doctrine you wouldn't
 need to care,
 because we would wrap it anyway in our current code. So it wouldn't matter.


I know you could wrap it in your code, but that would still mean there
would probably be multiple implementations of Annotations in the
wild, instead of a good complete functionality in the language
itself.

I know PHP is not primarily an OOP language, but Annotations IMHO make
sense as classes, so I don't see any reason why would it be bad to
make them in that way. Also, making Annotations be classes won't
magically turn PHP into a primarily OOP language?

Regards
Pavel Kouřil

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

Re: [PHP-DEV] Annotations in PHP7

[Pavel Kouřil]

On Wed, Feb 18, 2015 at 7:28 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
 Hi Dmitry,

 Are you (and Doctrine team) interested in this annotation idea?

 I'd say that Benjamin nailed in our possible usage:

 orm(new Entity(foo))
 class Foo {
 }

 Now I do feel we need to elaborate some sort of named parameters. Doctrine
 tries to simplify a lot developer's life by using consistency in default
 mapping and only if the user wants to override default behavior he needs to
 override a given parameter. This means in a case where you're mapping a
 JoinColumn (
 https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/JoinColumn.php
 ),
 you may only want to specify the onDelete=CASCADE operation instead of
 name, referencedColumnName and many other parameters.
 Trying to map this in your default parameter passing, we'd have something
 like:

 orm(
 [
 new OneToOne(Address),
 new JoinColumn(default, default, default, default, CASCADE)
 ]
 )
 public $address;

 As I said, named parameters make a lot of sense when mapping defaults.
 Now by looking at this syntax, I still think we're closer to a simple array
 implementation (ReflectionClass::getMetadata(string $name)) and having
 something like:

 [
 orm = [
 new OneToOne(Address),
 new JoinColumn(default, default, default, default, CASCADE)
 ]
 ]
 public $address;


 PS: We haven't even started on talking about overrides yet... =\


As a Doctrine user, I find this way worse than current state. This
syntax looks UGLY and contains a lot of useless clutter. And yeah,
adding named parameters to PHP be pretty helpful to make annotations
more readable. :(

And to what Francois said (Anyway, I don't like the OO features
people want to add everywhere. They can get strings and inject them to
OO, but that's not the role of the annotation layer, IMHO. I
definitely prefer the KISS approach.). What's exactly wrong with
doing annotations in an object oriented manner? Both Doctrine
Annotations and C# have them as objects, and it works well. Having
annotations as just array of expressions/strings/whatever and needing
another library to parse them is not really that great upgrade from
current state. :(

Regards
Pavel Kouril

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

Re: [PHP-DEV] Reviving scalar type hints

[Pavel Kouřil]

On Mon, Feb 16, 2015 at 5:42 PM, François Laupretre franc...@php.net wrote:
 Hi,

 - the fact that the RFC supports single types only, like the previous 'return 
 type' RFC. While it is easier to implement, it opens several issues as 
 multiply-typed arguments are an integral part of the PHP language (mostly 
 completeness and compatibility with internal function hinting). If we want to 
 support multiple types the same way for internal and userspace functions, we 
 must extend the ZPP layer to support it.

 - the mechanism to check for type hints on internal functions, while easy to 
 implement, is not sufficient, as a lot of internal functions get a bare zval 
 from the parsing system and then convert it by themselves. With the proposed 
 mechanism, there's no possible hinting on such argument, which will make the 
 implementation different from the documentation. Even if the check is done by 
 the function body, it won't be done in a consistent way with type hinting 
 checks and won't raise a similar error. As most cases are related to 
 multiply-typed args, the solution is in adding multiply-typed support to ZPP. 
 Multiply-typed support needs to redefine scalar conversion rules, to take 
 care of the target type being a combination of single types.


Hello,

I know this is probably a pretty unpopular opinion in PHP (based on
the replies I got in the other thread), but different values for
parameters should be IMHO solved by method overloading and such.

Regards
Pavel Kouril

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

Re: [PHP-DEV] Annotations in PHP7

[Pavel Kouřil]

On Mon, Feb 16, 2015 at 1:33 PM, Benjamin Eberlei kont...@beberlei.de wrote:


 On Mon, Feb 16, 2015 at 1:17 PM, Pavel Kouřil pajou...@gmail.com wrote:

 On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@zend.com wrote:
  hi,
 
  During discussion of different ways of implementing Design by Contract
  we
  got an idea of using annotations.
 
  BTW: annotations are useful by their own and may be used for different
  purposes. Support for annotations was proposed long time ago:
 
  https://wiki.php.net/rfc/annotations
  https://wiki.php.net/rfc/annotations-in-docblock
  https://wiki.php.net/rfc/reflection_doccomment_annotations
 
  HHVM already implemented similar concept
 
  http://docs.hhvm.com/manual/en/hack.attributes.php
 
  I made a quick and dirty PoC that shows how we may implement annotations
  in
  PHP7 and how powerful they may be :
  https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2
 
  The test there is self explainable. Of course, annotations just provide
  a
  way to add metadata, but doesn't define attribute names or the ways they
  are going to be used. Only Reflection API to read.
 
  There are still a lot of technical problems that have to be solved.
  Right now, we just need to answer a question - if we like this in PHP7?
  Thought and opinions are welcome...
 
  Thanks. Dmitry.

 Hello,

 I'd personally suggest you to consider that the Annotations could be
 classes, something along the lines of

 https://msdn.microsoft.com/en-us/library/aa288454%28v=vs.71%29.aspx#vcwlkattributestutorialanchor1

 IMHO it will allow for more usecases and such than simple arrays.


 They are statements, so you can do whatever. Dimitri just showed scalars,
 but it would be possible to do:

 orm(new Entity([repositoryClass = FooRepository]))

 And then getAnnotations returns something along the lines if evaluated by
 the PHP Parser:

 orm = [new Entity(), ]

 So your requirement would be possible.


 Regards
 Pavel Kouril

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



Hello,

while the usage of statements in annotations sound good in theory, I
find the need for using the new and such as ugly. Thefore, I'd
probably still prefer the C# style of doing annotations.

Regards
Pavel Kouril

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

Re: [PHP-DEV] Reviving scalar type hints

[Pavel Kouřil]

On Mon, Feb 16, 2015 at 9:50 PM, François Laupretre franc...@php.net wrote:
 De : Pavel Kouril [mailto:pajou...@gmail.com]

 Hello,

 I know this is probably a pretty unpopular opinion in PHP (based on
 the replies I got in the other thread), but different values for
 parameters should be IMHO solved by method overloading and such.

 The question is not that it's unpopular, it's that 1. It requires strict 
 types, and 2. If we want to solve this by polymorphism, we must also support 
 polymorphism on functions. Now, tell me how you would solve the 
 tan(int|float) case with polymorphism ? One 'tan' function for int, one for 
 float ? str_replace(string|array, string|array, string|array, int ) is also 
 a nice case to study if you can't sleep...

 Sorry but polymorphism on scalar types is possible with strict types only, 
 which is out of scope for the next RFC.

 François


I will get to this more tomorrow, but now just a short notes:

I'd only have tan(float) with int being able to be passed and the
value would be implicitly converted to float. This is something even
strongly typed languages normally do, and there is no reason PHP
shouldn't be able to. If somebody would make a tan(float) and tan(int)
declarations, then when calling tan($x), the apropriate one based on
current type of $x should be called. I don't see any reason why this
can be done only for strongly typed languages; could you name exact
reasons?

The str_replace(string|array $search, string|array $replace,
string|array $subject[, int $count ]) is a harder one to comment on
though. I will refrain from answering on that one right now and will
get back to that one tomorrow, because that one needs a little bit
more thinking.

Regards
Pavel Kouril

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

Re: [PHP-DEV] Annotations in PHP7

[Pavel Kouřil]

On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@zend.com wrote:
 hi,

 During discussion of different ways of implementing Design by Contract we
 got an idea of using annotations.

 BTW: annotations are useful by their own and may be used for different
 purposes. Support for annotations was proposed long time ago:

 https://wiki.php.net/rfc/annotations
 https://wiki.php.net/rfc/annotations-in-docblock
 https://wiki.php.net/rfc/reflection_doccomment_annotations

 HHVM already implemented similar concept

 http://docs.hhvm.com/manual/en/hack.attributes.php

 I made a quick and dirty PoC that shows how we may implement annotations in
 PHP7 and how powerful they may be :
 https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2

 The test there is self explainable. Of course, annotations just provide a
 way to add metadata, but doesn't define attribute names or the ways they
 are going to be used. Only Reflection API to read.

 There are still a lot of technical problems that have to be solved.
 Right now, we just need to answer a question - if we like this in PHP7?
 Thought and opinions are welcome...

 Thanks. Dmitry.

Hello,

I'd personally suggest you to consider that the Annotations could be
classes, something along the lines of
https://msdn.microsoft.com/en-us/library/aa288454%28v=vs.71%29.aspx#vcwlkattributestutorialanchor1

IMHO it will allow for more usecases and such than simple arrays.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Pavel Kouřil]

On Thu, Feb 12, 2015 at 3:31 PM, Andrea Faulds a...@ajf.me wrote:
 Hi Pavel,

 On 12 Feb 2015, at 13:48, Pavel Kouřil pajou...@gmail.com wrote:

 C# does have dynamic typing.

 No it doesn’t, it’s a statically-typed language. I don’t understand why you 
 say it has dynamic typing - there is some limited dynamism in parts, but I 
 don’t think it affects what we’re talking about. Dynamic typing and 
 polymorphism aren’t the same.


I never said dynamic typing and polymorphism are the same, or did I?
Also, C# has type dynamic, which allows for usage of dynamic typing
in C# (technically, under the hood, it is an System.Object type
without the need for casting, IIRC).

 I just don't believe that method overloading would suddenly make
 everyone write poor programs.

 Maybe not, but all the facilities needed to make good programs are already 
 there. Overloading would only really be useful for writing bad programs, 
 because all the good things it enables are already supported by PHP.

 It brings cleaner declarations of methods and functions.

 Only slightly. A switch() (or better, a pattern match, were we to add that) 
 can do the same job and it’s not that much less clean.


Actually, I wouldn't mind having both pattern matching and method
overloading in PHP. I'd say that both of them have their use, and not
everywhere you'd use pattern matching you'd use method overloading and
vice versa.

function foo(Foo $a) {}
function foo(Foo $a, Bar $b) {}
function foo(Foo $a, Baz $c) {}

This is much much more cleaner than doing:

/**
 * description of what it does depending if you pass Bar or Baz or null
 */
function foo(Foo $a, $b = null) {}

In pattern matching it could be done with, let's say:
foo $a, $b | $b instanceof Bar = {}
 | $c instanceof Baz = {}

Which is IMHO as unclean as using ifs statements inside the method. :(

And at the same time, I don't see how you could do this via method overloading:

signum x |  x  0  = -1
   |  x  1 = 1
   |  x == 0 = 0

I hope this example is correct, it's been a while since I used Haskell.

 Also, it
 brings the possibility of having operator overloading in user classes
 someday in the future (yes, this can be abused as well, but it also
 has legitimate use cases - like class for representing Money and being
 able to do +, - , / or * operations on them).

 Overloading isn’t necessary for operator overloading.


It isn't, but both would be nice.

 Is the option of omiting
 type hints and having optional parameters really a good enough
 replacement for method overloading polymorphism for you? Because for
 me, it unfortunately is not. :(

 Well, yes. PHP is dynamically-typed, this can happen, whether you’re using 
 strict or weak typing. Your only way to guard against it here is to do proper 
 testing. Well, if we added a numeric type hint, your IDE could catch this 
 error for you, actually.

 Anyway, the same thing can happen for float-int conversions *with* weak 
 typing, as we disallow certain conversions (PHP_INT_MIN  $x,  PHP_INT_MAX  
 $x, !isfinite($x), isnan($x)).

 Also, even though PHP does allow most float-int conversions with weak 
 typing, it doesn’t mean they’re a good idea. Silently losing the fractional 
 part is probably not what you want.


As I stated few times already, I find float - int a bad idea (even in
weak mode). That's at least something we can agree on I guess? :)


Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Pavel Kouřil]

On Thu, Feb 12, 2015 at 6:01 PM, François Laupretre
franc...@tekwire.net wrote:
 Hi Robert,

 De : Robert Stoll [mailto:p...@tutteli.ch]

 There are several programming languages which do support dynamic typing
 and method overloading somehow (Clojure, Erlang, Prolog, Cecil and
 certainly more).  Most of them use a multi-method approach and I think if
 PHP would introduce function/method overloading, then such an approach
 would be appropriate. Right now, I need to implement the dynamic
 dispatching quasi myself which might be more verbose but is also more
 cumbersome (and uglier IMO). Consider the following (fictional example):

 We all agree on the interest of polymorphism on object classes, even if your 
 example could be solved with specialized logger classes, but the question was 
 about polymorphism on different scalar types, which is much more problematic 
 in PHP, even using strict scalar typing.

 Cheers

 François


Hello,

actually, I was speaking about method overloading in general, for both
scalars and objects.

Also, I don't see the problems with scalar method overloading problem
with either weak or strict typing. Could you expand that thought,
please?

Regards
Pavel Kouřil

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Pavel Kouřil]

On Thu, Feb 12, 2015 at 1:45 PM, Andrea Faulds a...@ajf.me wrote:
 Hi Pavel,

 C# also doesn’t have dynamic typing. Plus, adding overloading to an existing 
 language is more difficult.


C# does have dynamic typing.

Adding method overloading to an existing language may be more
difficult than creating a new language from ground up, but I'd guess
it's definitely not impossible (I can't say for sure, because I do not
know C and PHP's internals).

 Overloading on scalar types - unpredictable how? Even with weak calls,
 the best candidate could be chosen?

 Still likely to cause chaos. If you can overload based on scalar types, then 
 foobar($a / 2) could call any of *three* different functions.


Sorry, but if you create functions foobar(int $x) and foobar(float $y)
which do totally different things, I'd argue that you brought the
chaos upon yourself. About the third option for called function, I'll
have to admit that I do not know of any other possible signature of a
function that the call could lead to, if we go by choose the best
candidate strategy for resolving.

 Of course, sometimes there will be
 an abmbiguous call, but as long as there would be a way to define
 which call you want, it shouldn't be a problem as well?

 “A way to define which call you want”? Sounds like a hacky workaround to me.


Scratch that, I was thinking about something else while writing this.
Error on an ambiguous call is probably the best way to handle this.

 Poor API - for useland code or in PHP's functions itself? But I don't
 think this should be considered as a real problem, because in userland
 code, developers are able to create a poor API even with the current
 versions of PHP.

 That doesn’t mean we should make it any easier.


I just don't believe that method overloading would suddenly make
everyone write poor programs. Also, they can do the same poor coding
with tons of ifs and elses in one method without typehint and
declaring multiple types in phpDoc (createFrom($a) and @param X|Y|Z in
phpDoc), or they have to create multiple methods which have some
suffix (createFromX, createFromY, createFromZ).

 If someone wants to shoot himself in the foot, he
 will do it in one way or another. And at the same time, polymorphism
 via method overloading can lead to a cleaner APIs, if it's used well.

 I don’t see how. The main things it enables are optional parameters (which we 
 already support) and polymorphism (which we already support). So you’d have 
 to explain what overloading brings to the table beyond those two things.


It brings cleaner declarations of methods and functions. Also, it
brings the possibility of having operator overloading in user classes
someday in the future (yes, this can be abused as well, but it also
has legitimate use cases - like class for representing Money and being
able to do +, - , / or * operations on them). Is the option of omiting
type hints and having optional parameters really a good enough
replacement for method overloading polymorphism for you? Because for
me, it unfortunately is not. :(

 Well, about number type hint. How this would work, in combination
 with strict types?

 function bar(float $f) {
return $f * 1.23;
 }

 function foo(number $x) {
return bar($x);
 }

 foo(1);

 From my understanding, it wouldn’t?

 It would accept an integer or a float, because both subclass number:

 function foobar(): number {
 return 1.0; // okay
 return 1; // okay
 }

 function foo(number $x) {}
 foo(1.0); // okay
 foo(1); // okay

 I don’t see why it “wouldn’t work”.

Read the example once more, please - the issue I see with it is that
bar() requires float, but foo() just number and doesn't convert it to
the required type. The most unpredictable thing is that it will work
half of the time and half of the time it will just throw errors. Sure,
the blame in this case is on all 3 participants - strict typing (and
no int - float conversion), programmer itself and number typehint
(it just doesn't work well with the strict typing) - but as you said,
should you make writing poor programs easier? Just kidding with the
last sentence :) ... but honestly, I do find method overloading and
implicit conversions from int to float a better way to solve the
usecases for number typehint.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Pavel Kouřil]

On Thu, Feb 12, 2015 at 12:44 PM, Andrea Faulds a...@ajf.me wrote:

 PHP already has polymorphism through its dynamic typing. I don’t see method 
 overloading happening any time soon. We have optional parameters and dynamic 
 typing, which all but eliminate the main needs for overloading. We’re a 
 weakly-typed language, so overloading on scalar types might cause 
 unpredictable behaviour (with strict types you’d get an error sometimes, and 
 that’s fine - but calling an entirely different function? Now that’s 
 different.) There’s also the question of how, or if at all, method 
 overloading could interact with our optional parameters and dynamic typing. 
 Finally, overloading can lead to really poor API design: it’s not that 
 uncommon in some languages to see 20 different function definitions with 
 overlapping and non-comprehensive subsets of a method’s behaviour, that are 
 distinguished only by parameter types. It’s one of my least favourite 
 Java/C#/C++ features for that reason.

 In response to saying numbers are not a type: well, they are more of an 
 abstract type which integer and float subclass. We already have internal 
 facilities for converting to and from “numbers” alongside integers and 
 floats, I don’t see why we can’t expose this to users.


Hello,

I don't see any problem with combination of optional parameters with
method overloading. C# has it and it is pretty useful and works there
without any bigger issues. Sure, the dynamic typing may be a (small)
issue, but again, C# does it in an IMHO meaningful way as well and it
can be used as an inspiration, should this way be chosen.

Overloading on scalar types - unpredictable how? Even with weak calls,
the best candidate could be chosen? Of course, sometimes there will be
an abmbiguous call, but as long as there would be a way to define
which call you want, it shouldn't be a problem as well?

Poor API - for useland code or in PHP's functions itself? But I don't
think this should be considered as a real problem, because in userland
code, developers are able to create a poor API even with the current
versions of PHP. If someone wants to shoot himself in the foot, he
will do it in one way or another. And at the same time, polymorphism
via method overloading can lead to a cleaner APIs, if it's used well.

Well, about number type hint. How this would work, in combination
with strict types?

function bar(float $f) {
return $f * 1.23;
}

function foo(number $x) {
return bar($x);
}

foo(1);

From my understanding, it wouldn't?

Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Pavel Kouřil]

On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds a...@ajf.me wrote:

 A number (or numeric, or num, or some other name) type hint is something I 
 plan to propose in a future, follow-up RFC.


Hello,

wouldn't polymorphism (via method overloading) solve the use cases and
be much more useful in the long run than introducing a something
that's not a type into type hints?

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

[Pavel Kouřil]

On Tue, Feb 10, 2015 at 1:52 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi all,

 Some of you are tired with this topic, but please take a look the RFC

 [RFC] Script only includes - this is 3rd version.
 https://wiki.php.net/rfc/script_only_include

 Please let me know what you like or dislike.

 Thank you.

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net

Hello,

IMHO the real solution to this problem is to educate the programmers
how to write safer applications, not by ini settings.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Pavel Kouřil]

On Wed, Feb 11, 2015 at 7:36 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 02/10/2015 07:57 PM, Xinchen Hui wrote:
 am I wrong?!
 seems I am wrong with this, it's a false alarm...  it can restore 
 automatically.

 Yeah, declare() doesn't span files so that isn't a problem.

 My worry is still the lack of type coercion for internal calls. I tested
 it on some apps and it will take quite a bit of tedious and rather
 useless effort to fix these to run in strict mode. Some examples of
 common things that are fatal errors in strict mode:

   ini_set('precision', 14);

   ini_set('display_errors', 1);

   ini_set('display_errors', true);

   ok, not common, but tan(4/2) fatal, tan(5/2) no error

   Wordpress has this function, spot the error:

   function add_magic_quotes( $array ) {
 foreach ( (array) $array as $k = $v ) {
 if ( is_array( $v ) ) {
 $array[$k] = add_magic_quotes( $v );
 } else {
 $array[$k] = addslashes( $v );
 }
 }
 return $array;
   }

   $v may not always be a string (it died with a float for me), so the
   fix is to cast:

 $array[$k] = addslashes( (string)$v );

   Also from Wordpress:

   $formatted = number_format( $number, absint( $decimals ),
 $wp_locale-number_format['decimal_point'],
 $wp_locale-number_format['thousands_sep'] );

   Here number_format() is expecting a float but $number is a string. So
   again, the only real fix is to cast.

   And in Drupal8 *without turning on strict*:

   use Drupal\Component\Utility\String;

   it dies with: Fatal error: string cannot be used as a class name in
 /var/www/drupal/core/includes/bootstrap.inc on line 11

   That String class is everywhere in Drupal. They are going to have a
   fun time with that. See
 https://gist.githubusercontent.com/anonymous/d9252deeeb2aae1a5af5/raw/053155130d22551b1404d0a9b94e27424544b6d1/gistfile1

   From Geeklog:

   if (strtolower($topic) != strtolower($archivetid)) {
 $sql .=  AND ta.tid != '{$archivetid}' ;
   }

   $topic can be null there. Looking at the logic, not really a bug,
   just a natural reliance on null being coerced to 

   Also from Geeklog:

 if( empty( $date )) {
 // Date is empty, get current date/time
 $stamp = time();
 } else if( is_numeric( $date )) {
 // This is a timestamp
 $stamp = $date;
 } else {
 // This is a string representation of a date/time
 $stamp = strtotime( $date );
 }
 // Format the date
 $date = strftime( $dateformat, $stamp );

 strftime() expects an integer for the timestamp there, but as the
 above logic shows, they are expecting a numeric string to be fine.
 No bug, just another forced cast.

 And another number_format() instance where arg1 is not necessarily
 a float. Obviously not a bug, so we have to cast again:

 return number_format( $number, $dc, $ds, $ts );

 In Opencart:

 $this-image = imagecreatetruecolor($width, $height);
 imagecreatetruecolor() expects parameter 1 to be integer, string
 given in /var/www/opencart/system/library/image.php on line 89

 You could argue this is a bug, I guess, but the width and height are
 coming from a database and are integers in the db, but since the db
 returns strings. Another cast...

 I was genuinely hoping to find some bugs with this exercise. I suppose
 it is because I did it on mature projects and at this stage those sorts
 of bugs have already been fixed. But I still fear that people are going
 to want to be enable strictness everywhere and then they will quickly
 learn that they better cast stuff to be safe which makes the whole thing
 rather pointless. And I feel pretty sorry for the Drupal folks. That
 list of 1000+ instances of their String class is going to suck to fix.

 -Rasmus



Helo,

the Drupal thing seems scary.

Also, I realized one thing why I think the strict version is a bad
idea for PHP (in the state PHP is now - in an ideal world I would love
to have nothing but strongly typed PHP, but that's offtopic) - PHP has
many functions that return multiple types, so you cannot do foo(bar())
if bar() has multiple return types. :(

Regards
Pavel Kouril

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

Re: [PHP-DEV] Design by Contract

[Pavel Kouřil]

On Tue, Feb 10, 2015 at 1:30 PM, Alexander Lisachenko
lisachenko...@gmail.com wrote:
 2015-02-10 15:20 GMT+03:00 Dmitry Stogov dmi...@zend.com:

 I thought about this way, and you are welcome to start composing another
 RFC. it makes sense and has its advantages.
 Unfortunately, it relays on many unavailable features that has to be
 designed as well (annotations, AST manipulation, opcode manipulation), but
 may be this is a right road.



 Thanks, Dmitry! Your position is clearly highlight my vision, it's not so
 easy, but maybe it will bring us much more profit at the end.


 2015-02-10 15:20 GMT+03:00 Dmitry Stogov dmi...@zend.com:

 D and Effiel approach may work as well, but if you like another
 (annotation based) approach - be involved into development.
 At first we'll need 3-rd RFC that defines all the things that must be
 implemented.
 I may help, with RFC, design and implementation.


 Thanks, your help is really appreciated ) I'l try to start another one RFC
 about this API, let's have a look what can be done.

Hello,

maybe you could try to consult your ideas with Ivan Enderlin. He
mentioned in previous emails (for instance
http://news.php.net/php.internals/82245) that he would prefer some
AOP/hook-based approach to DbC as well, so it may be compatible with
your mindset.

Regards
Pavel Kouril

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

Re: [PHP-DEV] Design by Contract

[Pavel Kouřil]

 There are a lot of researches in this field. PHP has a great opportunity to
 not close the doors by forcing a language. I suggest you to offer an API to
 hook on the runtime and “control” it, like AOP does. It will open the doors
 to so many interesting contributions!


Hello,

after reading this discussion, this seems like the best way to handle DbC.


Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Pavel Kouřil]

On Mon, Feb 9, 2015 at 9:04 AM, Dmitry Stogov dmi...@zend.com wrote:
 this is more or less true. :(
 The proposal is presented in an unfair way to include strict typing without
 the ability to vote for weak types only.

 Despite of semantic arguments, the implementation is a bit immature and
 introduces slowdown for any code without type hints.

 Thanks. Dmitry.



This is something I mentioned several times - there should be two
votes. One for weak types and one for adding the strict typing on the
weak typing as a bonus. Not bundling it into one voting, it makes it
feel forced.


Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Pavel Kouřil]

On Mon, Feb 9, 2015 at 9:22 AM, Pierre Joye pierre@gmail.com wrote:


 I am not saying I want one or the other (I have voted and now only
 focus on solving possible tech issues we may find) but trying to be
 fair with Andrea's RFC and amazing effort:

 What you ask is basically part of the RFC already, your code can be
 strict free if you wish to, or it will be by default. Only issue is
 the massive misunderstanding behind the declare(strict) thing.

 Cheers,
 Pierre

I'm not saying one or the other - I mean two votes, one for the
basic weak typing and if it passes, then vote for adding the
declareable optional strict typing. Now it is unfortunately both or
neither.

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Pavel Kouřil]

On Sat, Feb 7, 2015 at 11:11 PM, Andrea Faulds a...@ajf.me wrote:
 Hi,

 On 7 Feb 2015, at 22:03, Pavel Kouřil pajou...@gmail.com wrote:


 Yeah, but you say in the RFC that With this approach, an argument is
 only accepted if its type is exactly the same as the parameter. when
 speaking about C# and Java - which is NOT true.

 C# and Java aren’t really considered weakly-typed. Technically they’re not 
 “fully strict” I guess, but if you were to give example of strictly-typed 
 languages, you’d probably include C# and Java in that list - so I did.

C# and Java definitely aren't weakly typed. I never said they are
though? Also, is there a real difference between strict and strong?
Because C# refers to itself as a strongly typed, but you use strict
typing everytime you speak about strong typing?


 It might be somewhat misleading. Really, what’s “weak” and what’s “strict” is 
 rather subjective: C is sometimes considered weak, sometimes strict. I’d say 
 it’s more “weak” because all sorts of definitely wrong conversions are 
 allowed implicitly and merely generate warnings. C# and Java are more careful 
 here, so I’d say they’re “strict” even though I suppose they do have a degree 
 of weak typing.

 Also, there's no need to mention
 float - int, because that one is definitely wrong. But for the int
 (and long, etc) - float (and double) - how do the languages you
 mentioned in the RFC handle that conversion?

 From Microsoft’s documentation that you linked, it sounds like they just 
 always convert and never error, so you’d get data loss in some cases (just 
 like you do in PHP with an explicit cast).

 I am familiar with other languages, I just disagree with their approach.


It's not somewhat misleading, it's 100% misleading - because you state
that it acts like in Java and C#, but it doesn't. Also, are there any
strongly typed language that implement strong/strict typing the way
you want to do it in PHP?

 And as I said myself
 multiple times in the past, the declare syntax IS just ugly (and
 changing how code works by writing one line is an ugly principle as
 well, IMHO). :(

 I prefer this approach to the inconsistency the other approaches suggested 
 thus far lead to.


The thing is, you cannot please everyone. When you try to please
anyone, you usally end up with something that has flaws for everyone
to some degree. :(

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Pavel Kouřil]

On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds a...@ajf.me wrote:
 Good evening,

 At long last, I’m going to put the RFC to a vote. It’s been long enough - I 
 don’t think there needs to be, or will be, much further discussion.


Hello,

I just realized it now (I brought it up in a different manner when
there was discussion about the RFC), but I didn't notice there was a
totally false statement about it in the RFC itself. You probably
should fix it. I'm speaking about the Strict type checking, which is
used by many popular programming languages, particularly ones which
are statically-typed, such as Java, C#, Haskell, or Facebook's Hack.
It is also used for non-scalar parameter type hints in PHP. With this
approach, an argument is only accepted if its type is exactly the same
as the parameter. paragraph.

This is NOT true (at least for C# and Java), as you can read here in
the documentations of respecitve languages so you should not compare
the strict version of the typing implemented in PHP with other
strongly typed languages, because the PHP's strict is stricter than
strongly static typed languages. I really hope noone voted with the
thought that the strict typing acts as it does in Java and C#.

https://msdn.microsoft.com/en-us/library/y5b434w4.aspx
http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2


Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Pavel Kouřil]

On Sat, Feb 7, 2015 at 9:57 PM, Andrea Faulds a...@ajf.me wrote:
 Hi,

 On 7 Feb 2015, at 20:47, Andrea Faulds a...@ajf.me wrote:

 On 7 Feb 2015, at 10:57, Pavel Kouřil pajou...@gmail.com wrote:

 I just realized it now (I brought it up in a different manner when
 there was discussion about the RFC), but I didn't notice there was a
 totally false statement about it in the RFC itself. You probably
 should fix it. I'm speaking about the Strict type checking, which is
 used by many popular programming languages, particularly ones which
 are statically-typed, such as Java, C#, Haskell, or Facebook's Hack.
 It is also used for non-scalar parameter type hints in PHP. With this
 approach, an argument is only accepted if its type is exactly the same
 as the parameter. paragraph.

 This is NOT true (at least for C# and Java), as you can read here in
 the documentations of respecitve languages so you should not compare
 the strict version of the typing implemented in PHP with other
 strongly typed languages, because the PHP's strict is stricter than
 strongly static typed languages. I really hope noone voted with the
 thought that the strict typing acts as it does in Java and C#.

 https://msdn.microsoft.com/en-us/library/y5b434w4.aspx
 http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2

 I don’t think it’s unfair. There’s a limited set of permitted conversions in 
 some strictly-typed languages, but it’s still strictly-typed.

 To add to the previous email:

 * Most of these conversions are between different sizes of the same type 
 (float/double, char/short/int/long, etc.), but this is irrelevant to PHP 
 which has only one size for each type
 * The other ones are between types (int to float)
 * Always allowing implicit conversions from float to int is very likely to 
 cause data loss, so it’s not unreasonable for PHP to prevent this specific 
 case
 * Always allowing implicit conversions from int to float is sometimes going 
 to cause data loss, so it may also be reasonable for PHP to prevent this 
 specific case
 * Requiring an exact type match has the least mental overhead, and allows 
 types to be checked at compile-time


Yeah, but you say in the RFC that With this approach, an argument is
only accepted if its type is exactly the same as the parameter. when
speaking about C# and Java - which is NOT true. You should have
written that the way of strict typing in PHP is even more strict than
Java's and C# one - because the way it's written now is unfortunately
misinforming the readers of the RFC. Also, there's no need to mention
float - int, because that one is definitely wrong. But for the int
(and long, etc) - float (and double) - how do the languages you
mentioned in the RFC handle that conversion?

I'm wishing more and more that the RFC doesn't pass (even though I'd
LOVE to have typehints in PHP as a userland developer) and someone
else will make a better version of typehints RFC for  PHP 7, because
this one feels really like you took an ok-ish RFC (one that would be
good for PHP) and slapped a strict typing on it without enough
research about strong typing in other languages. And as I said myself
multiple times in the past, the declare syntax IS just ugly (and
changing how code works by writing one line is an ugly principle as
well, IMHO). :(

Regards
Pavel Kouril

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

Re: [PHP-DEV] What do we need strict scalar type hints for?

[Pavel Kouřil]

On Thu, Feb 5, 2015 at 9:59 AM, Stanislav Malyshev smalys...@gmail.com wrote:
 Hi!

 However I feel like the fact that it only affects your app (even if
 you use a library relying on strictness) if you want to is not clear
 for everyone replying here. Is this point clear for you?

 I was addressing the idea that every scalar type mention should be
 strict. If it is a choice, I am more open to it, even though I think
 declare is a very ugly way of doing it. I'd rather have foo(scalar $bar)
 for traditional (coercive) scalar typing, and something like foo(scalar!
 $bar) (you can bikeshed the syntax if you like) for strict typing. It is
 immediately clear what each one does, does not conflict with PHP
 tradition, and allows to freely choose and intermix strictness levels as
 one's hear desires.

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

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


Hi,

the problem with foo(string $bar) and foo(string! $bar) or
foo((string) $bar) is that the writer of the method is deciding, not
the caller - but in both cases, the method gets exactly what it needs
to have, so the way how it should be passed should be upon the caller.

Also, this discussion shows why exactly is it a bad idea to have two
ways of passing parameters - it's a mess and there isn't an ideal way
how to solve it.

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

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

[Pavel Kouřil]

On Wed, Feb 4, 2015 at 6:17 PM, Andrea Faulds a...@ajf.me wrote:
 Hey,

 On 4 Feb 2015, at 17:10, Crypto Compress cryptocompr...@googlemail.com 
 wrote:

 I would go with Http\

 Why not the reserved Php\Http\?

 This sounds good to me. php\ is already reserved, and it’s similar to the 
 common community convention of vendor\packagename. (e.g. ajf\escapes.) Would 
 work well with Composer and Packagist too, as it could be a virtual php/http 
 package (Packagist naming convention).

 Also, I’d like to say I’d prefer php\HTTP or php\http over php\Http. 
 Capitalising an acronym doesn’t feel right to me, perhaps because case is 
 usually significant, Following the Casing Rules Used by Titles. Of php\HTTP 
 and php\http, php\http is probably better since the case matches that of 
 php\. It could also be PHP\HTTP, I guess, but lowercase is somehow more 
 appealing to me.

 Thoughts?
 --
 Andrea Faulds
 http://ajf.me/





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


Personally,

From my userland point of view, I would expect it to follow the same
capitalization rules as classes are supposed to follow, making it
Php\Http.


Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Combined Comparison (Spaceship) Operator

[Pavel Kouřil]

On Mon, Feb 2, 2015 at 11:50 PM, Stanislav Malyshev smalys...@gmail.com wrote:
 Hi!

 I personally would use spaceship operator often, but only if PHP had
 operator overloading for classes. So I hope it will pass and operator

 PHP has operator overloading for classes, but just for internal ones.
 See: https://wiki.php.net/rfc/operator_overloading_gmp

 For userspace ones, the feeling is unlimited overloading would be a bit
 too chaotic.
 --
 Stas Malyshev
 smalys...@gmail.com

Hello,

yeah, I meant userspace operator overloading. I don't think it would
be chaotic - for instance C# allows it and it comes in handy sometimes
and is not chaotic at all.

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

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

[Pavel Kouřil]

On Wed, Feb 4, 2015 at 2:00 PM, Michael Wallner m...@php.net wrote:
 Hi!

 Do we want to discuss anything further before I put this to vote again?

 https://wiki.php.net/rfc/pecl_http

 Points explicitely marked for discussion in the RFC itself:

 * pecl/propro
   Proxies for properties representing state in internal C structs
   https://wiki.php.net/rfc/pecl_http#peclpropro

 * pecl/raphf
   (Persistent) handle management within objects instead of resources
   https://wiki.php.net/rfc/pecl_http#peclraphf
   Also, take special note of the INI setting:
   https://wiki.php.net/rfc/pecl_http#raphf_ini_setting

 * POST parsing disregarding request method, solely based on content-type
   https://wiki.php.net/rfc/pecl_http#rinit

 JFYI, I've create a POC for HTTP2 support:
 http://git.php.net/?p=pecl/http/pecl_http.git;a=shortlog;h=refs/heads/http2-poc

 This is for PHP5, though, and needs a recent libcurl built with nghttp2
 support.

 --
 Regards,
 Mike

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



Hello,

as I mentioned already in the other thread - there are currently no
coding standards related to namespace naming in
https://github.com/php/php-src/blob/master/CODING_STANDARDS and the
coding standards should probably be updated before voting, since this
extension contains namespaces.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Combined Comparison (Spaceship) Operator

[Pavel Kouřil]

Hello,

I personally would use spaceship operator often, but only if PHP had
operator overloading for classes. So I hope it will pass and operator
overloading will pass someday as well (but operator overloading would
probably require method overloading first and that's a thing you guys
oppose, right?).

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] [VOTE] pecl_http

[Pavel Kouřil]

On Sat, Jan 31, 2015 at 1:41 PM, Pierre Joye pierre@gmail.com wrote:

 There is zero reason to discuss what has been approved and followed for
 years already.

 I will simply post the link to our CS as a reminder and ask everyone to
 read it if they never did:

 https://github.com/php/php-src/blob/master/CODING_STANDARDS

Well, the coding standard doesn't mention namespaces. So shouldn't it
be updated to include namespaces? If there's an RFC for including
something using namespaces, the should be rules for naming namespaces
in the coding standard, IMHO.

Pavel Kouril

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

Re: [PHP-DEV] [RFC] [VOTE] pecl_http

[Pavel Kouřil]

On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner m...@php.net wrote:
 Hi,

 Discussion has been very low on this topic since it was proposed on
 August 19th, so I just opened the vote on the RFC whether to add
 pecl_http to the core. The vote will be open until about 12:00 UTC on
 Friday, February 6th.

 https://wiki.php.net/rfc/pecl_http#vote


 --
 Regards,
 Mike

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


Hello,

just one observation - would be the name of the classes and namespaces
stay the same after merging? I personally find the lowercased
namespace name kinda weird, given that most of code written in PHP
I've seen is using CamelCase.

Maybe there should be an RFC which would standardize naming and etc.
for future features?



Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] Scalar Type Hints

[Pavel Kouřil]

On Sun, Jan 25, 2015 at 5:02 AM, Andrea Faulds a...@ajf.me wrote:
 Hi everyone,

 Just a few small updates.

 I’ve made a small change to this RFC. Instead of the strict mode syntax being 
 declare(strict_typehints=TRUE), it’s now declare(strict_types=1) instead. 
 This makes it a bit quicker to type - important given you’d need to type it a 
 lot - without sacrificing much readability. It also avoids using the words 
 “type hint”, which I understand are contentious to some people.

 The patch now includes a more extensive set of tests: 
 https://github.com/TazeTSchnitzel/php-src/tree/scalar_type_hints_2_strict_mode/Zend/tests/typehints/

 The pull request is also now green on Travis (aside from two failures on the 
 debug build - but they also fail in master).

 Levi’s Return Types RFC has now passed, so now the RFC needs to cover that. 
 The RFC currently doesn’t discuss return types, save for a paragraph in the 
 Future Scope section. When the return types patch is merged, I’ll update the 
 scalars patch, and then update the RFC. A point of contention here is whether 
 or not return types should always be strict, or whether they should also obey 
 the strict/weak modes. I’m not entirely sure on that one, that specific item 
 may end up going to a vote. That said, I do lean towards always strict, given 
 you can usually ensure your return type’s correct.

 Thanks.

 --
 Andrea Faulds
 http://ajf.me/


Hello,

personally I still don't like this RFC in it's current form and
shorter declare won't change it. I was thinking a lot about the
typehints in PHP for last few days and I think having only one way
would be the best - and it's somewhere between the curent weak and
strict typing. My main issue is that the current weak typing is too
loose and the strict typing is too strict.

The problem with the current strict typing is that you cannot pass
int to a float parameter, even though there can be a totally
lossless conversion and it works in other strongly typed languages.
And being able to pass a float(1.5) to int and lose the 0.5 value
doesn't make sense as well, because data will get lost. Neither of
those feels somehow predictable and natural.

Also, after a little bit of thinking, if someone needs to do a type
conversion while calling a method, writing foo((int) $bar) isn't that
hard.

So, I think it would be best to choose just one of these two
approaches and either loosen it a little or make it more strict (so
data loss doesn't happen). But I guess this approach would be
inconsistent with how the built-in PHP functions work?

PS: Ideally, the data loss rules should be made for types and not
values (like the old scalar type hints RFC had), so you don't get
unpredictable results. The only ones I can think of right now are
basically int - bool, int - float, object (w/ __toString) - string,
int - string, float - string?

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] Scalar Type Hints

[Pavel Kouřil]

On Sun, Jan 25, 2015 at 5:05 PM, Andrea Faulds a...@ajf.me wrote:
 Hi Pavel,


Hi, thanks for explaining some things.


 It can *sometimes* be a lossless conversion. Only sometimes.

 For float to int conversion:

 * Floats have the special values INF, NAN and -NAN, which cannot be preserved
 * Floats have negative zero, which also cannot be preserved
 * Fractional components cannot be preserved
 * Floats sacrifice precision to allow a wider range of values. They work with 
 significant figures (scientific notation), unlike integers which always offer 
 full precision. So a particular float value isn’t necessarily equivalent to a 
 particular integer value, you have to invent precision to do the conversion. 
 2e10 is dealt with as if it’s 2 with 10 zeroes after it, but it’s just a 
 number beginning with 2 that has a magnitude of roughly 10^10. If you convert 
 it to the integer value 20 000 000 000, you’ve just invented values for those 
 trailing digits - those digits weren’t necessarily zero, we just don’t know 
 what those digits are. Someone who’s an expert on floating-point might need 
 to correct me here, but I think this is correct to some extent. What I’m 
 saying is that float-integer conversion is inherently imprecise.

 For int to float conversion:

 * Values beyond 2^53 or below -2^53 cannot be represented as floats without a 
 loss of precision

 Some strongly-typed languages allow these conversions implicitly, but I’m not 
 sure that’s a good thing or something we should want to copy. Loss of 
 precision isn’t good. If you ask for strict typing, you probably want to 
 avoid it, and should get strict typing.

 And being able to pass a float(1.5) to int and lose the 0.5 value
 doesn't make sense as well, because data will get lost. Neither of
 those feels somehow predictable and natural”.

 Sure, but it is our existing behaviour.


Yeah, as I said, implicit float to int is IMHO bad and I personally
don't like it much, because data loss sucks. But being consistent with
existing behavior is probably the right way to do stuff.

About the problem with int to float and loss of precision beyond 2^53:
I didn't realize that, was thinking just about 32bit integers when I
wrote that. But now I wonder how other languages do it, when they are
implicitly converting 64bit integers to double precision floating
point numbers.


 Unfortunately we don’t have safe casting functions because they were 
 rejected. Alas.

 So, I think it would be best to choose just one of these two
 approaches and either loosen it a little or make it more strict (so
 data loss doesn't happen). But I guess this approach would be
 inconsistent with how the built-in PHP functions work?

 While it never went to a vote, the Scalar Type Hinting with Casts RFC, which 
 proposed stricter weak casts, was not well-received. The Safe Casting 
 Functions RFC was rejected when it went to a vote.


Oh, I didn't know that stricter weak casts were not well-recieved,
because I didn't read internals mailing list back then. But if that's
the case, I would gladly see the weak variant of this RFC accepted.
Have you thought about splitting this RFC into two? One for adding the
weak version and another one for adding the declare strict statement?


 The Scalar Type Hinting with Casts RFC didn’t do that, it was also based on 
 values.

 In a dynamically-typed language like PHP, I don’t see why it needs to be 
 type-based rather than value-based.


Maybe I wrote it wrong; I knew the old RFC had conversions based on
values. I just thought the rules based on types (you definitely know
what you need to convert and what not before calling a function) would
make much more sense, but the problem with 2^53 means that the
typed-based conversions are not a great solution either.



Pavel Kouril

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

Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list

[Pavel Kouřil]

On Fri, Jan 23, 2015 at 10:18 PM, Jan Ehrhardt php...@ehrhardt.nl wrote:
 Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400):
master branch.

 propro, raphf and pecl_http do not compile with the master branch.
 You'll have to checkout the phpng branch. These extensions did compile
 and load:
 https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm

 Build:
 https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip

 Maybe there are other PECL extension that have PHP7 branches, unknown to
 you and me.

 Jan

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


Hello,

may I use your build for testing my applications compability with PHP
7? I would like to try PHP 7, but I'm not really feeling like
compiling it by myself for Windows (I probably even don't have all the
tools needed for it); or is there a simple HOWTO for building it
myself?

Regards
Pavel Kouril

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

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Pavel Kouřil]

On Thu, Jan 15, 2015 at 4:11 PM, Jordi Boggiano j.boggi...@seld.be wrote:

 Reading the thread at this point shows so much confusion, it seems half the
 people reading the spec misunderstood that the declare() line affects
 function calls only and not the API/implementation level.

 As much I think it was a smart idea and workaround, it is perhaps too clever
 for its own good if nobody gets it.

 Anyway, as v0.2 appears to be v0.1 + declare(), why not keep those two
 options separated in the vote?

 a) should be add weak typing
 b) should we also add declare() for to get strict typing at call-site.

 If *a* passes it would be a great stepping stone towards adding *b* later
 perhaps, or tweaking internal coercion rules to improve the behavior of the
 weak types, having scalars in return hints (since return hints seem likely
 to pass), etc.

 If *b* passes as well great we have a complete picture and every team can
 have declare() Y/N in their own coding guidelines based on preference.


Yeah, while the confusion is definitely still there, I would
personally argue that definitely some people who oppose the declare()
get that it's only for calls in the file - and still don't find it
clever.

The potential issues with this are pretty real, to be honest. Simple
things like moving a method from one class to another (let's say to
parent or descendant) and getting to another typing context may cause
unpredictable behavior if the user forgets to have declare() in both
files.


Pavel Kouril

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

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Pavel Kouřil]

On Thu, Jan 15, 2015 at 4:35 PM, Jordi Boggiano j.boggi...@seld.be wrote:

 I mean that if someone wants strict typing they won't want to use weak hints
 because that would coerce the data before they can verify it and ensure
 their code is strictly typed.

 Therefore the best course of action is to have no hint + check manually,
 like they are doing now with such libs.


I'm sorry, but I still don't follow.

For the writer of a library, he is always guaranteed to get the types
he wants (declared in typehints) and therefore checking inside the
method doesn't really make any sense. Or are you saying that
developers would use checks inside of methods instead of typehints,
even if the RFC passed in its current state with the declare()
statement?


--
Pavel Kouril

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

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Pavel Kouřil]

On Thu, Jan 15, 2015 at 4:19 PM, Jordi Boggiano j.boggi...@seld.be wrote:

 Right now, or with only weak hints, if a library decides to implement strict
 typing, they'll skip the scalar hints and check types with something like
 the assert lib [1]. A user calling it with random data would *always* get
 exceptions. There is no way for the library to use scalar hints to play nice
 with weak-typed callers as it would not be able to type check anymore in
 that case.


Why would the libraries writers use the checks inside the method
instead of the typing, even in the case of the weak typing? I don't
see a single reason to do so, because if they ask for an int in the
method signature, they will get an int or the method won't get called
at all. See the example in the RFC with the if (!is_int($i)).



Pavel Kouril

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

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Pavel Kouřil]

On Thu, Jan 15, 2015 at 9:29 AM, Lester Caine les...@lsces.co.uk wrote:

 One of the nice features of PHP when I started using it all those years
 ago was that I did not have to create separate functions different types
 did exist in the source data. int/float/num/double and others all needed
 separate handling in c/c++, and one could not easily add a different
 'type' of data.


If you have a function which requires a double in C# (a strongly
typed language), you can safely pass int to the function and it will
work, because you are not narrowing the possible values. So making the
PHP accept only the argument if its type is exactly the same as the
parameter (paraphrased from RFC for the strict version of type hints)
seems like a step in a wrong direction. If I'm not mistaken, Java
behaves the same way. How exactly does it work in C++ and C? I haven't
used C in years, so I'm a little bit rusty on this detail.

Pavel Kouril

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

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Pavel Kouřil]

 On Wed, Jan 14, 2015 at 11:28 PM, Andrea Faulds a...@ajf.me wrote:
 From what I can see, the larger PHP community is generally in favour of 
 strict typing, and among them, the previous RFC revision was received quite 
 poorly. Myself, I might have been somewhat happy with just weak hints, but it 
 would upset an awful lot of developers who would like some measure of strict 
 typing. Developers who would most likely not use the new scalar type hints, 
 because they weren’t strict. And if nobody uses them, why add them?

Actually, what's the big difference, making weak typing worse and less
useable? The people who write libraries are guaranteed either way that
the input parameters for their methods will be of desired type in both
cases. And the people who use them either can do the conversion
themselves (in strong typing case) or let the language help with it
for them (in weak typing case) - which is IMHO fine, as long as the
conversions are kinda predictable and 100% documented.

And yesterday I was pointed out one thing: the RFC states With this
approach, an argument is only accepted if its type is exactly the same
as the parameter.. Does this mean you cannot pass integer to a
function with float argument in the strict mode?

Is it strong or strict, btw? I always thought it's supposed to be
strongly typed, but since I saw strict typing here used by
everyone, I'm not sure now.

Pavel Kouril

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

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Pavel Kouřil]

Hello,

personally, as a language user, I really dislike the idea of both
options for scalar type hinting to be the part of the language.
Especially since you would have to declare the strict typing in each
file (if you are going by 1 class per file in a bigger project, that's
a LOT of declare directives to write in the long run) and if you'd
forgot once, it would make the calling of methods somehow
inconsistent.

I wish there was just one way to do it; I don't care if the weak or
strong variant is going to be accepted, IMHO most programmers will be
able to adapt to either of them. The weak version makes probably more
sense for PHP and how it handles scalar types (at least from userland
developer's standpoint), but either of them is better than no
typehints at all. :)

PS: Personally, I find the scalar typehint idea useless and cannot
find a real use case for it. Richard, would you mind giving an
example?

Regards
Pavel Kouril

On Wed, Jan 14, 2015 at 2:35 PM, Zeev Suraski z...@zend.com wrote:
 I don’t think we’re ever going to get consensus.  But judging by the
 feedback to the v0.1 version, I tend to disagree that the opposers would
 have blocked it.  There were certainly opposers – but not that many of them
 as far as I could tell.  I think it stood a good chance to pass at a 2/3.
 Unlike strict typing – we didn’t even go to a vote on it, which I think is
 unfortunate (and should be changed, before changing course completely as
 this v0.2 suggests).



 We’re definitely not going to have consensus on introducing both options as
 per this RFC.  I for one think it’s the worst possible option.



 Zeev





 *From:* Richard Quadling [mailto:rquadl...@gmail.com]
 *Sent:* Wednesday, January 14, 2015 3:23 PM
 *To:* Zeev Suraski
 *Cc:* Andrea Faulds; Leigh; PHP Internals List
 *Subject:* Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2







 On 14 January 2015 at 09:41, Zeev Suraski z...@zend.com wrote:

 -Original Message-
 From: Andrea Faulds [mailto:a...@ajf.me]
 Sent: Wednesday, January 14, 2015 11:33 AM
 To: Leigh
 Cc: PHP Internals List
 Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

 Hi Leigh,

  On 14 Jan 2015, at 09:17, Leigh lei...@gmail.com wrote:
 
  I really don't like this behaviour being changed at the call site. If
  I design a function that I _know_ should only take a string, then I
  want it to be an error if the user supplies anything else, so that
  they know they messed up.

 I don’t like the idea of being forced to use strict (or weak) type
 checking
 because the API author decided as much.

 I don't either.  But I don't like the user to do it either, it's something
 that is a part of the language definition.

 I completely agree with both Robert and Leigh.  I liked the v0.1 one, but
 v0.2 is DOA from my point of view.  Arguably, from my POV, it's the one
 option that's even worse than having strict typing exclusively.

 Zeev



 The issue of scalar type hinting has been around for a while, with various
 proposals and RFCs, but no consensus. Each time a certain level of progress
 is made, more issues arise.



 It would seem that the major issues is that whatever a library/framework
 developer decides, the user of that library/framework would have to develop
 their application to fit. Is this such a bad thing? The comeback to that is
 that PHP supports type juggling, so there is a different mechanism for
 non-scalars to scalars. Fair enough.





 From the lib developer's perspective, if a parameter to a function/method
 is going to be treated as an integer and is expected to be an integer, then
 they should be able to force/limit this just like they can when they say it
 must be an array/callable/class/interface. But take into account the option
 to enforce the type juggling.





 I get 3 questions from this.



 1 - Should the type hint restrict non matching types?

 2 - When should the value be juggled to match the type hint if it is
 different?

 3 - Could we allow different signatures for the same method name? - A
 different question entirely, but one that may be worth having in relation
 to this proposal.





 Whatever mechanism is used, it needs to be of zero effort for the user, but
 fully understood of the effect.





 I think to answer all of this, and to provide enough flexibility that
 everyone can be made happy and understand the effect, I think the issues
 could be resolved with the following.





 1 - A type hint of 'scalar' is required.



 This excludes other types (array/callable/class/interface) and would
 specifically mean that no type juggling will take place as part of the
 parameter passing.



 If no type juggling is going to take place, why does it matter what the
 type hint is? The advantage of having 'scalar' as a type hint is, as I
 said, excludes non-scalars.



 Now, if the method does something to the value and the value is passed by
 reference, then that would need to be documented clearly.







 2 - A scalar type type hint will