Re: [PHP-DEV] What do we need strict scalar type hints for?
Hi Robert, > On 4 Feb 2015, at 09:38, Robert Stoll wrote: > > Personally I am not in favour of the declare approach because the user will > need to switch between strict context and non-strict context which will be > quite challenging, anti-efficient (in terms of productivity) and most > probably another source for bugs. I’ve found this not to be quite true in practice. When I ported my app to use strict scalar hints, very little broke - and this is an app that took advantage of weak typing everywhere. I realise switching contexts might be a little painful, but it doesn’t seem to be as bad as I expected. It looks to me like much PHP code is already fairly strict and consistent with its types. I think it’s mostly just edge cases where things break with strict types on. Any strict code will work fine as “weak” code, and most weak code will work fine as strict code, I think. > Yet, I have to defend Andrea's RFC here since the claims made that it will > break all kind of existing code is just not true (or I got the RFC completely > wrong). > > sin(1) would only be broken if and only if the user has decided to use it in > a strict mode. Consider the following: > > User A writes the file index.php > > $a = sin(1); //perfectly fine > include 'test_strict.php' > ?> > > and user B writes test_strict.php > > declare(strict=1); > $b = sin(1); //will fail and that's ok [*] since the user decided to be in > strict mode > ?> > > As far as I can tell user A which want to code in non-strict mode could do so > also in the future - no error is reported, no problem at all. Only user B > would get the error and only because he/she wanted to be informed when > his/her code is not strict. > > [*] we could actually distinguish between int literals/constants and int > variables. The above case would be fine as well since 1 can be int or float > (pretty much as Haskell is handling it) Yeah, I only had int/float issues when I turned on strict mode in my app. And that caught a bug, actually, so I was quite thankful for it. -- Andrea Faulds http://ajf.me/ -- 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?
Hi again,
> On 4 Feb 2015, at 11:15, Andrey Andreev wrote:
>
> On Wed, Feb 4, 2015 at 1:02 PM, Florian Margaine wrote:
>> Hi Leigh,
>>
>> Le 4 févr. 2015 11:50, "Leigh" a écrit :
>>>
>>> What was wrong with:
>>>
>>> function x(int $y, string $z) { // strict
>>> function x((int) $y, (string) $z) { // casting
>>>
>>> This was the best suggestion I've seen that covers the requirements of
>>> both camps, and is still very clear how data is going to be handled.
>>>
>>> Authors who want their APIs to adhered to strictly can do that,
>>> authors who want to accept anything and have it end up as their
>>> desired type can do that too.
>>
>> Because it is then the callee who decides, not the caller, whether or not
>> he wants strict typing.
>>
>
> ... and apparently, this is the root of all evil. :)
It’s not “the root of all evil". But the two-syntax approach has disadvantages
I’ve elaborated numerous times.
It shifts the choice to the callee, not the caller. This means existing
applications are broken if strict hints are added to existing libraries. It
means that programmers will have to deal with two different systems,
simultaneously, in the same file or function or method, because one API uses
(int) and the other uses int. It means that if the API author decides to have
weak types, you are prevented by the language from having the benefits of
strict typing, even if you want them. It also has a syntax issue: (int) looks
like an explicit cast, yet what is usually proposed doesn’t something similar.
There’s also the consistency issue in that we’d have to support real for
consistency with (real), since T_DOUBLE_CAST is a token. It means that internal
functions could now also use strict hints - or if they can’t, we have a
consistency issue. It means beginners, and people who don’t like strict types,
now have to deal with strict types in their code, despite PHP always having
been a weakly-typed, beginner-friendly language. And so on, and so forth.
The current RFC deliberately does not propose this because I think it causes
more problems then it solves.
> I am baffled by how the two-syntaxes suggestion is always so easily
> dismissed by that argument. I'd argue that most people who support the
> current proposal don't fully understand what declare(strict_type=1)
> really does.
Well, *I* understand what it does. I’ve used it. It worked really,
fantastically well… better than I expected it to. It provided benefits that the
two-syntax suggestion wouldn’t have. It provided benefits that just strict
hints wouldn’t have. It provided benefits that just weak hints wouldn’t have.
> As I've previously said - putting the caller in control
> (and really the caller, not in a per-file context) makes it a
> debugging tool, not support for strict typing.
What’s the difference between “per-file” and “really the caller”? The RFC
*does* allow you to use declare() blocks if you really want to.
Also, type hints are mostly a debugging tool anyway. They’re a tool for
catching errors early, and to enable better documentation. That’s all that they
do.
--
Andrea Faulds
http://ajf.me/
--
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?
Hi, > On 4 Feb 2015, at 18:41, Andrey Andreev wrote: > > I didn't want to turn this thread into a re-iteration of the RFC > discussion one. I'm just completely surprised how relentlessly all > suggestions about two syntaxes have been waved off by a callee vs > caller argument like it's a golden rule or something ... it's not, you > just don't like the other approach. I think it’s a shorthand for listing, again, all the problems with shifting the choice onto the caller. The subject has been debated to death. People aren’t being dismissive - the problems with it have already been covered extensively. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow dropping typehints during inheritance
Hi Nikita,
> On 4 Feb 2015, at 18:49, Nikita Popov wrote:
>
> Currently we do not allow [1] removing a typehint during inheritance. For
> example the following code is not valid:
>
>interface A {
>public function method(Typehint $param);
>}
>class B implements A {
>public function method($param);
>}
>// Fatal error: Declaration of B::method() must be compatible with
> A::method(Typehint $param)
>
> The above code does *not* constitute an LSP violation, because B::method()
> accepts more inputs than A::method(). However we still forbid it.
>
> This is an issue, because it makes it impossible to add typehints to
> parameters at a later point in time. I've seen this issue come up both in
> userland code, as well as in a recent DateTime change, see
> https://github.com/php/php-src/commit/8e19705a93d785cd1ff8ba3a69699b00169fea47
> .
>
> Instead of reverting the DateTime BC break, I'm wondering if it wouldn't be
> better to fix the root cause by making the inheritance check less strict
> and allow removing typehints?
Sounds sensible to me.
Of course, the reverse is true for return types, which should be either
covariant or invariant. :)
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow dropping typehints during inheritance
Hi Hannes, > On 4 Feb 2015, at 23:58, Hannes Magnusson wrote: > > So what it supports "more inputs"? > It does constitute an LSP violation. "more inputs" is not what the > guarantee is at all, if that is what you want you'd typehint on a > interface. > > > It is a LSP failure to allow a string, or any other scalar value, when > the parent requires a specific type/object. > > It sucks that we fail our arginfo very frequently, but this is the way it is > :] An interface requires only a minimum standard for accepted input. If a class implementing that interface allows a wider range of values, but still allows at least what the interface requires it to, it is not an LSP violation. Scalars are not special. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Scalar Type Hints v0.2
Hi Pascal, > On 5 Feb 2015, at 00:02, Pascal Chevrel wrote: > > I am probably going to ask a stupid question, but do we really need the =1 > part in declare? > > declare(strict_types=1) couldn't be declare(strict_types)? > > Or does it mean that there would be cases when strict typing would be > deactivated after being activated with declare(strict_types=0)? Oh, I made it like that because that’s the existing syntax of declare(), it takes a name and a value. But I suppose it could be modified to allow just a name. I don’t think we should modify it just for this specific case, really… less exceptions to a rule and more consistency are generally a good thing. There is a use for declare(strict_types=0), which is to make part of a file weak while having the rest strict. It’s not something you’d want to do very often, but it may be useful in some rare cases. If we have declare(strict_types=1), then it makes sense to also have declare(strict_types=0). It’d be rather odd to not allow it. > To be honest, I don't like declare() because it looks like a function call, > not a setting for the file like a namespace declaration would be. Also, in > the case of declare(ticks=1), 1 is not a boolean but an interval so I find it > a bit confusing that strict_types=1 would be a boolean in that case. Or maybe > declare(strict_types=true) then? I originally had it be a boolean, but considering how often this would be used, I changed it to 1 for terseness. Using 1 is common for INI settings, so I don’t think it’d be that confusing, but I see your point. > Personnally I would prefer a syntax like: > declare strict; > > which is just shorter and more readable in my opinion. I know it is mostly > cosmetic but I don't really understand why declare uses parenthesis if it is > a language construct and not a function (and yes, I think that > declare(ticks=1) also looks silly ;) ); > > So basically instead of that at the top of my files: > namespace Foo; > use Bar; > declare(strict_types=1); > > I would prefer having that: > namespace Foo; > use Bar; > declare strict; > > It's probably a detail in the whole discussion, but for some weird > psychological reason, it matters to me :), I can see the appeal, though I’m not really sure about adding new syntax just for this. By the way, I think declare() would be easily distinguished from a function for two reasons. Firstly, you can’t assign to constants, and secondly, it’ll be syntax-highlights differently. I can understand your concerns, though. :) Thanks for voicing them. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] hints and constraints
ently > being proposed, but I don't feel that is 'the PHP way' and some of the > flexibility PHP currently provides is actually constrined in a much more > practical manor than the current proposals. I hardly see the need for constraints in this case: we’ve had if() and throw for ages now, and they do this specific job perfectly well. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow dropping typehints during inheritance
Hi Julien,
> On 5 Feb 2015, at 12:10, Julien Pauli wrote:
>
> If we allow larger type, why doesn't such code work ?
>
> interface A { }
> interface B extends A { }
>
> class C {
> public function foo(A $a) { }
> }
>
> class D extends C {
> public function foo(B $a) { } // E_STRICT
> }
>
> This is wrong IMO.
Well, firstly that’s the wrong way round: inheriting classes can only
*increase* the range of supported values, but you’ve done exactly the opposite.
But even if you fixed your code, you’d still have an error. This ispresumably
because doing anything other than simple invariance causes enormous problems
related to compilation order and autoloading, as we discovered with the Return
Types RFC. I think that we’d probably support full contravariance for
parameters if we could.
However, we could easily support contravariance in type hint existence, as that
doesn’t require subclassing checks.
--
Andrea Faulds
http://ajf.me/
--
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?
Hi, > On 5 Feb 2015, at 06:52, Dmitry Stogov wrote: > > I completely agree. > Strict typing doesn't fit into PHP. It was already told thousand times. Seems to work rather well in practice, so long as it’s optional. > Also, the only really useful case for "strict typing" is the ability to catch > mistakes in user apps. > However, this ability is really limited. Implementing "Design by Contact" > approach may be much smarter. It’s not that limited. I caught two different bugs in my app simply by adding strict types. Strict typing, crucially, allows the catching of errors ahead of time, too. You can’t do that with weak typing, because it depends on the value, not the type. And you don’t know the value from reading the source code. -- Andrea Faulds http://ajf.me/ -- 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?
Hi François, > On 5 Feb 2015, at 08:58, François Laupretre wrote: > > +1. Checking IS_ at the C level after implicit conversions and checking > this at the PHP level are very different. > > IMHO, the key point is the concept of 'type'. Strict typing considers a > one-to-one correspondence between PHP types and zval types, which is > nonsense. At the PHP level, any value returning true through is_numeric() IS > a 'number', and it must remain so. Any such value with a null decimal part is > an 'integer' (not the result of 'is_int()') and so on. This simply isn’t how PHP works. PHP has a limited form of type juggling, but the types of values are not merely an implementation detail. There are numerous places where PHP completely violates the notion that these types don’t matter, such as comparisons, sorting, functions accepting multiple types, functions returning multiple types, bitwise operators and array indexing. All of these discriminate between types. To claim that types are merely an aspect of a zval is ignorance in the extreme. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Scalar Type Hints
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. I’d like to make sure that everyone voting understands the RFC fully. Please read the RFC in full: the details are important. And if anyone has any questions or uncertainties, please ask them before voting. I am very happy to answer them. I would urge everyone who wants type hints to vote for this RFC. It is not a perfect solution, but there can be no perfect solution to this issue. However, I think it is better than most of the alternatives suggested thus far - see the rationale section, and previous discussions. Crucially, this RFC would keep PHP a weakly-typed language, and not force either strict typing, nor weak typing, on anyone who does not want it. It would allow the addition of type hints to existing codebases. It would not create a situation where userland functions are strict yet internal functions are not, because the strict mode affects both. I’ve tested the implementation myself on my own code, and it worked well, providing benefits other proposals would not have given (see my previous post about my experiences). Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In addition to the vote on the main RFC, there is also a vote on the type aliases issue, and a vote to reserve the type names for future RFCs’ sake if this RFC fails. The RFC can be found here, and it contains a voting widget: https://wiki.php.net/rfc/scalar_type_hints Thank you for your time. -- Andrea Faulds http://ajf.me/ -- 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?
Hi, > On 5 Feb 2015, at 19:15, Dmitry Stogov wrote: > > "works" and "fits" are different. Fair point. > Strict type hinting may help catching problems only at run-time. > > In PHP you almost never can do something ahead of time, because of run-time > binding. > You may only guess, analyzing the whole projects and performing type > inference. This is true to an extent. However, there are still some things you can catch ahead-of-time. One of the things strict mode caught could’ve been noticed by a static analyser. The other probably wouldn’t have been. Strict typing tends to be better for catching errors ahead-of-time, and I think with return types it’ll get even better. Thanks for your input. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Andi, > On 5 Feb 2015, at 23:22, Andi Gutmans wrote: > > I have to say I’m pretty disappointed at the opening of the vote. > We had a pretty good RFC (thank you) for weak type hinting which was aligned > with the spirit of PHP and everyone was able to rally around it. This is far from true. Some people on internals were happy, but only some, and everywhere outside internals I looked, the reception was far more negative. > This has now been morphed into something very hard to swallow and IMO having > such a declare(…) syntax will be ridiculed by the broader app dev community > until the end of time… Nobody mocks Perl or JS for use strict. > But even that syntax aside (it’s only syntax after all), I think we lost the > ability to reach consensus on something so important to everyone which we > haven’t been able to come to agreement on for over 10 years. Finally it was > there, in reach and you made a 180 degree turn. “Consensus” is exaggerated. There was no consensus and to claim there was is to ignore the reality that the PHP community is divided over this issue. I’d love to say that everyone loves weak type hints and if that version had passed we’d all be dancing around happy holding hands, but the reception was not uniformly positive, not even close, and that’s just on internals. > I think it’d be so much easier for us to implement weak type hinting. Have > everyone rally around it. Be happy and then learn and see whether an > additional mechanism is really necessary. Who’d be happy? I realise you and Zeev are big fans of weak types, as are many others, but there are also a lot of PHP developers who vehemently disagree with you. > We could even add an E_STRICT_TYPES error_reporting flag to help folks > “debug” their code if they so wish to see if there are any hotspots in their > code they may want to take a look at - again not necessarily an error but > maybe a debugging tool. Global error handlers affect all code the interpreter runs, which is why we’ve looked down on them in recent times. > But net, net - why not just implement the thing everyone can agree on. Everyone doesn’t agree on it. If everyone did agree on it, v0.1 of the RFC would have been the one that went to vote. > Have something really good in the spirit of the PHP Language for PHP 7 and > learn how people leverage that… The reality is that for the majority of the > Web community “1” coming in from HTTP should be accepted as a 1. Period. It’s very well and good you claiming that the “majority” agree, but this does not match my experiences. The PHP community is not a single, homogenous entity. It is very difficult to judge. > I voted “no” but I will vote “yes” for the competing RFC which is 80% of your > RFC. Why are we not given that option?? Because I cannot in good conscience push through something in the name of “consensus” which does not even approach it. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Dan,
> On 5 Feb 2015, at 23:41, Dan Ackroyd wrote:
>
> As much as I want scalar types I'm voting no as:
>
> i) Having this code:
>
> function foo(int $numberOfRightTurns) {
>$x = $numberOfRightTurns * 90;
>return sin(deg2rad($x))
> }
>
> work or blow up depending on a setting at the top of the file is horrible.
From what I’ve seen this is a rather uncommon case.
Also, that code only works for some integer values and not others: the strict
version is uniformly broken, the weak version is sometimes broken.
> ii) Having the code that I write in userland behave differently
> depending on how people call it, is also horrible.
Your code always behaves identically.
> Additionally Andrea, I am disappointed that you opened voting without
> a option with the 'declare' stuff removed. This is despite myself
> having asked you for an vote option for just strict types directly
> several times. Other people have asked for a vote option that allows
> strict and weak types with a different syntax.
Yes, I realise you and others have asked for such things. I disagree with you
there and I don’t think adding strict types to PHP is really a good idea. I’d
prefer we have more rather than less consistency between userland and internals.
> I realise that the RFC as it stands is your preferred option, but just
> not accepting feedback during an RFC is not appropriate.
I have listened to feedback. But listening to feedback and agreeing to any and
all suggestions are not the same thing.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Andi, > On 5 Feb 2015, at 23:50, Andi Gutmans wrote: > > I am not sure. > > I think we need to explicitly vote on a weak type hinting option. > Andrea, I think this should be an option in any vote. Right now it feels like > the only option to people is the very challenging, non-consensus driving RFC > or nothing. > I think we have plenty of key folks who would support weak type hinting and > frankly, I think that would be a huge win for everyone! Yes, *you* think it’s a huge win for everyone. There are plenty who’d disagree. This RFC is a different attempt at consensus. Rather than asserting the dominance of one idea over the other and completely ignoring the segment of the community that believes in a particular approach, it allows using both approaches. It allows choice. It’s radical, sure, but I think trying to accommodate everyone’s use cases (or at least most people’s) is better than covering only one of two. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Andi, > On 5 Feb 2015, at 23:57, Andi Gutmans wrote: > > The folks who really want all this great strict typing should head over to > Oracle.com and download free open-source Java? I hear it's got a lot of > strict typing features in it. Only downside is that it'll take them 10x > longer to complete their projects. OK sorry. Had to say that :) I realize > it's not the same… I don’t think it’s terribly funny to tell a large portion of the PHP community to go away. > Andrea, while I don't agree with what you say I accept it. *But* exactly for > the reasons you state (the big divide) we should also have a weak type > hinting option to vote for in parallel. If you feel morally unable to do that > then I can copy your work and just have another RFC running in parallel but I > think that would do a disservice to the good work you've done. No, I don’t think that’s fair. I’d be against holding a vote on strict types only for the same reason: the community is divided. Letting one side “win" is simply unfair on everyone else. To quote myself in the Scalar Type Hints thread, here’s a rough tally of who was in favour of what in the v0.1 thread (I think “yourself” was Zeev in that context): > On 15 Jan 2015, at 14:51, Andrea Faulds wrote: > > Let’s have a look. From a quick skim over the thread for v0.1: > > * In favour of weak types (or the RFC anyway): Adam, Stas, yourself, Jordi, > Pierre, > * Against, in favour of strict types: Maxime, Nikita, Markus, Marco, Leigh, > Levi, Sven(?) > * In favour of strict types, not against weak types as compromise: Matthew > * Somewhat in favour: Sebastian > * In favour of allowing both approaches: Marcio, Thomas, Marco > > I apologise if I am misrepresenting anyone’s position. > > This is unlikely to be super-representative of the PHP community. However, > I’m not sure I’d say “overwhelmingly positive”. It can be easy to get > confirmation bias when reading RFC threads. > > It is very clear to me that a lot of people would like strict types, and some > people would like weak types. As to their relative numbers, I cannot say. > > I don’t think it’s really fair to cover only the use case of one half of the > PHP community. The other half counts too. This is a rather divisive issue. As is rather clear, there was no such consensus on internals. Confirmation bias can be a powerful thing, and it’s easy to forget that the number of messages doesn’t reflect the number of participants. The views on other places were, from my experience, even more against weak types than internals. Internals seems to be the most pro-weak types PHP community I’m a part of. Because of this schism, I really think it would be completely unfair to force through weak types. I know internals might like it (or some of internals, anyway), and I know you and Zeev certainly do, but it’s not as clear-cut in the wider community. This isn’t some minor issue, either: it’s a very frequently resurfacing topic, and one which is particularly divisive. It’s not some minor syntax issue that merely holding a vote will solve. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, > On 6 Feb 2015, at 00:24, Andi Gutmans wrote: > > Oh come on... You're taking me a bit too literally. Your proposal isn't > Java-like strict typing... I even said that. I still disagree with the sentiment, but never mind. I realise it was just a joke. >> No, I don’t think that’s fair. I’d be against holding a vote on strict >> types only for the same reason: the community is divided. Letting one side >> “win" is simply unfair on everyone else. > > I don't understand that statement. You mean it's not OK for any side to win > unless you win? Or are you saying that you tried to strike a balance > between the two parties which you hoped everyone could rally around? The latter. > What > if they can't? It's all or nothing? Btw, not trying to be facetious but > really trying to understand where you're coming from. I just don’t feel comfortable if only one camp is satisfied. It doesn’t seem fair. While first-past-the-post politics is “winner takes it all” (usually, anyway… but that’s way off topic), the design of the PHP programming language shouldn’t be. Compromise doesn’t lead to ideal solutions, sure, but it does lead to more people being happy than otherwise, if it’s a good compromise. >> To quote myself in the Scalar Type Hints thread, here’s a rough tally of >> who was in favour of what in the v0.1 thread (I think “yourself” was Zeev >> in that context): > > Zeev and I aren't twins (thank god for him) and aren't always in agreement > on such topics. Looks like I am not on that list. Don't see him either > btw… huh? Maybe you misunderstood me. I meant that in that list in the quote, the word “yourself” was referring to Zeev, since that’s who I was responding to in the original email (I think). I don’t think you were in that discussion - maybe you were and I missed you. > Anyway, I think I need to sleep on it... I understand what you're trying to > do. It's definitely not a crazy strict type hinting approach (which would > be very bad)... But I find elements of it challenging… I also have some gripes with this RFC - declare() isn’t the nicest of things to have to type on every file. But, I think it seems to work out better overall than all the numerous other proposals I’ve seen so far, and that’s why I like it. I also need sleep. Goodnight! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Pierre, > On 6 Feb 2015, at 00:50, Pierre Joye wrote: > > I have to agree here while I like the declare option, it should have > been an option as we clearly do not have a consensus during the > discussions (and will never have). Jeopardize the whole because of > that sounds dangerous to me. Three-way votes for this type of issue are rather nightmarish. Originally, this RFC was going to have at least three separate options in the vote, but I gave up on that because of the sheer complexity. Whatever result you’d get wouldn’t be very fair and the margins wouldn’t make sense. If someone wants to make a separate RFC later for strict types or weak types or whatever, nothing would stop them. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Pavel, > On 7 Feb 2015, at 10:57, Pavel Kouřil wrote: > > On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds 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. >> > > 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. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, > On 7 Feb 2015, at 20:47, Andrea Faulds wrote: > >> On 7 Feb 2015, at 10:57, Pavel Kouřil 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 Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, > On 7 Feb 2015, at 22:03, Pavel Kouřil wrote: > > On Sat, Feb 7, 2015 at 9:57 PM, Andrea Faulds wrote: >> Hi, >> >>> On 7 Feb 2015, at 20:47, Andrea Faulds wrote: >>> >>>> On 7 Feb 2015, at 10:57, Pavel Kouřil 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. 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. > 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. 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'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. I am familiar with other languages, I just disagree with their approach. > 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. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Rasmus,
> On 8 Feb 2015, at 02:38, Rasmus Lerdorf wrote:
>
> On 02/07/2015 05:03 PM, Pavel Kouřil wrote:
>> 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). :(
>
> I am not sure I would go that far. Andrea did plenty of research and has
> tons of experience in other languages, I just think this approach is
> misguided. I also wonder just how many people of those who voted even
> bothered to download and try the patch. I tried it a while back on some
> existing code and it was a nightmare. Does everyone realize that these
> simple things break?
>
> tan(1);
> echo strstr("test", "est", 1);
Banning int->float and float->int is both a pain point and sometimes a
life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you
discover if your ints floats would be silently truncated (as I did with
PictoSwap).
I wouldn’t say that int->string not working is a problem, though. Seeing
something like strstr(“test”, “est”, 1); is rather confusing. Looking at it,
I’d think the third parameter is some sort of number for you to want to pass an
integer to it. If I want a string, I’ll use one.
> Having absolutely no coercion for int to float and 0/1 to false/true,
> especially for internal functions, is just too pedantic to me. I also
> find this a bit hypocritical:
>
> declare(strict_types=true);
>
> outputs:
>
> Fatal error: strict_types declaration must have 0 or 1 as its value
>
> That is obviously nit-picking, but if we are going to get this pedantic…
Yes, that is a cruel irony that I did notice when I changed it. I sacrificed
strictness/“correctness” there for brevity. The reason you can’t use a boolean
is that I think it’s better if only two forms are allowed (=0 and =1) - less
forms to remember, less ambiguity.
> And, you also have to realize that it isn't actually per file. For
> example, this:
>
> function myErrorHandler($errno, $errstr, $errfile, $errline) {
> if ($errno===E_RECOVERABLE_ERROR) {
>echo "\ncatchable fatal error\n";
>return true;
> }
> return false;
> }
> set_error_handler('myErrorHandler');
>
> echo tan(1);
> declare(strict_types=1);
> echo tan(1);
> declare(strict_types=0);
> echo tan(1);
>
> This will output:
>
> 1.5574077246549
> catchable fatal error
> 1.5574077246549
>
> The RFC refers to it as a per-file directive, which just means it
> doesn't apply to files you include after setting it. It doesn't mean
> that the entire file is affected. You can flip in and out of strict mode
> at will. Which isn't necessarily a bad thing, but it can certainly get
> confusing.
Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one
sense (like encoding, but unlike ticks, it has no effect on the including or
included files). However, it technically affects the remainder of the file, not
the whole file.
> For example. Since everyone has already voted, you can all tell me what
> this does, right?
>
> 1)
> function do_something() {
> declare(strict_types=1);
> }
> echo tan(1);
> do_something();
> echo tan(1);
I don’t understand why it’s even allowed for the declare() statement to be used
like that (why is a compile-time option allowed to be within a function? That’s
a recipe for disaster), but that would make the first tan(1); error and halt
program execution.
> How about this:
>
> 2)
> echo tan(1);
> do_something();
> echo tan(1);
> function do_something() {
> declare(strict_types=1);
> }
First two calls succeed. Again, declare()’s behaviour is weird… makes me wonder
who thought it was a good idea to allow this.
> or this?
>
> 3)
> function do_something() {
> declare(strict_types=1);
> }
> echo tan(1);
> echo tan(1);
That would make the first tan(1); error and halt program execution.
> Answers:
>
> 1) fatal error on the first tan(1)
> 2) no errors
> 3) same as 1)
Hooray, I guessed right.
> Basically declare() does not respect function scope, but it doesn't let
> you know that. There is a reason we haven't used declare() for anything
> real.
I wonder if we should just remove this ability of declare(); or at least
produce some sort of warning (E_DEPRECATED? E_WARNING? E_STRICT?). It’s highly
misleading and I don’t really understand why it’s allowed.
Then again, that would cause problems for ticks, possibly?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi,
> On 8 Feb 2015, at 02:51, Andrea Faulds wrote:
>
> Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one
> sense (like encoding, but unlike ticks, it has no effect on the including or
> included files). However, it technically affects the remainder of the file,
> not the whole file.
A minor follow-up: the RFC does actually mention this specific point about
declare()’s behaviour:
> By default, all PHP files are in weak type-checking mode. A new declare()
> directive is added, strict_types, which takes either 1 or 0. If 1, strict
> type-checking mode is used for function calls and return statements in the
> remainder of the file. If 0, weak type-checking mode is used.
>
> This directive also supports the declare() block syntax (e.g.
> declare(strict_types=1) { foo(); }), in which case it will only affect
> function calls and return statements within the block.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi,
> On 8 Feb 2015, at 03:52, Rasmus Lerdorf wrote:
>
> On 02/07/2015 09:51 PM, Andrea Faulds wrote:
>>> tan(1);
>>> echo strstr("test", "est", 1);
>>
>> Banning int->float and float->int is both a pain point and sometimes a
>> life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you
>> discover if your ints floats would be silently truncated (as I did with
>> PictoSwap).
>>
>> I wouldn’t say that int->string not working is a problem, though. Seeing
>> something like strstr(“test”, “est”, 1); is rather confusing. Looking at it,
>> I’d think the third parameter is some sort of number for you to want to pass
>> an integer to it. If I want a string, I’ll use one.
>
> This isn't int->string. This is int->boolean. The 3rd arg to strstr() is
> a boolean and passing 1 instead of true makes it blow up. It is very
> very common for people to pass 0 or 1 in place of true/false to all
> sorts of things in PHP.
Oh, my bad, I looked up strtr and not strstr.
I’m not sure that disallowing implicit integer->boolean conversion is bad,
though. That conversion will discard all data except whether the value is
non-zero. If you opt in to strict typing, then you have chosen to always use
the correct types.
>
>> Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one
>> sense (like encoding, but unlike ticks, it has no effect on the including or
>> included files). However, it technically affects the remainder of the file,
>> not the whole file.
>
> Well, no, not the remainder of the file either since it can be switched
> again. It only affects the part of the file between declares if there is
> a second one.
Sure, that’s true, the option can be changed more than once.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserving primitive types
Hi Timm, > On 8 Feb 2015, at 12:04, Timm Friebe wrote: > > Hello everyone, > > I've been following the "Static type hints" discussion for a while now. Presumably you mean "scalar" not "static". > Aside > from its content, which there are some strong sentiments about, there's also > another recurring pattern - the wish for voting options instead of just > "yes/no". > > Along these lines I've created an RFC on one aspect of primitive type hinting > (whether parameters or return type), namely reserving the primitive type > names: > > https://wiki.php.net/rfc/reserve_primitives > > I personally see the benefits this could have but also the BC break this would > introduce. Let me know whether it's worthwhile putting this up for discussion. > I'm happy to add, elaborate or remove options as a result of feedback before > doing so. I don't see the point of this: the Scalar Type Hints RFC already has a voting option on reserving the type names, and it is set to pass, so by the time your RFC could go to a vote, it would have been rendered redundant. Thanks. -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] Reserving primitive types
Hi, > On 8 Feb 2015, at 13:32, Timm Friebe wrote: > >>> I personally see the benefits this could have but also the BC break this >>> would >>> introduce. > [...] >> I don't see the point of this: the Scalar Type Hints RFC already has a voting >> option on reserving the type names, and it is set to pass, so by the time >> your >> RFC could go to a vote, it would have been rendered redundant. > > My point is to prevent adoption hurdles *before* PHP 7's release. PHP 5 was a > sad story in regard to this. PHP 7 shouldn't be; and doesn't have to: So far, > PHP 7 has stayed largely BC-break free, which is good for its adoption. If this RFC would somehow pass, yes. However, you’re introducing a competing proposal at the “eleventh hour”, so to speak, which is terribly nice. Unless there’s a radical shift in how people vote on the Scalar Type Hints RFC, it won’t pass, anyway. > I believe more than just yes and no should be considered in this case, which > breaks existing code - not just in edge cases and in near-bug-scenarios. This has been discussed extensively in the Scalar Type Hints RFC thread, but people have voted to reserve the type names anyway. I appreciate your concerns, but introducing a competing RFC *while its competitor is in voting* is both poor sportsmanship, and quite probably futile. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserving primitive types
> On 8 Feb 2015, at 15:48, Andrea Faulds wrote: > > If this RFC would somehow pass, yes. However, you’re introducing a competing > proposal at the “eleventh hour”, so to speak, which is terribly nice. Unless > there’s a radical shift in how people vote on the Scalar Type Hints RFC, it > won’t pass, anyway. Sorry, I meant “isn’t terribly nice”. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Syntactical change to Scalar Type Hints RFC
Hi, I’m posting this in a new thread since people might (reasonably) be ignoring further responses to the [VOTE] thread. I’m considering a small change to the Scalar Type Hints RFC, specifically about syntax. Quite a few people have said they don’t like the declare() syntax, and it’s easy to see why. It’s rather verbose, it has all the quirks of declare() (such as block syntax, not respecting scope), and it’s rather ugly. Instead, I’m wondering if the following might be better: http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Zeev, > On 8 Feb 2015, at 19:48, Zeev Suraski wrote: > > Last, voters should take into account that this isn't an 'either this RFC or > nothing' situation. I think it's very unfortunate that the original RFC - > that had zero controversy surrounding it - was never put to a vote. Please stop repeating this, it is blatantly false and I’ve pointed this out several times. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
Hi François,
On 8 Feb 2015, at 20:43, François Laupretre wrote:
>> De : Andrea Faulds [mailto:a...@ajf.me]
>> Instead, I’m wondering if the following might be better:
>>
>>>
>> Which would be used like so:
>>
>>>
>>function foobar(): int {
>>return 1.0; // error!
>>}
>>
>> It’d be a per-file directive, so there’d be zero mixing of modes within one
>> file, and you’d avoid the quirks of declare().
>
> ' not always the first item in a file.
>
> What would this mean :
>
> Lines of data
> ...
> php code
> ?>
> Data
> Code
> ...
>
> Would it be strict or not ? or will you interpret the first ' What is the syntax exactly ? Does it make 'strict' a reserved keyword ?
It doesn't make "strict" be reserved.
With regards to multiple blocks, there are a few possible approaches:
* First block affects subsequent blocks, only it can declare strictness (my
favourite)
* Per-block
* Use of directive prevents use of end tags, and thus use of multiple blocks
I think the first makes the most sense. It's what namespaces do, after all.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 artifact - binary strings
Hi, > On 8 Feb 2015, at 20:10, Marc Bennewitz wrote: > > Since PHP-5.2.1 we have an artifact of PHP-6 in the engine means we can > define binary strings but such definitions haven't any effect. Yes. That’s because PHP 6 was going to have Unicode strings by default, alongside binary strings (to PHP 5 and 7, just “strings”). These “binary strings” are just strings. > So what we can define is the following: > > $str = "str"; > $bin = b"b\0i\0n"; > $str2bin = (binary)$str; > > One of the biggest issue is that currently ALL strings will be handled as > ASCII-7 compatible strings on type-juggling but they aren’t. In the rare case you need to prevent type juggling of binary data, you could wrap it in an object. > It would be very appreciated if PHP could respect such binary declaration: > > * use binary string comparison on compare a binary string to any other string > * don't convert binary strings into integers on array keys > * allow bitwise operators on binary strings without casting to integer This would break existing code which was made “PHP 6-ready”. Also, we already support bitwise operations on strings, I don’t know what you’re on about there... -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 artifact - binary strings
Hi, > On 8 Feb 2015, at 21:48, Marc Bennewitz wrote: > > Wrapping all in objects isn't an option. This would only add unnecessary > overhead and only move the issue to a different place. I don’t see why not. Objects are generally exempt from type juggling, except for conversion to strings. Surely that’s what you want? >> This would break existing code which was made “PHP 6-ready”. > I don't think so. If a string was declared as binary it should be binary else > it is a wrong declaration and a bug. It already is binary, though. PHP’s strings are binary, they always have been. The reason that we have (binary) is because PHP 6 was going to make (string) a synonym of (unicode) instead. >> Also, we already support bitwise operations on strings, I don’t know what >> you’re on about there... > > Sorry I wasn't clear. > I mean the bitwise shift operators see http://3v4l.org/MBadR That would be a BC break, and the kind of non-obvious evil one Derick doesn’t like much. Though I can’t talk: I already ‘broke’ bitwise shifts with the Integer Semantics RFC. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Ferenc, > On 8 Feb 2015, at 22:18, Ferenc Kovacs wrote: > > I've voted no for two reasons: > 1, I don't really like the the proposed declare solution, I know that you put > much thought and effort with finding a way to make the strict hints opt-in > for the caller, but I think it is still not a good compromise: people in > favor of strict hints will hate it because it is opt-in from the caller, so > they can't use scalar hints to save the boilerplate for argument validation Hmm. Personally, I don’t think types are really a substitute for argument validation. This doesn’t provide a means to force strict types upon people who don’t want them, sure… but the proposal is designed precisely to prevent that, since I don’t see someone like Zeev (say) wanting to deal with strict types any time soon. > , and other people like me will unlike it because they think that the > blockless declare will cause many errors and debugging headache when somebody > moves some code between files (or concatenating files as part of their > deployment process). It’s worth noting that I intend to change this to have the “ 2, As this is a really polarizing topic I would like if the eventual solution > would have wider support from the current php-src regular contributors, and > not just pushed through by "force". (And I know that status quo sucks when > somebody trying to do innovative stuff, but it is a safe thing to default to). I’m not sure. There are some people completely opposed to compromise, that can’t be helped. For everyone else, I’m not sure how I feel about contentious votes. If it gets through by a 2/3 majority then presumably it does have significant support, though I worry about lasting impact. Votes do, at least, provide a way to resolve contentious issues, though. > Thanks for your efforts on such a hard topic and I hope you can eventually > succeed where everyone else failed thus far! Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, > On 8 Feb 2015, at 23:03, Stanislav Malyshev wrote: > >>> Last, voters should take into account that this isn't an 'either this RFC or >>> nothing' situation. I think it's very unfortunate that the original RFC - >>> that had zero controversy surrounding it - was never put to a vote. >> >> Please stop repeating this, it is blatantly false and I’ve pointed this out >> several times. > > How is it false? Did we have a vote on v1? What was the result of the vote? No, we didn’t. But the statement “zero controversy” implies that, well… let’s look up what controversy means: > argument that involves many people who strongly disagree about something : > strong disagreement about something among a large group of people (Merriam-Webster) So, controversy is where a lot of people disagree - and there were numerous people in the original thread who disagreed with the RFC and preferred strict types. I actually tallied them in a reply to Zeev (which I later quoted in a reply to Andi). There were almost as many people against the proposal as in favour. This is to say nothing as to how it was received outside internals which, from my experience on reddit, Twitter and StackOverflow, was even less positive than internals, considerably so. So, I think that to say that there was “zero controversy” is certainly stretching the truth. Really, I’m yet to see any scalar type hinting discussions which haven’t had some controversy. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Zeev, > On 8 Feb 2015, at 23:24, Zeev Suraski wrote: > > It's not stretching the truth or even slightly bending it, considering the > RFC currently being voted on is a superset of that RFC. That has no relevancy. > There's zero or virtually zero controversy surrounding the weak typing RFC, > the one that was v0.1. The controversy wasn't (and isn't) about what was in > v0.1, but rather, about what wasn't in there, namely, strict typing; So, then, there was controversy around that RFC. > The way it should have went is voting on the weak typing RFC, around which > there was (and probably still is) almost consensus. Again, there was not consensus. The RFC was controversial, especially outside of internals, but even on internals around half the people who responded *were not positive*. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactical change to Scalar Type Hints RFC
Hi,
> On 8 Feb 2015, at 23:22, Rowan Collins wrote:
>
> On 08/02/2015 19:44, Andrea Faulds wrote:
>> Hi,
>>
>> I’m posting this in a new thread since people might (reasonably) be ignoring
>> further responses to the [VOTE] thread.
>
> Incidentally, you still used "reply" to create this message, so mail readers
> which base threads on headers (e.g. Thunderbird) rather than subject lines
> (e.g. GMail) still see it as part of the same thread (though the subject line
> change makes it stand out, so I spotted it anyway).
Oh yeah, my bad. :/
>
>> I’m considering a small change to the Scalar Type Hints RFC, specifically
>> about syntax. Quite a few people have said they don’t like the declare()
>> syntax, and it’s easy to see why. It’s rather verbose, it has all the quirks
>> of declare() (such as block syntax, not respecting scope), and it’s rather
>> ugly.
>>
>> Instead, I’m wondering if the following might be better:
>>
>> >
>> Which would be used like so:
>>
>> >
>> function foobar(): int {
>> return 1.0; // error!
>> }
>>
>> It’d be a per-file directive, so there’d be zero mixing of modes within one
>> file, and you’d avoid the quirks of declare().
>
> I find this much, much uglier than declare().
>
> Firstly, it seems to be creating a whole new syntax convention, which will
> need its own rules - Can it be preceded by a newline or other whitespace?
> Must it be followed by a newline (unlike a normal " enable strict typing in a short tag using " ?>”?
Secondly, it is less specific than the current proposal - it suggests that
> PHP has a generic "strict mode", rather than a "strict type-checking" mode.
It could be renamed to strict_types, but that loses some elegant.
> Would more "strict" features be added to this mode later?
No.
> Or would other keywords be added so that you could, ahem, "declare" several
> directives at the top of your block?
No.
> Thirdly, it has all the same scoping issues as declare() - you can break a
> function up into multiple blocks, so it's still possible to
> switch it halfway through a declaration,
I’ve already sent an email in this thread about possible approaches to handling
multiple blocks. My preferred solution would not allow what you describe, and
instead behave like namespaces (must be in first block, affects entire file).
> If this magic token has the extra effect of causing ?> to be ignored, that's
> a fairly major and unrelated feature, which would probably need its own RFC.
?> isn’t ignored - PHP blocks aren’t, and never have, been considered the same
as separate files.
> If you make the first " was never a consideration before.
This is technically correct, but only if that first block is empty. The
following is an error:
Test
It's not like non-block namespace declarations having to be at the top of the
> file, because that is still a separate statement, it just has to be the
> *first* statement; whereas this appears to be designed to merge with the
> non-statement opening tag.
Is there really an important difference between first statement, and first
opening tag? The main difference in behaviour is empty blocks.
> If you're going to go that far, why not just disallow the block-level syntax
> of declare() for this case, if that is the complaint? Or if the problem is
> the non-block syntax, why not enforce that a non-block declare(strict_types)
> be at the top of the file?
Well, it’s not just that which is the problem: declare() is rather verbose and
ugly. Also, having it behave differently from all other declare() statements
would bring into question why we even bother reusing the declare() syntax.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, > On 9 Feb 2015, at 08:04, Dmitry Stogov 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. Oddly, nobody seems to complain that it's unfair if I side with the weak typing camp, despite that being equally unfair. > Despite of semantic arguments, the implementation is a bit immature and > introduces slowdown for any code without type hints. The implementation could do with improvement, this is true. However I suspect any slowdown is minor at best, and this could be dealt with in future. The RFC is more about the language change than the implementation. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, > On 9 Feb 2015, at 03:48, Zeev Suraski wrote: > > A - has pretty much everybody agreeing with is a good idea. Nobody objects > to it. It's under consensus. This isn't true. I've explained why it isn't true several times. Maybe you are suffering from confirmation bias or something, but there is no such "consensus". Quite a few internals contributors liked v0.1. Quite a few didn't. I've gone and evidenced this before in replies sent directly to you. In addition, the reaction from the wider community was largely negative. > B - has a large number of people thinking it's alien to PHP, and has many > people objecting to it. B also has a large number of supporters because it is a pragmatic compromise. A also had a large number of detractors. > The vote is on A+B. No it isn't. You are claiming, as I understand it, that: * Weak typing has consensus (it doesn't) * Strict typing is entirely controversial (it has many supporters, however) * This proposal including both somehow nullifies the argument that weak typing lacks consensus (it doesn't - someone is free to oppose the addition of something in isolation yet support its addition in combination) The truth of the matter is this. There are at least two approaches to scalar type hint behaviour: weak and strict. Both are highly controversial. The addition of either exclusively, is controversial. The addition of both together, is controversial. The addition of "stricter" weak typing, is controversial. The issue of scalar type hints is highly controversial in general for these reasons. There is no consensus whatsoever. To suggest there is would be to grossly exaggerate. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Zeev, > On 9 Feb 2015, at 17:03, Zeev Suraski wrote: > > I'll make an absolute last attempt to explain what I'm saying, after that > we can agree to disagree. We probably interpret the same facts > differently. > > Fact is, there were very few people who said that weak types are *bad* > (although Sebastian seems to fall in that category). The vast majority of > feedback that 'opposed' weak typing, didn't really oppose weak typing at > all. What it opposed was, rather, the lack of introducing strict typing. > That is clearly not the same thing, which is why the fact there were > people who opposed v0.1 of the RFC does not equate with people opposing > weak typing, not at all. > > Each and every person that voted in favor of the v0.3 RFC, voted in favor > of weak typing. Weak typing is not only a key element of that RFC - it's > even the default behavior. In addition to everyone who voted in favor of > the v0.3 RFC, many - most probably most of the people who voted against > it- are in favor of the weak typing API. If you combine the two groups, > you're going to get to nearly 100% support, or arguably, 'lack of > opposition', to the weak typing proposal. First off, it’s really unfair to claim that merely because someone votes for this RFC, that they are okay with weak typing. It’s a compromise proposal: I’m not a big fan of weak typing, not by any means, and plenty of other people aren’t either, but this RFC allows me to use strict typing and others to use weak typing, without us getting in each other’s way. So, I am in favour of this RFC. I *do not like* weak typing. But I am willing to vote for and push for this RFC, if it means we’ll get scalar types somehow (and, crucially, it allows *strict* scalar types). People who are in favour of this RFC are *not* necessarily in favour of weak types, or adding weak types on their own. Anyway, to the main point. I’m pretty sure that you’re wrong in saying that the vast majority of the people who opposed the introduction of weak scalar types, and *only* weak scalar types in the v0.1 RFC, were actually okay with weak typing. That does not go with my experiences at all. From what I have seen, a large number of people are opposed to weakly-typed parameters, period. But let’s assume that you’re correct for a moment. Let’s say that, hypothetically, 100% of the people in the v0.1 thread (absolute consensus, then) had no opposition to the idea of weak typing, and the only complaint anyone had was that strict typing wasn’t also being added. This doesn’t help your case. In fact, it hurts it. Firstly, while there may be this hypothetical consensus around weak types, the v0.1 RFC showed there was definitely NOT consensus around adding weak types *on their own*. Yet that was what you are arguing: that their would be consensus, or is consensus, around just adding weak types. So, merely adding weak types, and not strict types, is not something there’s a consensus on, and is not something everyone can agree on, despite what you have been arguing. Secondly, you are saying that the only opposition to v0.1 was that it did not also introduce strict types. So, therefore, this new version of the RFC which introduces strict typing alongside weak typing, should surely be more popular, no? I do not understand your logic. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Guilherme, > On 9 Feb 2015, at 18:12, guilhermebla...@gmail.com wrote: > > I read again and again the RFC and I just decided to switch my vote. > Originally a "YES" voter, I'm now a "NO" voter. I still want strict types > to exist in PHP, and not only at the end-user level, but also at the > internals level (I can see so many optimizations around...). > However, I think it's not an INI setting or a per file operation. I > consider it should be (at the current PHP's pace) a heavily flexible > support. I tend to agree that if you put "string" in its definition, you > don't want a weak type, but strict type, the same way when you put MyClass > instead of nothing. > > That's why I don't agree with the declare or "use strict" or If I say "string $foo", I want a string, not a converted value. By > accepting this fact, makes easier in the future to make OO primitive types > if we wish, and also makes everything easier for everyone... if you have > foo(string $name), you expect strict type... if you want weak type, > foo($name). All code will work as is today, no BC breaks. > > That's my 2 cents... now time to update my vote in RFC. I can understand that viewpoint, but it’s not terribly kind on your users. You’re basically saying that you want to force people who’d prefer weak typing to use strict typing if they use your API. It’s doing this which this RFC is designed to prevent. I don’t think allowing people to force their way on their users is a good way to deal with the lack of weak or strict consensus in the community, no matter whether it’s nice for API design or not. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, > On 9 Feb 2015, at 18:22, Lars Strojny wrote: > >> On 07 Feb 2015, at 12:46, Matteo Beccati wrote: >> >> Maybe it's just me, but I didn't quite understand the point you are making >> here. Are you saying that declares are more or less like ini settings? > > Yes, exactly that. The new declare()-statement will fundamentally change how > the engine behaves It’s a relatively minor change. It changes how arguments and return values are type-checked, that’s all. The patch isn’t that complex. > and one will have two learn more or less two flavors of PHP. Hardly, the differences are not that big. One’s slightly stricter when checking arguments and return values, but that’s it. It’s not two completely different worlds, it’s a minor detail of personal preference. > Even worse I am forced to use the PHP flavor the person picked who changed > the declare() statement last. Well, yes, in a project with multiple people, you must conform to the project style guide and such, that’s hardly unusual. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can we remove "NEWS" tag ?
Hi, > On 11 Feb 2015, at 09:52, Lior Kaplan wrote: > > Hi, > > I've been doing some editing to the NEWS files, and keep getting this > problem > > $ git diff NEWS > fatal: ambiguous argument 'NEWS': both revision and filename > Use '--' to separate filenames from revisions > > Although I can do as it suggests, I would prefer to remove the NEWS tag we > have since 2008 as part of the move from CVS to SVN. > > Any objections ? > > Kaplan I swear this has come up before. Please, remove or rename it, I don't see anyone objecting. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Rasmus,
> On 11 Feb 2015, at 06:36, Rasmus Lerdorf wrote:
>
> 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
Such classes will unfortunately have to be renamed. However, this is only true
if the code needs to run on PHP 7. For PHP 5 codebase compatibility, Drupal can
do this:
class StringHelper {
…
}
if (version_compare(phpversion(), “7.0") < 0) {
class_alias(“Drupal\\Component\\Utility\\StringHelper”,
“Drupal\\Component\\Utility\\String”);
}
This way, only code made “PHP 7-ready" will have to replace its references to
String with, say, StringHelper. Drupal can work on both PHP 5 and PHP 7, but
codebases using it can migrate at their own pace.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Pavel, > On 11 Feb 2015, at 07:41, Pavel Kouřil wrote: > > 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. :( You can’t do it with weak types either. Functions with multiple return type usually do so in order to use one type for success, and another return type on failure. In weak typing mode, PHP would just mangle the error value (like FALSE). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
> On 11 Feb 2015, at 21:30, Zeev Suraski wrote: > >> -Original Message- >> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] >> Sent: Wednesday, February 11, 2015 8:37 AM >> To: Xinchen Hui; Andrea Faulds >> Cc: PHP Internals >> Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints >> >> 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. > > There's also some pretty interesting analysis on this proposal - based on > some real world experimentation - from Benjamin Eberlei - bit.ly/1vl0UED I disagree with some aspects of the blogpost: > enabling strict mode completly defeats the purpose, because now we are forced > to convert manually, reimplementing weak type hinting in our own code This isn’t true at all. The key difference between explicit conversions and implicit conversions is that they’re, well, *explicit*. You can see them, they are blatantly obvious, if you use grep you can find them. Implicit conversions, while they can sometimes be great, happen silently and automatically - if they screw up, it can be hard to track down where the conversion is taking place. With explicit conversions, you’re converting once and you know you’ve converted. With implicit conversions, you have no idea where and how often values are being converted. > We write code with casts already, the scalar type hints patch is not > necessary for that! Only a superficial level of additional safety is gained, > one additional check of something we already know is true! Yet in the previous part he was explaining how existing code doesn’t use casts and would need them added… so therefore, this thing *isn’t* already known to be true, and the blogpost is self-contradictory. > strict mode is useless for library developers, because I always have to > assume weak mode anyways. I don’t really understand at all… either he doesn’t understand the proposal (which guarantees you get the types you ask for), or it’s a reference to the claim from the previous paragraph, which I’ve already responded to. > In a well designed application or library, the developer can already trust > the types of his variables today, 95% of the time, without even having type > hints, using carefully designed abstractions (example Symfony Forms and > Doctrine ORM): No substantial win for her from having strict type hints. Yet he was previously explaining how, actually, data coming in from web requests isn’t the correct types. > In a badly designed application, the developer is uncertain about the types > of variables. Using strict mode in this scenario she needs to start casting > everywhere just to be sure. In an application using strict mode everywhere with scalar type hints everywhere, you can’t possibly be uncertain about the types of variables. … there’s a lot more in that blog post I could disagree with, but I won’t bother. Benjamin has his reasons for not liking strict mode. That’s fine. But if PHP adds strict mode, it has zero effect on him. > If you've voted on this RFC or intend to vote - please spend the few minutes > to read through his blog post. It does a good job at actually illustrating > what life would look like if this rubber ends up meeting the road. Anthony Ferrara also had his own analysis which showed some of the problems with weak type hinting, and where strict types can be beneficial: http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html I would suggest people read that blog post before voting, as well. It points out some real-world examples of where weak typing in PHP can be insufficient (div), or even downright dangerous (curlopt). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hey Guilherme, > On 11 Feb 2015, at 22:46, guilhermebla...@gmail.com wrote: > > @Andrea: I spent around 2-3 hours speaking with Anthony and the other half > talking to Jordi (Composer, Symfony). > I still think a few things are required to be fully usable. > 1- Exceptions RFC (outside of your scope, but making the code under strict > type impossible to recover in a library) Yeah, I agree that this is quite important. This could actually be fixed without exceptions (make type hint error skip the function call?), but they’re a nicer way to do it (possibly simpler within the engine?). > 2- Lack of numeric scalar type > There're others, but these ones are keys to make them fully usable. A number (or numeric, or num, or some other name) type hint is something I plan to propose in a future, follow-up RFC. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, > On 12 Feb 2015, at 07:05, Pavel Kouřil wrote: > > On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds 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. >> > > 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? 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. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate properties using var
Hi Pierre, > On 12 Feb 2015, at 11:51, Pierre du Plessis wrote: > > Before I create an RFC, I just want to get some feedback on a proposal, to > deprecated the use of "var" when declaring properties on a class. > > This was previously deprecated in PHP 5.0.0 and the deprecation notice was > removed in PHP 5.1.3. > > My proposal is to deprecate the use of var on properties in PHP 7, and then > remove support for it in PHP 8. This compliments the [0] "Remove PHP 4 > Constructors" RFC, as it is old PHP 4 behaviour, and according to the docs > is only "supported for compatibility reasons", and personally I think users > should be encourage to use proper visibility when defining properties. What’s the benefit here? It seems like a needless backwards-compatibility break. PHP 4 constructors have been proposed to be removed because they cause problems (Filter::filter) and it simplifies the language. What problems does var cause? Its existence doesn’t seem to hurt anyone - sure, using public/protected/private is better, but this only matters if you’re reading legacy code. I’d also be wary of removing it if we’re going to get rid of T_VAR, as that seems like a useful keyword we might reuse later. So I don’t see why we need to remove this. It’s also worth noting that removing PHP 4 constructors is unlikely to go ahead. I think Levi is planning to simply deprecate them instead, since it solves the main problem (Filter::filter broken) without breaking BC. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Pavel,
> On 12 Feb 2015, at 12:39, Pavel Kouřil wrote:
>
> 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.
C# also doesn’t have dynamic typing. Plus, adding overloading to an existing
language is more difficult.
> 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.
> 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.
> 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.
> 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.
> 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”.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi Pavel, > On 12 Feb 2015, at 13:48, Pavel Kouřil 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 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. > 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. > 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. :( Could you give an example use-case? > 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. 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. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hey Robert,
> On 12 Feb 2015, at 16:15, Robert Stoll wrote:
>
> 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.
Interesting, I should maybe look into those. I’m not sure if all of those are
really… “dynamic” as such. Are you sure the overloading you’re referring to
there isn’t pattern-matching?
> 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):
>
> I want to write a Logger-Service which provides one public method "log" which
> writes all kind of objects to a log. The corresponding classes do not all
> belong to my code base, are part of third party libraries respectively, so I
> am not able to introduce some interface which all classes implement. The
> strategy pattern is certainly a good idea for this problem but nevertheless,
> somewhere I need to have the distinction based on many if/else with
> instanceof (latest in the LoggerStrategyFactory) -- off topic, if someone has
> a better design approach to handle this problem, then let me know it in a
> private message, would be interesting as well ;)
>
> class Logger{
> public function log($x){
>if($x instanceof Foo){
> logFoo($x);
>}else if($x instanceof Bar){
> logBar($x);
>}
>//...
>}else{
> throw new Exception("type ".gettype($x)." not supported");
>}
> }
> private function logFoo(Foo $f){
>//..
> }
> private function logBar(Bar $b){
> //..
> }
> //...
> }
>
> With method overloading I could write the following, removing the hassle to
> write the dynamic dispatch myself:
>
> class Logger{
> public log(){
>$this->_log($x);
> }
> private function _log(Foo $f){
>//..
> }
> private function _log(Bar $b){
> //..
> }
> //...
> private function _log($x){
>throw new Exception("type ".gettype($x)." not supported");
> }
> }
>
> Which is cleaner IMO.
We could also add some sort of pattern-matching syntax which could do the same
thing, but would have usefulness beyond merely dispatching to multiple methods.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, > On 13 Feb 2015, at 09:37, Patrick ALLAERT wrote: > > Voted "no" because of the reasons already mentioned by a bunch of others here. > > Weak type hint as presented earlier: +1 (and very good job Andrea about > that!). > declare(strict_types=1): -1, not only about the syntax, but also about the > mixed mode it introduces. > > I'm pretty confident that this RFC will "pass" with just above 2/3 of > majority while it could reach much more. > > I am pretty sure that if this RFC doesn't include a strict type mode _the > way it is proposed_ (or even, not at all, as part of another related RFC), it > would have some "no" converted to "yes" and would have a wider adoption, > which is for sure a better option than relying on a voting mechanism which > still is a supporting tool, we're not politicians after all :) It wouldn’t have wider adoption. Excluding a large portion of the PHP community (which favours strict types) and giving them something which doesn’t work for their use cases (weak types) is not going to win any fans. > Andi's suggestion about an E_STRICT_TYPES sounds very reasonable and much > more in line with how PHP deals with "errors”. I don’t think E_STRICT_TYPES is a good idea. Global error handlers are, well, global. They not only affect your own code, but everything within the request, including libraries you use. So you can use them (and break every library you use), or not use them (and now it’s useless). What this RFC does is let individual files choose one mode or the other. This is far better for interoperability. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic
Hey, > On 13 Feb 2015, at 07:28, Michael Wallner wrote: > > On 12/02/15 19:55, Thomas Punt wrote: > >> I'd like to propose to make empty() a variadic, where if any >> arguments passed in are considered empty, then false is returned > > Should that read "if any arguments passed in are considered *NOT* empty, > then false is returned”? No, I think it’s correct, if confusingly phrased. I believe Thomas is proposing variadic empty() where TRUE is returned if any of its arguments are empty, otherwise FALSE. So, empty($a, $b, $c) would be equivalent to empty($a) || empty($b) || empty($c), much like isset($a, $b, $c) is equivalent to (and implemented as) isset($a) && isset($b) && isset($c). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic
> On 13 Feb 2015, at 11:16, Andrea Faulds wrote: > > Hey, > >> On 13 Feb 2015, at 07:28, Michael Wallner wrote: >> >> On 12/02/15 19:55, Thomas Punt wrote: >> >>> I'd like to propose to make empty() a variadic, where if any >>> arguments passed in are considered empty, then false is returned >> >> Should that read "if any arguments passed in are considered *NOT* empty, >> then false is returned”? > > No, I think it’s correct, if confusingly phrased. I believe Thomas is > proposing variadic empty() where TRUE is returned if any of its arguments are > empty, otherwise FALSE. So, empty($a, $b, $c) would be equivalent to > empty($a) || empty($b) || empty($c), much like isset($a, $b, $c) is > equivalent to (and implemented as) isset($a) && isset($b) && isset($c). Wait, I think I made a mistake. * Thomas proposed "if any arguments passed in are considered empty, then false is returned”, i.e. !(empty($a) || empty($b) || empty($c)) if his words are taken literally. This doesn’t make much sense, I think it was a mistake. * You suggested he may have meant "if any arguments passed in are considered *NOT* empty, then false is returned”, i.e. (empty($a) && empty($b) && empty($c)) * I assume Thomas actually meant “where if any arguments passed in are considered empty, then *true* is returned”, i.e. (empty($a) || empty($b) || empty($c)) Sorry for the confusion. I think the || behaviour is the most useful, as it’s the analogue of isset’s. So !empty($a, $b, $c) would work similarly to isset($a, $b, $c), and similarly, !isset($a, $b, $c) would work similarly to empty($a, $b, $c). But that’s just my opinion. :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Group Use Declarations
Hey,
> On 13 Feb 2015, at 16:24, Nikita Popov wrote:
>
> I'm in favor of this RFC. Honestly I don't really understand the negativity
> it is getting around here.
>
> The ability to import multiple items from one namespace is a
> well-established feature you'll find in many languages employing some kind
> of namespacing. I don't think the availability of what I lovingly call "IDE
> vomit" is a good reason to decline a feature - a programming language
> should be able stand on its own and not require IDE assistance for
> reasonable use.
>
> The syntax seems pretty obvious as well - but maybe I just had too much
> exposure to Rust, which makes extensive use of the same syntax.
My thoughts echo Nikita’s.
I think this feature would be especially important if PHP gets function
autoloading (which it may yet gain in PHP 7 - a certain someone has been
working on it). Currently, sets of independent functions have to be implemented
as static classes. But with function autoloading, they’d have to be imported
independently, and that would lead to way too many use statements.
This feature is familiar to people who have used other languages, as Nikita
mentioned. In Python, I might do this:
from somelibrary.math import sin, cos, tan, degrees, radians
Simple, uncumbersome, readable.
The equivalent in PHP is this:
use function SomeLibrary\Math\sin;
use function SomeLibrary\Math\cos;
use function SomeLibrary\Math\tan;
use function SomeLibrary\Math\degrees;
use function SomeLibrary\Math\radius;
Ouch. Not fun to type, not fun to read, takes up way more space than it should.
This is just a modest five functions, too - in many cases you’d be importing
more.
But with Marcio’s proposal, we could instead write this:
use function SomeLibrary\Math\{sin, cos, tan, degrees, radius};
Much better, no? I know which one I’d rather read and write.
It’d be a real shame if this doesn’t pass.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi, > On 13 Feb 2015, at 16:18, Benjamin Eberlei wrote: > > Wait i almost forgot, it *does* have an effect on me, especially around > callback handling: > > https://gist.github.com/schmittjoh/778e044deacc6f1fe516 > > Essentially callbacks are evaluated in the mode they are called in, not in > the one they are defined. This is correct, yes. This is only going to cause a problem, however, if: * You add type hints despite not knowing what types will be passed * You add type hints for the wrong types In both cases, you have only yourself to blame for your code not working. So, I really don’t think it’s an issue. If you don’t know what types will be passed, why did you add type hints? If you know what types will be passed and added incorrect type hints, why did you expect that to always work? There is of course a third case: the function’s documentation lies and claims the function will call your callback with certain types, and actually passes different types. However, this is not a problem with the RFC, and is something that could happen anyway. At least with this RFC, you might discover the bug in the library more quickly due to getting an error. Anyhow, we could catch such errors prior to call-time by extending the callable typehint to take a parameter list, such that parameter type hints can be checked (with the same rules as used by inheritance). This would solve your problem. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE] Group Use Declarations
> On 13 Feb 2015, at 17:18, Lester Caine wrote:
>
> On 13/02/15 16:41, Andrea Faulds wrote:
>> But with Marcio’s proposal, we could instead write this:
>>
>>use function SomeLibrary\Math\{sin, cos, tan, degrees, radius};
>
> Well it used to be simply ...
>
> require SomeLibrary\math.php;
I can’t say I miss the days of putting everything in the global namespace.
Makes it impossible to use two libraries with conflicting function names.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
d the ARG_INFO mechanism to allow > internal function developers to set type hinting in a similar way to > userspace type hinting (just optimizing values for performance). The return > type hint should be set there too. Anyway, if we want reflection to provide > this information for internal functions, the only way is to add it to the > ARG_INFO information (we could then provide a way to generate the function > prototype from this info). That's a big work but I don't see another way to > be consistent. There’s already a mechanism for this, I believe. I don’t think it is widely used, however. > - The following weak conversions : (bool -> float), (bool -> string), and > (string -> bool) are not much more natural than (array -> scalar), or > (resource -> int), which are forbidden. While it is natural in a C-like world > to consider any non-null number as true, I don't see why we should allow > sending a bool to a function expecting a float, even in weak mode. I would > consider this as a bug, but there may be use cases I'm not aware of. Note > that BC is not an argument here, as weak mode already modifies the way > arguments are handled (by refusing arrays, resources, and null for scalars), > so we are free to restrict it a little more if it makes sense. No, BC is an argument: the RFC tries to keep weak userland hints as close to zpp as possible. The only difference is in NULL handling, and I’d like to keep it that way. If the behaviour is to be changed, zpp should be too. > - I didn't see anything saying if you check the return type in weak mode. It does check it in weak mode, but the wording might have been a little unclear. Sorry about that. > - Do you plan a way to define the return type of arguments passed by > reference, or do you assume that input and output types must be the same ? > Even if you assume they are the same, do you also check these types along > with the function's return type ? What about a syntax like > '[:]' (with an error if arg is not passed by ref) ? Types of pass-by-reference arguments are only checked on the initial function call, like for all other type hints in PHP. This is an interesting point that you raise, though. > - In 'unaffected PHP functionality', you might change this : ' When the > strict type-checking mode isn't in use (which is the default), function calls > behave identically to previous PHP versions' as it is not exactly the case : > setting a scalar type in front of an argument restricts the possible zval > types he will accept. Ah, that’s a mistake on my part. It should say function calls to built-in/extension PHP functions (i.e. internal functions). I’ll correct that. > - Maybe a way to let the user decide whether he wants errors to be raised as > exceptions or PHP errors (a declare addition/variation?). If we define such > an option, it must go with the declare directive, not as an INI setting. > Exception could contain the required and provided types. Nikita’s Exceptions in the Engine RFC should replace this E_RECOVERABLE_ERROR with exceptions. I don’t think we need to allow choice, though… and PHP already lets you convert errors to exceptions if you want. > - Please, please, don't move declare() to ' ambiguous syntax I can imagine. That’ll be a separate, follow-up RFC. You’ll be free to vote against it. > - About the 'numeric' type you would introduce in a future RFC, would you (in > strict mode) allow everything accepted by is_numeric() or is it just a > shortcut for 'int|float’ ? The idea is just int or float (except in weak mode of course, where it needs to accept strings etc.). But that makes the naming possibly misleading. I’d prefer “number”, but that’d be a BC issue I expect. But that’s for a different RFC. > > Well, that's all for today. I spent 3 hours writing this from previous notes, > but the subject deserves it. > > Of course, most of this is for a future RFC but we can start thinking about > it. > > I send a copy of this post to Anthony because he probably has an interesting > opinion on the subjects I'm listing here. Thanks for your comments. :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow dropping typehints during inheritance
Hi, I’m coming back to this thread after some discussions about related matters off-list. I’m firmly convinced this is a good idea, now: * It would be very useful to extend the callable type hint to support typed parameters and return types. If we were to do so, its validation rules should follow inheritance’s. It would be really unfortunate if you couldn’t pass an untyped callback to a callable with typed parameters. * With the Scalar Type Hints RFCs, and other future RFCs, more type hints may be added to the language. It’d be a shame if existing interfaces couldn’t have type hints added to them. * Contravariance is widely accepted as being sound for parameter types. * We already have covariance for return type existence. So why not contravariance for parameter type existence? I hope we can have this added. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Void Return Type
Hi everyone, I’ve written a small RFC and patch to add a “void” return type: https://wiki.php.net/rfc/void_return_type Please have a read over it. I think this would be a simple, yet useful addition. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Hey François, On 14 Feb 2015, at 04:57, François Laupretre wrote: > That's a nice addition and a beginning to distinguish void from null, as I > imagine the function still returns null. > > Now, what about making void a real zval type ? It would open a lot of > possibilities. Unlike null, conversions from void would raise an error. It > would also be rejected as argument input type but could be used as an output > type when arg is passed by ref, it could be the default type for return_value > (huge BC break here) and so on... We could do this, but for the longest time we've made all functions have some return value, even ones which don't explicitly return one (they return NULL). I think it'd be better not to change this. I expect IDEs and such could earn you about it, though. > There's a need for a real 'no value' type different from null, as null has > too many uses. If defined correctly, it can be a powerful addition. If I was to go back to 1994, I'd add "undefined" to PHP like JS has. Today, though, I think that is unrealistic, as much as I wish it wasn't. A void type only really makes sense as a pseudo-type for return type checking purposes, IMO. Thanks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Hi,
> On 14 Feb 2015, at 05:03, Xinchen Hui wrote:
>
> Hey:
> be honest, I think it's only part of the idea is implemented.
>
> which make it useless.
>
> in PHP, even if you don't return anything, NULL is returned implicitly.
>
> even if a function is declared return nothing(void).
>
> like:
>
> function a() : void {};
>
> following codes still works:
>
> $b = a();
>
> so, if you want a void return type, and if you want it to be a useful
> feature..
>
> above expr should be invalid with an error " a() return nothing"
I'm not sure about this. PHP has always made functions valid rvalues, for
better or for worse. This RFC could make void functions "truly" void, but that
would be a massive change to support value-less function returns. It would also
break existing code which assumes all functions return a value, which isn't
good.
I think this RFC is enough: it would let you enforce that a function doesn't
return anything and makes code more self-documenting. It doesn't affect
anything trying to use the function's implicit return value of NULL, but IDEs
and code linters would surely pick up on it for you. It's still useful even if
it doesn't bind the caller.
Thanks.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Hi, > On 14 Feb 2015, at 05:54, Stanislav Malyshev wrote: > > Hi! > > I'm not sure what it is useful for, exactly. I mean, the more fatal > errors the merrier, but I fail to see what exactly use except having yet > more cases when your code may break it provides. I mean, if you defined > a void function, that means you're not using it return value anywhere. > Then who cares what return statement says? What would be the point of *allowing* returning a value? It's clearly an error. We could let you return anything and then discard it, but now you won't spot the error in your code. > Additionally, this RFC gets inheritance wrong - having return from > function that previously did not return anything is not a violation of > contract, since there's no practical contract that can rely on function > not returning anything (in fact, there's no way in PHP to even check > that AFAIK). I am wondering about inheritance as well. I thought of void as having no subclass. But it's not really a return type for our purposes, it's more like a declaration that a function doesn't return anything. So, I guess inheritance should allow removing or changing the typehint if it is void. I might need more opinions on this first, though. > Summarily, this seems to me an exercise in strictness for the sake of > strictness. There are languages that force people to abide by a lot of > rules because their creators believe more rules is the same as better > code, but PHP never was one of them and the fact there are so many > people trying to make PHP that makes me sad. It's not merely for the sake of it. It makes function signatures more descriptive, and lets you catch bugs in your code. We already use void in the manual: why not in PHP? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Hi, > On 14 Feb 2015, at 03:32, reeze wrote: > > Do we really have to throw an catchable fatal error? > > the other return types make sense, why so strict? We throw E_RECOVERABLE_ERROR for all type errors, both for parameters and return types. It's not anything new. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Hi Robert, > On 14 Feb 2015, at 21:23, Robert Stoll wrote: > > I think a void type for PHP would make sense but only if the return value of > such a function cannot be used. Why? If the return value cannot be used, it prevents the function being used with any API that stores the return value of a callback. That’s not terribly nice. A void return value doesn’t need to enforce anything on the caller. PHP has always filled in missing values with NULLs, including return values, like other dynamic languages do here. > Otherwise it is another reason for people to laugh at PHP and justifiably so, > telling that a function does not return anything but return null is very > inconsistent. It does implicitly return NULL, but NULL is a useless value, and it’s returned implicitly, rather than explicitly. I don’t think it’s really that ludicrous. > I suggest to use one of the following behaviours: > 1. declaring a function void does not return anything (hence is like echo to > a certain agree) That makes it cease to be a function in the PHP sense. PHP always allows functions to be used in expressions. > 2. declaring a function void does return a thing of type void (that would be > similar to Unit in scala) We don’t need another form of NULL. Also, a thing of type void could be passed around, just as the unit type can be in other languages, so it wouldn’t do what you want it to. > 3. instead of void a function can be declared to be of type null -> almost > the same behaviour as your RFC but without the inconsistency That seems like a strange solution. You’re requiring the function to always return a useless value. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Big Integer Support
Hi everyone, I should’ve done this a long time ago, but I’m going to hold a vote on this RFC. The implementation isn’t finished, but the remaining work isn’t impossible to surmount (though help would certainly be appreciated). RFCs can be put to vote without implementations (or so says https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished isn’t necessarily a blocker. Putting it to a vote, finally, means I can stimulate further discussion (let’s face it, most discussion on a given RFC happens during voting), and importantly, see how much support the RFC has in order motivate myself to finish the implementation. I think this would be a useful feature for PHP. It brings PHP into line with other modern dynamic languages in having integers of arbitrary size. It makes integer behaviour both more intuitive and more consistent across platforms. It (finally) adds a means for handling of 64-bit (and larger) integers in 32-bit environments. I think allowing integers to grow as needed and not having to worry about platform-specific details is very “PHP”, as well. So, anyway, here’s the RFC, including the voting widget: https://wiki.php.net/rfc/bigint Voting starts today (2015-02-15) and ends in 10 days (2015-02-25). If you have any queries, please ask. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Big Integer Support
Hi Netroby, > On 15 Feb 2015, at 04:00, Netroby wrote: > > The time range is Chinese lunar new year. Oh! My bad, I was unaware of that. (I really should’ve noticed that, given I am learning Mandarin.) When do festivities etc. end? What would be a good time to extend it to? Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Big Integer Support
Hi, > On 15 Feb 2015, at 12:39, Xinchen Hui wrote: > > On Sun, Feb 15, 2015 at 10:46 AM, Andrea Faulds wrote: >> Hi everyone, >> >> I should’ve done this a long time ago, but I’m going to hold a vote on this >> RFC. The implementation isn’t finished, but the remaining work isn’t >> impossible to surmount (though help would certainly be appreciated). RFCs >> can be put to vote without implementations (or so says >> https://wiki.php.net/rfc/howto), so the fact the implementation is >> unfinished isn’t necessarily a blocker. > for such a big change, the implementation self is also important, > there was some RFC accepted with "not good" implementation, which > cause lots of troubles for us to maintaining . This vote isn’t to be thought of as accepting the implementation, merely the feature. If the implementation isn’t good enough, the feature could actually be dropped for PHP 7, as much as I hope that won’t happen. >> >> Putting it to a vote, finally, means I can stimulate further discussion >> (let’s face it, most discussion on a given RFC happens during voting), and >> importantly, see how much support the RFC has in order motivate myself to >> finish the implementation. >> >> I think this would be a useful feature for PHP. It brings PHP into line with >> other modern dynamic languages in having integers of arbitrary size. It >> makes integer behaviour both more intuitive and more consistent across >> platforms. It (finally) adds a means for handling of 64-bit (and larger) >> integers in 32-bit environments. I think allowing integers to grow as needed >> and not having to worry about platform-specific details is very “PHP”, as >> well. >> > from your RFC: > " > but obviously the implementations of anything dealing with integers > may need to be changed." > > this sounds too much compare to the benefits it brings.. (User can use > bcmath or other similar thing to deal with big int). It’s not a massive change. All the places in core have already been changed. Most extensions taking integers do so via zpp’s “l” type (or FAST_ZPP’s Z_PARAM_LONG), which handles bigints properly. The main issue is functions accepting zvals (“z” or Z_PARAM_ZVAL). In such cases, the change is usually two lines of code to add an IS_BIGINT case to a switch. > and actually, I'd prefer this to be a extension instead of get it into core.. > > too much changes for little gains.. > > Thus, I voted -1 on this. Alright, I can understand your perspective. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Big Integer Support
Hi, > On 15 Feb 2015, at 13:07, Leigh wrote: > > I think this adds a ton of unnecessary complexity and isn't worth the > breaks or performance degradations that come with it. > > We already have big integer support in the form of the GMP extension, > and it is very clear when you are working with arbitrary length > integers. But instead this patch adds GMP as a dependency and hides it > away internally (or for a bigger performance hit, LibTomMath). > > Extensions "that deal with numbers" are all going to need updating. So > probably every extension? Anything accepting a zval rather than a long through zpp, but the changes are quite small in most cases. It’s a much smaller change than, say, what phpng did. > You talk about eventually deprecating ext/gmp and moving it to PECL. > Definitely not acceptable. I *talk* about it. I’m not saying we’ll do it. It’s a future possibility: since it would be made largely redundant by large integer support in core, we might eventually get rid of it. I said “might” because it’s not part of the proposal, it is merely a thought. > Sorry, the fixed size integer data type is far too baked-in and > useful. I could understand your perspective if PHP had modular arithmetic like C and such, but it doesn’t. So I don’t understand why it is “far too useful” - what usefulness is being lost by extending its range? > I don't see any gain from this patch except hidden performance > penalties, breaks, and extra work for everyone in maintaining it and > other extensions. I'd rather big int usage was kept verbose and > conscious. I see a clear gain: we clean up almost every integer overflow edge case, integer overflow handling is more intuitive, we support large integers safely on 32-bit, and we don’t require you to use a weird extension that may crash the PHP interpreter and DoS your web host in order to do large number arithmetic. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] I quit.
Hi everyone, For my own reasons, I have decided to cease my involvement with PHP development. This isn’t a judgement of the PHP community nor the internals mailing list, you’re all wonderful people and it’s really been a pleasure, and I mean that completely honestly. However, this has ended up taking up too much of my time (which is my own fault, and my own fault alone) and I can’t really justify it to myself anymore. So, I’m no longer contributing to PHP, and all four active RFCs authored by myself are therefore withdrawn: Scalar Type Hints, Spaceship/Combined Comparison Operator, Void Return Type, Big Integer Support. The first two were in voting, so the votes have been cancelled. If anyone would like to pick up from where I left off with any of these RFCs, they are very much welcome to - there is no need to consult me first (and it’s probably for the best if you don’t). The Spaceship/Combined Comparison Operator RFC was also authored by Davey Shafik, so ask him if you want to revive that one. I’m sorry about this, but it can’t be helped. I’d rather move on to other things. I would stick around to finish everything up before I leave, but I just don’t have the time nor the motivation to finish everything. I apologise for that, especially for Scalar Type Hints as I realise this is something a lot of developers were looking forward to. I’d leave quietly, but since this affects active RFCs, I need to announce it somewhere. So, thank you, PHP community. It has been a wonderful 2 years. Goodbye. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I quit.
Hey Rowan, > On 15 Feb 2015, at 22:07, Rowan Collins wrote: > > I'm really really sorry to hear this. The energy you've put into the project > recently has been really appreciated by many people, and I really admire your > dedication to finding compromises to controversial topics. I can see, though, > that it takes a lot of time to be that actively involved on a voluntary > basis, and that a clean break might feel necessary to shift your focus. I > hope to see your name in future, either in a less involved role in PHP, or in > some other project. Thank you. > On a purely procedural note, though, is there some way the Scalar Type Hints > RFC can be left in voting, as a vote in principle, while we wait for someone > to step up and take over the implementation? There are only 4 days left, and > with over 100 votes cast, it seems a shame to say that they were all > meaningless, while leaving the door open to start all over again. I think it > will hurt people's faith in the process to cancel now, and can't think of a > particularly strong reason not to let the vote run its course before deciding > what to do next. It might be for the best that we don’t keep it in voting. During the voting process, it became apparent that the declare() syntax (with all its idiosyncrasies) was a big problem (influencing at least 3 people’s votes), so much so that I decided that I’d make a follow-up RFC to fix it after voting ended, to avoid having to cancel the vote. Now that voting’s cancelled, that could be fixed properly if someone revived the RFC. I think the vote totals still make a statement. The vote may have ended 4 days early, but it’s only 1 vote short of a 2/3 majority. I’m not sure, really. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Spaceship operator RFC
Hi Stas, > On 16 Feb 2015, at 05:20, Stanislav Malyshev wrote: > > Since Andrea has withdrawn the spaceship operator RFC > (https://wiki.php.net/rfc/combined-comparison-operator), I'd like to > resurrect it. Looks like by vote results (with 1 day of official vote > left) it was clearly passing, so are there any objections to treating it > as passed? If not, I'll treat it as such and do the merging as soon as I > have time. I’m fine with that (though I’d already given permission in the “I quit.” email). I assume Davey’s fine with it as well, though you should probably check with him just to be sure. One thing of note is that I didn’t write a language specification patch. If you’re to pick it up, I guess you’d have to do that at some point, sorry about that. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Fix division by zero to throw exception
Hi Dmitry, > On 3 Apr 2015, at 20:04, Dmitry Stogov wrote: > > 2) Very similar weird behavior was introduced for shift with negative > offsets. I also propose to change it in the same way (Fatal error at > compile-time, Exception in run-time). > > Any thoughts? objections? For consistency with IEEE 754, shouldn't we produce INF on a division by zero, at least for floats (but probably integers too because of weak typing)? I don't think producing a warning is an issue, but FALSE isn't the right value to produce. However there should be a compile-time solution. Maybe, if a division by zero happens, don't evaluate the expression at compile-time? Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Fix division by zero to throw exception
Hi, > On 3 Apr 2015, at 20:46, Dmitry Stogov wrote: > > May be you'll also suggest something regarding bitwise shifts with negative > offset? > Allowing negative offsets using opposite directions would fix inconsistency, > but I remember, you didn't like it. > May be keep WARNING (Bit shift by negative number) and then perform shift in > another direction? > + disable negative shifts at compile-time. I don’t think opposite-direction shifts would work well for a few reasons. I don’t believe this is normal behaviour in other languages, for one. Another issue is that << and >> are not actually opposites, they have different behaviour with respect to signs, so there’d be ambiguity as to what $x << -$y means (is it the same as $x >> $y, or does it deal differently with signs?). Negative shifts being used are usually the result of mistakes, as well, so you want to inform the user. The main problem, though, is that we previously did something different if the shift is negative. Having it now produce a warning, means you’ll see error messages when you run existing code. But shifting in the opposite direction might change the behaviour of existing code silently I think the most sensible solution would be to make negative shifts produce an exception, since they’re really an error, an unsupported operation. I made them be a warning + return FALSE just because it matched division. But that’s not ideal and I’d be fine if it was replaced. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix division by zero to throw exception
Hi, > On 3 Apr 2015, at 21:34, Dmitry Stogov wrote: > > 3) One more problem is modulo :( > > $ sapi/cli/php -n -r "var_dump(1 % 0);" > > Warning: Division by zero in Command line code on line 1 > bool(false) Hmm, modulo is a more difficult one. Since it’s an integer-only operation in PHP, producing INF doesn’t make sense. It also doesn’t make sense mathematically. I think the most sensible thing to do here would be to throw an exception. On the same note, the new function intdiv() is the counterpart to % for obtaining the quotient (% produces the remainder). It currently does the same thing as % and / division and produces FALSE with a warning. If % is changed, intdiv() should be too, because they are the same operation, just returning different parts of the result. An exception being produced by both would seem reasonable. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Fix division by zero to throw exception
> On 3 Apr 2015, at 23:08, Dmitry Stogov wrote: > > On Apr 4, 2015 12:34 AM, "Nikita Popov" wrote: > > > > Don't think we need to disable compile-time evaluation for 2) and 3). It'll > > just end up being a compile error in that case. I think if you have 1 % 0 > > occurring in your code literally, it's better to have the compile fail > > rather than getting (or not getting) a runtime exception. > > This is even easier. > Andrea, what do you think? I was wondering if that might cause problems if you have a large codebase and some unfixed errors in a few places. If the code isn’t being run, only compiled, then it’d be unnecessary pain. However, the chances of a codebase having numerous undetected divisions by zero, that are obvious at compile-time, aren’t very high. So, failing at compile-time is fine. And, to save another email, I agree with the four items in your summary. Exceptions for negative shift, modulo/intdiv by zero, normal division by zero is +/-INF. :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closure::call() to access private data, really ?
Hi,
I'm no longer subscribed to internals so I don't know if this email will show
up there. If not, feel free to forward it.
> On 17 Apr 2015, at 17:43, Ferenc Kovacs wrote:
>
>
>
>> On Fri, Apr 17, 2015 at 6:11 PM, Julien Pauli wrote:
>> Just a simple use case showing how dangerous that is :
>>
>> > $p = function($p) { $this->$p = new Stdclass; };
>> $p->call($e = new Exception, 'trace');
>> throw $e;
>>
>>
>> That nearly crashes PHP7.
>> http://3v4l.org/fJj22
>>
>> (The same trick using Reflection with PHP5 crashes the engine, this is a
>> known bug that we chose not to fix).
>>
>>
>> I am absolutely not confident at all having Closure::call() beeing able to
>> access private data.
>>
>> Private is private.
>>
>> For internal classes, this is even worse, and could lead to crash (look at
>> the example about Exception).
>> Changing a variable that is private, is absolutely NOT expected from the
>> class designer.
>>
>> For User classes, this could lead to information leaks or bad behaviors,
>> and for internal classes this is even worse and could easilly segfault or
>> with a little bit of more magic and brain sauce, lead to memory disclosures.
>>
>> I would like we re-open the debate about accessign private data with
>> external code (closure), especially in a write context.
>>
>>
>> Julien.P
>
> For the record this isn't exclusive to Closure::call, afaik the same thing is
> possible with Closure::bind() since 5.4
> http://3v4l.org/hlFS4
> And there are/were a decent amount of discussion (and AFAIR even hydrate
> libraries using this trick) about this, for example:
> http://ocramius.github.io/blog/accessing-private-php-class-members-without-reflection/
> So while I think that for 7.0 we could remove this behavior, the cat is
> already out of the bag, as you can see from my paste you can use that code to
> cause segfaults for php >=5.4.0, so I think it would be better to fix the
> internal classes to properly handle/validate their properties instead of
> blindly trusting their types.
Right, what Closure::call() does isn't particularly new. I'm not sure if it's a
good thing that you can arbitrarily re-scope closures, but that's how it is.
Also, if information leaks are a worry, we've had things like ob_start() and
var_dump(), and (array) for a while now.
A further thought: type hints for class properties would be helpful here.
Thanks.
--
Andrea Faulds
http://ajf.me/
Re: [PHP-DEV] Closure::call() to access private data, really ?
Hey Julien, > On 22 Apr 2015, at 13:18, Julien Pauli wrote: > > Perhaps the best thing to do is to forbid rebinding a Closure to an internal > class ? > > I'm sure we could find segfaulting behaviors using such a trick on most of > our internals classes, aka mysqli, simplexmlelement, PDO or SPL classes. > > Thoughts ? Sounds good to me! There’s already a precedent for having internal classes special with respect to Closure binding, as you can’t bind a method of an internal class to an object not of that class. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix division by zero to throw exception (round 2)
Hi Bob, > On 29 Jun 2015, at 16:54, Bob Weinand wrote: > > I would like to bring this topic back up, as there were users confused with > it and it's absolutely not consistent what we have now. > See also https://bugs.php.net/bug.php?id=69957 (As I thought it was > non-intentional, I went ahead and "fixed" it, was reverted later, hence > discussing that now here.) > > So, looks like there was some quick decisions and discussion I totally had > missed. > What we have now is: > >> Am 03.04.2015 um 23:13 schrieb Dmitry Stogov : >> >> So the summary: >> >> 1) division by zero produces a warning and +/-INF IS_DOUBLE. Compile-time >> evaluation is disabled. >> >> 3) Modulo by zero produces Exception.Compile-time evaluation is disabled. > > Why? Why do we change the one but not the other? > > Why does 0 % 0 throw an Exception, but 0 / 0 NAN? > Why does 1 % 0 throw an Exception, but 1 / 0 INF? > > I'd like to either properly return 0, INF or NAN in both cases or in none. > > Having different rules for so similar operations is non-sense, I think. It > just is inconsistent and causes confusion. Those operations are not as similar as you think! In PHP, the complement of % isn’t /, it’s intdiv(). intdiv() takes an integer divided and divisor, and produces an integer quotient. % also takes an integer dividend and divisor, but produces an integer remainder. intdiv() and % work with integer-only inputs and always produce integer outputs. /, on the other hand, takes an integer or float dividend and divisor, and produces an integer or float fractional result. It might as well work only on floats and always produce floats, really, given that it behaves the same as if it did. So intdiv() and % work on integers, and / works on integers and floats. This informs how they handle certain error cases. For integer division and modulo (PHP’s intdiv() and %), the accepted way to handle division by zero is to produce an error. There’s no correct or useful result you can produce. In PHP, we used to produce FALSE here, which is a different type (boolean). I don’t think that was a good idea because of PHP’s weak typing. If you use FALSE in some other arithmetic operation, it’ll be coerced to zero, and produce weird results from other operations. Sure, there’s an E_WARNING produced, but your code keeps running and produces garbage. So, throwing an exception is safer and brings PHP into line with established practice in other programming languages. For floating-point division (PHP’s /), on the other hand, errors are usually handled differently. IEEE 754 defines special error values we can produce: +Infinity, -Infinity and NaN. These are still values of the float type, but they’re not normal numbers. They flow through floating-point operations in a well-defined manner. For example, if you do anything with a NaN and a NaN, you get a NaN, while if you divide by zero, you get ±Infinity, and if you divide by Infinity, you get ±0. Again, PHP used to produce FALSE here, which has the problems described earlier. ±Infinity and NaN, on the other hand, flow properly through later arithmetic operations. If the error affects your result, it will most likely be obvious, because it’ll be ±0, ±Infinity, or NaN. Yes, you result is garbage, but it’s at least obviously so. And, like with the integer behaviour, this brings PHP into line with established practice. tl;dr: intdiv() and % have matching behaviour because they work with integers and that’s what’s usually does for them, / has different behaviour because it works with floats and that’s what’s done for them. I hope that makes sense. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix division by zero to throw exception (round 2)
Hi again, > On 29 Jun 2015, at 18:02, Bob Weinand wrote: > > Yes, it generally makes sense... > Then I have other questions: > > - Why do we then still have a Warning? Either we have well-defined behavior, > or we throw an exception. Well-defined behavior *plus* a warning is IMO > non-sense. That’s weird, yeah. We don’t throw warnings for the math functions when you give them odd inputs, e.g. sin(INF) is just NAN, no warning. I think removing it would make sense. > - Is it intentional for intdiv and % to throw an Exception instead of Error > or some more specific DivisionByZeroError or similar? (yes, I know, Error is > only very recent, but the question still needs to be asked). Hmm. Using Error might make some sense given it used to raise E_WARNING. I think DivisionByZeroError sounds like a good idea. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix division by zero to throw exception (round 2)
Hi Bob, > On 2 Jul 2015, at 01:26, Bob Weinand wrote: > >> Am 29.06.2015 um 19:14 schrieb Andrea Faulds : >> >> Hmm. Using Error might make some sense given it used to raise E_WARNING. I >> think DivisionByZeroError sounds like a good idea. > > Hey, > > I just committed that to master… Great! > But I noticed that intdiv(PHP_INT_MIN, -1) isn't very well suited for a > DivisionByZeroError. > > What do you think about adding an ArithmeticError for that case (and making > DivisionByZeroError subclass of it)? > That ArithmeticError could then be reused for negative bitshifts, which would > solve the question what to do with that too. Well, that specific case is integer overflow. Normally in PHP we just upgrade to float instead of throwing an error in these situations, but for intdiv() I didn’t think that made sense (it’s *integer* division). So, maybe OverflowError would be a better name. But we don’t really do overflow errors anywhere else that I can think of, so the more general ArithmeticError might be fine. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix division by zero to throw exception (round 2)
Hey Sherif, > On 4 Jul 2015, at 21:56, Sherif Ramadan wrote: > > I'm proposing that we reconsider removing the warning from floating point > division and here's why. > > While IEEE 754 defines special values for floating point arithmetic when > division by zero occurs, there's nothing stopping the language from providing > useful error information to the user, which may help them debug potentially > buggy code. It's true that it's not exceptional since there is now well > defined behavior in the case of changing division by zero to IEEE 754 > standard in PHP. However, PHP didn't actually distinguish between integer > division and floating point division prior to intdiv. So in the case of > division by zero the warning was useful to help someone catch their mistake. > > Now, the onus is on the person writing the code to decipher whether or not > they created a potential division by zero scenario by deducing how they > arrived at INF at some point in their code. This is creating an unnecessary > burden when we've always provided the user with the useful error information > in the past. I'm not sure why we should remove it now, but based on this > conversation I can see that the confusion resonates around this urge to > convert the warning to an exception and the conflict of it not being > exceptional (in the case of floating point math) since there is now well > defined behavior. > > So my conclusion is that... > > Yes, it's not exceptional. No, we shouldn't throw an exception for division > by zero in floating point arithmetic. No, we shouldn't remove the warning > since it still provides useful information to the person debugging the code. > Debugging the code without this warning can be a monstrosity since you won't > necessarily know at which point in a compounded operation the division by > zero occurred. For example, PHP_INT_MAX ** PHP_INT_MAX creates an overflow > resulting in INF. Though 0 / INF results in 0. So an operation like (1 / ($x > / PHP_INT_MAX ** PHP_INT_MAX) where $x happened to be 0 in one particular > case, makes both hunting down and reproducing the bug quite difficult without > some direction. The warning has historically provided this direction in the > past and I believe that removing it now will only further the confusion. > > I don't think people actually care about whether or not we keep the warning. > I think what they would care about more is the consistency of the return > value and defined behavior, which I believe we have already addressed very > well. Yeah, keeping it around makes sense. Thing is, if it’s a problem, you can silence it with @, so @($a / $b). If that’s slow, we could optimise it (make it call div_function_no_error or something?) Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 21/10/2013 21:36, rpar...@yamiko.org wrote: This proposal sounds a lot like exceptions to me or am I missing something :/ Could we do something like throw new expectation($expects, $message); Er, T_EXPECT will be essentially a clone of Java and Python's assert statement, but not called assert because of the existing assert() function (and backwards-compatibility is PHP's middle name). Unless you mean the similar name. Well, I don't think "exception" and "expect" can be confused (though as someone who used to use Python, I keep reading this as "except", Python's equivalent to "catch"), though "ExpectationException" might be confusing. I think we should name it "AssertionException". -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
-1 to "expect is a problem". expect is not a problem. > Le 21 octobre 2013 à 10:42, Joe Watkins a écrit : > > > On 10/21/2013 09:57 AM, Tjerk Meesters wrote: > > On Mon, Oct 21, 2013 at 4:16 PM, Michael Wallner wrote: > > > >> On 21 October 2013 10:13, Patrick Schaaf wrote: > >>> Am 21.10.2013 03:52 schrieb "Joe Watkins" : > > So looks like we need a new name ?? Ideas ?? > >>> > >>> abstract EXPRESSION > >> > >> wat? > >> > >> > >>> abstract is already a keyword, so no BC. > >>> > >>> abstract is not concrete so alludes a bit to the > >>> might-be-or-might-not-be-checked nature of the test > >>> > >>> abstract is the name for the "short summary" intro part of scientific > >>> papers, and these conditions are kind of a summary of what is known > >>> (preconditions) and concluded (postconditions). > >> > >> Ah, ok well. I'd rather go for expected() or except() then... > >> > > > > Since we're throwing around terms, here's another one: > > > > predicate ; > > > > It should be understood by most programmers what it means (though, > > admittedly, it doesn't carry an obvious severity) and isn't used anywhere > > in the language (afaik). > > > > > >> > >> > >> -- > >> Regards, > >> Mike > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > > > I suggest we process thusly: > > We need some consensus as to whether this is actually a problem or not > before we get lost in suggestions ... > Should we decide it's a problem then we need to decide if using the > keyword "expected" solves the problem ... > Should there still be a problem we should compile a short list and get > a consensus on it before proceeding to make necessary changes. > > So first of all, can we get a quick +|-1 on: > > Using "expect" is a problem > Using "expected" solves the problem > > We can proceed from there I think ... > > Cheers > Joe > > > > > > -- > 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
Re: [PHP-DEV] [VOTE] Change crypt() behavior w/o salt
On 22/10/2013 07:10, Yasuo Ohgaki wrote: Hi all, Any comments patch for this RFC? Better E_NOTICE message is welcome. I'm a native English speaker, how about "Calling crypt() without giving a salt will not produce strong password hashes."? It doesn't necessarily say you will produce a strong hash with it (other factors are at play), but it does say that you can't without it. Perhaps "secure" might be better than "strong". Just my 2 pence. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] list() Reference Assignment
Good evening again,
Previously I wrote to this mailing list about my proposal to add
reference assignment to list() with a new syntax ("[PHP-DEV] Proposal:
Implement FR #7930 (list() constructor reference assignment)"). I have
now opened an RFC:
https://wiki.php.net/rfc/list_reference_assignment
In brief, this allows you to write this:
$array = [1, 2];
$a = $array[0];
$b = &$array[1];
Like this instead:
$array = [1, 2];
list($a, &$b) = $array;
Reference assignments with list() work just like normal assignments, and
you can still skip variables, use nested list()s, and use list() in
foreach as usual.
There is a patch with a passing test, however a memory leak bug was
found (thanks Nikita!), and so the patch can't be considered complete or
final yet. I'm something of a novice at debugging PHP code at the
moment, so any help fixing that would be appreciated, but I will try to
fix it when I have more time.
The patch is here: https://bugs.php.net/bug.php?id=6768
The RFC has been added to the list in Under Discussion.
Any thoughts, suggestions, etc. appreciated.
Regards,
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 24/10/2013 18:41, Nikita Popov wrote: Hi internals! I'd like to propose an RFC, which allows the use of exceptions within the engine and also allows changing existing fatal errors to exceptions: https://wiki.php.net/rfc/engine_exceptions This topic has been cropping up in the discussions for several of the recent RFCs and I think the time has come to consider moving away from fatal errors. Thoughts? Thanks, Nikita I love this proposal! Errors are a very dated way of handling errors, and there are a lot of fatal errors which are unnecessarily fatal. This would mean many could stop being fatal and start being exceptions, which is great news. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding new MIME types for the CLI web server
On 31/10/13 21:32, Derick Rethans wrote: Isn't there a reason why you can't use the fileinfo extension/code for this instead? Hardcoding it seems rather strange? I looked at the manual and mime_content_type() is deprecated and tells me to use the Fileinfo PECL extension. From which I am led back to the parent section, which is for the built-in Fileinfo extension. Looks like the manual is out-of-date. Anyhow, looks like finfo_file() works as we'd want, though I feel uneasy about guessing filetypes this way. Perhaps we should have several explicitly specified ones (.txt as text/plain, .html as text/html, etc.), and guess the rest? Especially for ones which it would not correctly guess. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] lxr.php.net's phpng seems out of date
Per this exchange on IRC: [11:48pm]Tyrael: ajf: http://lxr.php.net/history/phpng/Zend/zend_types.h [11:48pm]ajf: Tyrael: May now? Where was it stuck to before? Has the issue been fixed? [11:49pm]Tyrael: ajf: Cataphrac reported it to be fixed [11:49pm]ajf: Ah [11:50pm]Tyrael: checks out: https://github.com/php/php-src/commits/phpng/Zend/zend_types.h [12:04am]ajf: Aha [12:05am]ajf: Tyrael: and the most recent change, from laruence, is there:http://lxr.php.net/history/phpng/main/php_variables.c It would appear this issue has been resolved. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] not_null function
> On July 5, 2014 at 9:05 AM Pierre Joye wrote: > > > On Jul 5, 2014 9:43 AM, "Tjerk Meesters" > wrote: > > > > > Obviously spoke to soon ... what I've written there is basically an ugly > > `!isset($var)`. > > > > Totally fail to see what is ugly with is set or the difference with > exists(). The latter, in the context of php (even more with phpng) makes > little sense. > > Besides that, I am not sure what is the goal of this thread. Adding aliases > to copy cat ? Can we please stop this ridiculous bikeshedding? It is incredible this thread has gone on for so long. PHP has idiosyncracies, but frankly, the is_null function is hardly the worst of them and I see nothing useful resulting from this discussion. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Name of Next Release of PHP
Good evening, I am announcing a rather unorthodox RFC. With the advent of the phpng and uniform variable syntax RFCs, it looks likely the next major release of PHP, to succeed the 5.x series, may appear relatively soon. However, unlike with previous releases of PHP, it is not entirely clear what it shall be called. This RFC attempts to settle the matter once and for all with a straight yes/no vote as to whether the name should be PHP 6. Should it pass, the matter is settled and we actually have a proper name for this fabled “PHP NEXT”. Should it fail, nothing is really lost, except that the discussion will inevitably resurface at some point. The plan, really, is to hopefully get it over with now so we don’t have to have this discussion later, avoiding potential future bikeshedding or derailment. This is the shortest RFC I’ve ever authored, and I’d greatly appreciate it if everyone read the whole thing: https://wiki.php.net/rfc/php6 The plan for voting, if I think we should go ahead with it, is the same as a normal RFC: at least 2 weeks after proposed to internals, voting for at least 1 week. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 5 Jul 2014, at 22:57, Zeev Suraski wrote: > While I'm not sure whether this isn't a bit premature to have this > discussion, if we were to have this discussion, the RFC should do a much > better job at summarizing the discussions we already had in the past. That’s true. I’ve updated it with more arguments from past discussions. > First, it shouldn't be a yes/no for PHP 6, but rather, a 'PHP 6, PHP 7, or > Defer Decision' or at least 'PHP 6 / PHP 7’. I don’t want to have a vote with over two choices, I don’t think it would be fair (one option could pass without >50% voting for it), and a binary 6/7 choice is forcing people’s hand. I want it to be simple and straightforward, so that is why it is Yes or No to PHP 6. If people vote no, there could always be a different vote later, but that is not what I want to do. I am not going to change the vote options. > Secondly, contrary to what the RFC implies, the reasons against using > version 6 went far beyond books - and covered much more important things > (honestly I never quite understood the preoccupation with this books > angle, I don't think anybody at all cares about it). If we decide to do > the discussion now, the RFC should cover them (they were discussed in a > thread named "About PHP6 ..." > > Third, numerous people (myself included) actively proposed we skip version > 6 and go with version 7; Dismissing that with "I don't think the > alternative naming options are really much better" doesn't seem to belong > in an RFC. The merits of this option - which were really more about the > drawbacks of calling it '6' and the lack of drawbacks of calling it '7' > should be properly described in the RFC. I’ve covered the PHP 7 issue more now. > Of course, you don't have to buy into that reasoning, but let's not tuck > the discussion away under the carpet. If we were to have this discussion > now, let's make the best cases we can for both options on the table, > instead of focusing on just one and dismissing the opposition as something > about books. Sure. > Another couple of cents - both because of what I said here but also > unrelated, I think /rfc/php6 is a bad name for this RFC (both because > there's more than one option, but also because this is too generic for > something as wide as the next version of PHP). Perhaps /rfc/php2015 is a > better choice, or at least /rfc/php.next.name Right, the URL isn’t entirely ideal, but it’s not really important. I don’t think it’s possible to change it, and this is at least memorable. Really, RFC URLs are pretty meaningless. We’ve had URLs before with spelling errors in them. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 00:05, Zeev Suraski wrote: > I think there's some confusion here. > > If the next version of PHP is going to be a major one (which is clearly > defined in https://wiki.php.net/rfc/releaseprocess), then I believe the > only two options that were ever raised are PHP 6 and PHP 7. If you're > aware of other proposals that were made then please state them, otherwise, > I think it's a very clear decision between 6 and 7 - and putting this as a > 'yes/no' for 6 gives it undue advantage. Well, if we have the current yes/no to PHP 6 vote, then if it passes, we get PHP 6. If it doesn’t pass, we’re back where we were before. If we go for PHP 6/PHP 7 vote, then the result is unclear. Would one option be the default? Would it be PHP 7 if it’s not PHP 6? Would it be PHP 6 if it’s not PHP 7? In which case, what’s the point in a majority? We could hold a 50%+1 vote, but such a vote would be contentious and would be a popularity contest, not requiring consensus. If we don’t have a default, and either 6 has to get 2/3 or 7 has to get 2/3, then we should have an Other option, or a Continue Discussion option, or both. This is all way too complicated for me and I don’t want the vote to be contentious or confusing. Hence, it is a Yes/No vote to PHP 6. If it fails, we are back to where we were before. If it passes, the name is PHP 6. It could not be more straightforward, and the result cannot be misinterpreted. It requires a 2/3 majority to pass, so it would require consensus. Again, this is my position and I am sticking to it. I see no good reason to complicate matters. >> I've covered the PHP 7 issue more now. > > Not really, not in a meaningful way. You haven't covered the real > drawbacks of calling it PHP 6 (it's still this books thing which nobody > cares about, and perhaps even incites people to support 6 just to spite > these 'evil book authors'), and you haven't covered the advantages or > disadvantages of calling it 7 - beyond a very weak and very biased > dismissal. I'm intentionally not going into those here, because I don't > want to (re)start the discussion right here and now. A lot has been said > already about this and the RFC should reflect it, or not move ahead. I’m willing to take suggestions, if that could improve it. > Andrea - this updated RFC is the very definition of tucking the discussion > under the carpet and trying to run ahead to force a 6 decision without > doing the discussion that already took place any justice. > > The only way to really make the case for both options is for someone who > believes in each option to make the case; And to make this RFC about a > decision between these two. Which options? 6 and 7? This isn’t a 6 vs 7 RFC. This is a 6 or not RFC. Sure, I can’t make a great case against 6, unfortunately. I am willing to accept suggestions here. > However, I have to say I wish that instead of (IMHO) wasting energy on > such a discussion at this point, we'd focus on the actual content of > php.next. People sharing phpng benchmarks and testing it with their apps > would be a whole lot more productive use of our time. The entire point of this RFC is to get the discussion over with sooner rather than later, and hopefully come to a decision quickly so we don’t need to discuss it again. Also, I disagree that holding a vote to settle the name matter once and for all is a waste of energy. It should, hopefully, mean less energy wasted than otherwise in future. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 01:29, Kris Craig wrote: > I would, however, recommend that Andrea take Zeev's input and create a more > comprehensive section outlining his arguments in favor of breaking from the > current convention. Another section could be created to outline the other > side. What we don't want is a situation where Zeev feels compelled to write > a competing RFC. That could get messy, so I think it'd be best if the two of > you could find enough common ground to make this RFC acceptable to both sides. Right. As I said, I’m willing to improve the Rationale section with suggestions, I just can’t think of many other arguments for at the moment. Perhaps I need to delve deeper and read some more previous discussions. I’m not in favour of the version skip, and though I can play devil’s advocate, I am not really very good at doing so here. I don’t dispute that the Rationale section could do with improvement. > > I'd also recommend that, since you're calling for a 2/3 vote, you specify > more clearly what it is that requires 2/3; breaking the current convention or > keeping the current convention? I'm guessing you probably meant the former, > but the wording seemed a bit vague on that point to me. I’m not exactly sure what you’re talking about here, but to clarify: It is a 2/3 majority-required vote on whether or not the name should be PHP 6. That would be in line with the current convention of incrementing the major version number. I can see Zeev’s point that 7 is the main other option (though I also think 6.1, or codenames, are possible though unlikely other options). However, I don’t want to call a 50%+1 6/7 vote because it just feels like too narrow of a majority. I suppose if that 6 yes/no vote fails, I might consider a 50%+1 6/7 vote. Bear in mind I proposed at some point recently that we use 2/3 for all votes. That was largely related to the 64bit RFC, but I still agree with the principle. To be honest, I may end up retreating at this point and just calling a 50%+1 before even running a 2/3 one. My problem with that is that I feel such a narrow majority would be too contentious and not end the discussion for good. Sadly, it is not realistic to hold a vote on the majority with which to vote. ;) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 02:04, Christoph Becker wrote: > Andrea Faulds wrote: > >> I can see Zeev’s point that 7 is the main other option (though I also >> think 6.1, or codenames, are possible though unlikely other options). >> However, I don’t want to call a 50%+1 6/7 vote because it just feels >> like too narrow of a majority. I suppose if that 6 yes/no vote fails, >> I might consider a 50%+1 6/7 vote. > > Have you considered a 6 vs. 7 vs. other vote, which would require a > majority (i.e. > 50%) to pass? In my first reply to Zeev, I said I was opposed to having a 6/7/other vote with a plurality, but a 50%+1 vote of that kind might be more tolerable. Then again, the “other” votes might ensure nothing passes. To be honest, I’d much rather just do a 6/7 50%+1 vote in that case. I suppose I could also do a 6/7 2/3 majority vote in place of the 6 yes/no 2/3 majority vote the RFC proposes, though then again, you’d have the question of what to do if neither gets an outright majority. Of course we have that problem anyway with a yes/no 2/3 majority vote. Argh, I need some sleep. I’ll think about it further and respond in the morning. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 5 Jul 2014, at 22:23, Andrea Faulds wrote: > This RFC attempts to settle the matter once and for all with a straight > yes/no vote as to whether the name should be PHP 6. Should it pass, the > matter is settled and we actually have a proper name for this fabled “PHP > NEXT”. Should it fail, nothing is really lost, except that the discussion > will inevitably resurface at some point. The plan, really, is to hopefully > get it over with now so we don’t have to have this discussion later, avoiding > potential future bikeshedding or derailment. The RFC has been updated. I’ve backed down and made the vote be 50%+1 with the options PHP 6 and PHP 7. Hence only a plurality of votes is needed to win. Hopefully this should be decisive, unless the number of Yes and No votes matches. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 14:48, Lester Caine wrote: > Andrea - Your total disregard for anything other then a a single reason > related to books is a problem here. While printed /electronic books are > a part of the problem with the tag PHP6, there are considerable > additional references to that tag over the last 10+ years, along with a > substantial amount of code in the code base which was a dead end. PHP6 > has been linked with development work which will not now be taken forward. I don’t have a total disregard for it. I acknowledge the argument that PHP 6 was a real thing, although it never was released properly and was eventually abandoned. If the RFC isn’t clear enough about this argument, again, I welcome suggestions to improve it. I’d suggest talking with me on IRC about it (#php.pecl on EFNet) if you catch me there, might mean less noise than here on the list. Of course, nothing wrong with email. > To some extent WHAT the next version is released as is perhaps not the > problem here, but rather being able to simply identify third party > discussions relating to the current roadmap(s) for PHPNext? It's just > the matter of ring fencing what is the current roadmap and plan for > PHPNext and isolating that from the older existing PHP6 documented plans > ... The use of PHP7 can be simply explained, fits in perfectly with the > code base, and provides a clean tag to move forward? Using some > alternative tag until a release is ready and then switching back to PHP6 > simply does not make sense? We have no PHP-6 or PHP-6.0 tag/branch in git, I see no reason why we wouldn’t call it PHP 6 before release, if we decide to call it PHP 6, of course. I think it’s generally clear what’s for the new PHP 6 and what’s for the old; anything from after the old PHP 6 was abandoned must be about a new PHP 6, and anything from before it must be about the old PHP 6. If this RFC were to pass with people voting for 6, then it would be pretty clear that anything coming after it was about the new PHP 6. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 16:12, Jocelyn Fournier wrote: > It's my first post in this list, and wanted to share my external point of > view, with a parallel with the MySQL world. Welcome to PHP! :) > MySQL 6 was alpha in 2007 and finally was never released. > So far its name has never been reused (instead we had MySQL 5.6 and 5.7 to > avoid confusion, and there are also books about PHP 6 / MySQL 6) > Even on the MariaDB side, they bumped up the version to 10.0 to avoid > confusion (and because it was not based on MySQL 5.6). Similarly, ECMAScript 4, which was to be the replacement for ECMAScript 3, was abandoned and skipped, with ECMAScript 5 replacing it and ECMAScript 6/Harmony continuing it in spirit. There is some precedent for this. > There are quite a few tutorials and reference about PHP 6 on the web, it > would be misleading to have something completely different, but with the same > name as the "old" PHP 6. However I'm not convinced "7" is the right choice, > perhaps a radical change in version number would be better ? Well, 7 is a nice number. But yes, a more radical change might be better. How about PHP 14, after the year? PHP Loxodonta, a genus of elephants? PHP 14.mm, where mm is the month, following the Ubuntu month/year scheme? However, all other options only seem to have fringe support at the moment, so a binary 6/7 vote is optimal, unless you can find a name everyone can agree on. Keeping with 6 or 7 means we stick to our tried and tested naming scheme, too. I think that’d be for the best. Side note: another thought comes to me now that just skipping 6 and going to 7 makes little sense in a way, as 7 isn’t the successor to 6, it is the second successor to 5, the first (the old PHP 6) having been abandoned. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 17:46, Lester Caine wrote: > On 06/07/14 16:08, Andrea Faulds wrote: >> I think it’s generally clear what’s for the new PHP 6 and what’s for the >> old; anything from after the old PHP 6 was abandoned must be about a new PHP >> 6, and anything from before it must be about the old PHP 6. If this RFC were >> to pass with people voting for 6, then it would be pretty clear that >> anything coming after it was about the new PHP 6. > > https://www.google.co.uk/search?q=php6+site%3Abugs.php.net ... > > Now one can filter additional on date, but the point here is that just > starting with the bugs list we have conflicting material that needs to > be avoided. PHP6 WAS documented extensively even just on the web site, a > lot of that material gets mirrored with more recent timestamps which > makes filtering what is new and what is old a lot more difficult. Even > PHP7 appears quite often on the website, but fortunately not too often > in the bugs list … Can’t we just rename the PHP 6 category to “Old PHP 6” on bugs.php.net and be done with it? Or does it not work like that? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 18:37, Zeev Suraski wrote: > I appreciate your change! > > As such I'd like to coauthor it with you and represent the case for 7. You’re welcome to edit the RFC and add a subsection with a case for 7. I’d appreciate it if you could discuss edits to the existing Rationale with me (I don’t want it to unintentionally be too 7-sided). If you can catch me on IRC, that would be optimal. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
