Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On 7/11/13 2:56 PM, Florin Patan wrote: We already have a bunch of RFCs about strict typing in PHP: https://wiki.php.net/rfc/typechecking So I personally am not sure we need yet another RFC on the topic - given that we discussed previous ones multiple times. You are right, as part of the moving from gist to RFC I'll try and contact the authors and see if they are still interested in this topic. Friendly recommendation: Keep the RFC and all discussion tightly focused on adding optional return typing for callables, but ONLY for things that are already type hintable as parameters. Trying to expand beyond that will run right smack into the ancient battlefield of strict typing discussions, and the ghosts of brave souls that have fought and died upon it. :-) I'm pretty sure that would kill the proposal in OT chatter. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
> @Sara: thank you for the offer, I'll send you a mail, if it's ok with > you, in the next days, I'd want to make this as a tutorial and maybe > me implement it with your guidance, but more on this another time. > > Sure thing. PHP needs more developers with deep understanding of the engine. I'd be happy to work interactively with you. If you happen to be in the bay area, feel free to come by FBHQ and I'll give you a tour and/or work on the diff with you directly.
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Thu, Jul 11, 2013 at 10:52 PM, Sara Golemon wrote: > I agree 100%. > > This particular item has been in the works since before I joined the team > and I've given them a bollocking out over it. You may have noticed > UConverter and a few other changes which WERE proposed to internals@ prior > to inclusion in HHVM and the implementation of those features were changed > based on the feedback received from this group. > > I'm on PHP's side, guys. > > > On Thu, Jul 11, 2013 at 1:47 PM, Nikita Popov wrote: >> >> On Thu, Jul 11, 2013 at 10:27 PM, Sara Golemon wrote: >>> >>> I won't suggest that PHP should follow HHVM, if anything I'll usually >>> (and >>> have frequently) rallied for the other way around. In this case, >>> however, >>> as with Generators, I think that we should endeavor to keep the >>> implementations close together by the most appropriate means. I don't >>> want >>> two versions of PHP syntax. >> >> >> It would be nice if the HHVM devs could send a mail over to internals when >> you're including new syntax, so we are a) aware of the fact that you're >> adding it and might consider adding it too and b) have a chance to provide >> some input on the feature (in particular also in order to bring it into a >> form that PHP would be willing to include). >> >> I understand that discussing some new feature on internals most likely >> needs five times more time than actually implementing it in HHVM, but I >> think that it would benefit everyone if there was some communication between >> the projects :) >> >> Nikita > > Helo, @Sara: thank you for the offer, I'll send you a mail, if it's ok with you, in the next days, I'd want to make this as a tutorial and maybe me implement it with your guidance, but more on this another time. @All: please keep this discussion about adding the return typing feature to PHP. There's a separate thread for HHVM + PHP and I think it's a better place to talk about these issues. Search for title: 'Integrate HHVM into PHP (Was: Re: [PHP-DEV] Request for comments - new PHP feature: return typing)'. Also, I think it is great that people from FB could participate in this since they are the largest instalment of PHP, if I'm not wrong, and, while their needs might be sometimes specific to their business/application, it's clear that their ultimate goal is a better language and better performance, which I believe it's the same as everyone here wants. Thank you. Best regards, Florin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
I agree 100%. This particular item has been in the works since before I joined the team and I've given them a bollocking out over it. You may have noticed UConverter and a few other changes which WERE proposed to internals@ prior to inclusion in HHVM and the implementation of those features were changed based on the feedback received from this group. I'm on PHP's side, guys. On Thu, Jul 11, 2013 at 1:47 PM, Nikita Popov wrote: > On Thu, Jul 11, 2013 at 10:27 PM, Sara Golemon wrote: > >> I won't suggest that PHP should follow HHVM, if anything I'll usually (and >> have frequently) rallied for the other way around. In this case, however, >> as with Generators, I think that we should endeavor to keep the >> implementations close together by the most appropriate means. I don't >> want >> two versions of PHP syntax. >> > > It would be nice if the HHVM devs could send a mail over to internals when > you're including new syntax, so we are a) aware of the fact that you're > adding it and might consider adding it too and b) have a chance to provide > some input on the feature (in particular also in order to bring it into a > form that PHP would be willing to include). > > I understand that discussing some new feature on internals most likely > needs five times more time than actually implementing it in HHVM, but I > think that it would benefit everyone if there was some communication > between the projects :) > > Nikita >
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
> > > 1) HHVM isn't just running FB. A number of sites have either already > started using HHVM, or intend to soon. > > Were could I read about those? > > I didn't list any because I don't know how they individually feel about sharing that info. I realize that takes the wind out of my statement, but there it is. > > 2) The "static compilation" description is grossly outdated information. > > I guess my knowledge about HHVM is a bit out of date, which is no wonder > as I wasn't following latest developments for some time. Could you send > a link where I (and everybody interested of course :) could read about > the current state of affairs? > > Apart from the documentation distributed with HHVM, you could look at our blog http://www.hiphop-php.com/ which includes a walkthrough in getting WordPress running http://www.hiphop-php.com/wp/?p=113 > > however, as with Generators, I think that we should endeavor to keep the > > implementations close together by the most appropriate means. I don't > > want two versions of PHP syntax. > > I don't think whatever HHVM does without input from PHP community should > be any argument for any change in PHP. If it is good for PHP, it can > stand on its own merit, if it's not, then the fact that HHVM team did it > for some internal reasons that we do not know can not be an argument. > > If we want a common PHP syntax that will be followed by different > implementations, it's a great idea, but it can not start with "we > already did it, so you have to do it too". I don't want many versions of > PHP syntax either, but I don't think HHVM team should be the one > deciding how the one version looks like. If they use syntax that is good > (I think this specific one is not, but that's beside the point, as it is > only my personal opinion) it can and should be argued on its own merits, > not on the argument that it is in HHVM. > > I never stated, not intended to state, "we already did it, so you have to do it too". Please do not put words into my mouth. I think it should be a part of the conversation, not a dominant part, but a part. Of course every new feature should be argued on its own merits. Please do not suggest that I think otherwise.
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Thu, Jul 11, 2013 at 10:27 PM, Sara Golemon wrote: > I won't suggest that PHP should follow HHVM, if anything I'll usually (and > have frequently) rallied for the other way around. In this case, however, > as with Generators, I think that we should endeavor to keep the > implementations close together by the most appropriate means. I don't want > two versions of PHP syntax. > It would be nice if the HHVM devs could send a mail over to internals when you're including new syntax, so we are a) aware of the fact that you're adding it and might consider adding it too and b) have a chance to provide some input on the feature (in particular also in order to bring it into a form that PHP would be willing to include). I understand that discussing some new feature on internals most likely needs five times more time than actually implementing it in HHVM, but I think that it would benefit everyone if there was some communication between the projects :) Nikita
[PHP-DEV] Re: Integrate HHVM into PHP (Was: Re: [PHP-DEV] Request for comments - new PHP feature: return typing)
If you run into issues (yes, our build system still sucks a bit) poke me in IRC freenode/#hhvm (or ptarjan or any other @ in that channel). And just to jump in front of what I detect in your comment "albiet compile it". Repeat: HHVM is not a code translator anymore. Hasn't been for awhile now. The basic functionality of HHVM is just like PHP. Put a .php file in your webroot, browse it, profit. -Sara On Thu, Jul 11, 2013 at 12:45 PM, Florin Patan wrote: > On Wed, Jul 10, 2013 at 10:58 AM, Patrick ALLAERT > wrote: > > Hello Florin, > > > > 2013/7/10 Florin Patan : > >> Since you brought up the discussion, would you think it would make > >> more sense to actually start and integrate HHVM into PHP rather that > >> patching it up? > >> Or better yet, rewrite it with a HH VM in mind? > >> I know and fully understand it's a gigantic task but at some point in > >> a software lifecycle there's only so much patching up you can do > >> before you can't patch it anymore. > >> Thanks. > > > > Not that this is not interesting, but this is deviating the discussion > > so much than the original thread that it is worth having it as it's > > own thread. > > Please, remember to change the subject if you start an off-topic > > discussion, it makes discussions easier to follow. > > > > Thanks, > > Patrick > > Hi, > > > Thank you for moving this into a separate thread. > > I'll look into HHVM in the following days/weeks but I think it's clear > that HHVM brings some nice concepts both to the language and to the > way PHP works, albeit compile it and so on. > Also reading articles like this: > > http://ocramius.github.io/blog/accessing-private-php-class-members-without-reflection/ > makes me very sad that this code is possible in PHP in order to > overcome speed issues of the language. > Could this be a topic of interest for more people, especially the core > people? > > > Best regards, > Florin > > Florin Patan > https://github.com/dlsniper > http://www.linkedin.com/in/florinpatan >
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
Hi! > 1) HHVM isn't just running FB. A number of sites have either already started using HHVM, or intend to soon. Were could I read about those? > 2) The "static compilation" description is grossly outdated information. I guess my knowledge about HHVM is a bit out of date, which is no wonder as I wasn't following latest developments for some time. Could you send a link where I (and everybody interested of course :) could read about the current state of affairs? > however, as with Generators, I think that we should endeavor to keep the > implementations close together by the most appropriate means. I don't > want two versions of PHP syntax. I don't think whatever HHVM does without input from PHP community should be any argument for any change in PHP. If it is good for PHP, it can stand on its own merit, if it's not, then the fact that HHVM team did it for some internal reasons that we do not know can not be an argument. If we want a common PHP syntax that will be followed by different implementations, it's a great idea, but it can not start with "we already did it, so you have to do it too". I don't want many versions of PHP syntax either, but I don't think HHVM team should be the one deciding how the one version looks like. If they use syntax that is good (I think this specific one is not, but that's beside the point, as it is only my personal opinion) it can and should be argued on its own merits, not on the argument that it is in HHVM. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
> Should I conclude that there's enough interest for this feature and > move from a gist to a RFC? If so, I would definitely need someone to > help out with the implementation. > > Without wanting to put the cart too far before the horse, I'll mention that FB is willing to offer resources (me, basically) to work on an implementation. And yes, preferably one which isn't directly at odds with our syntax. ;)
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
> While HHVM is a very interesting project, their use case is pretty > specific and narrow, and, as I understand, connected to a single > application (albeit running huge traffic numbers). So I'm not sure > copying whatever they do is necessarily good for PHP as a whole. HHVM > case is basically static compilation of monolithic application, as far > as I remember, which is not how PHP is usually run. It is true that such > mode negates many arguments against static typing, but it negates them > only for specific narrow case of HHVM, not for PHP as a whole. > Incorrect on a few points: 1) HHVM isn't just running FB. A number of sites have either already started using HHVM, or intend to soon. 2) The "static compilation" description is grossly outdated information. HHVM behaves the same way as PHP when it comes to running an application. There's an optional "precompile to bytecode" step, but that's a minor optimization overall. In general, you just point it at your webroot and it compiles to bytecode on demand (just like PHP) caches the compiled bytecode (just like APC or ZO+), and JITs to machine code as needed. 3) We mitigate the arguments against strict typing in other ways than you think, evidently. :) I won't suggest that PHP should follow HHVM, if anything I'll usually (and have frequently) rallied for the other way around. In this case, however, as with Generators, I think that we should endeavor to keep the implementations close together by the most appropriate means. I don't want two versions of PHP syntax. -Sara
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
Hey, On Thu, Jul 11, 2013 at 9:51 PM, Stas Malyshev wrote: > Hi! > >> Thanks for your input Sara, everything sounds very interesting. In all >> fairness I haven't looked at HHVM but I from what you described about >> this particular feature sounds good. >> >> Should I conclude that there's enough interest for this feature and >> move from a gist to a RFC? If so, I would definitely need someone to >> help out with the implementation. > > We already have a bunch of RFCs about strict typing in PHP: > https://wiki.php.net/rfc/typechecking > > So I personally am not sure we need yet another RFC on the topic - given > that we discussed previous ones multiple times. > > While HHVM is a very interesting project, their use case is pretty > specific and narrow, and, as I understand, connected to a single > application (albeit running huge traffic numbers). So I'm not sure > copying whatever they do is necessarily good for PHP as a whole. HHVM > case is basically static compilation of monolithic application, as far > as I remember, which is not how PHP is usually run. It is true that such > mode negates many arguments against static typing, but it negates them > only for specific narrow case of HHVM, not for PHP as a whole. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 You are right, as part of the moving from gist to RFC I'll try and contact the authors and see if they are still interested in this topic. As for the HHVM stuff, lets move to the other thread. Best regards, Florin Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
Hi! > Thanks for your input Sara, everything sounds very interesting. In all > fairness I haven't looked at HHVM but I from what you described about > this particular feature sounds good. > > Should I conclude that there's enough interest for this feature and > move from a gist to a RFC? If so, I would definitely need someone to > help out with the implementation. We already have a bunch of RFCs about strict typing in PHP: https://wiki.php.net/rfc/typechecking So I personally am not sure we need yet another RFC on the topic - given that we discussed previous ones multiple times. While HHVM is a very interesting project, their use case is pretty specific and narrow, and, as I understand, connected to a single application (albeit running huge traffic numbers). So I'm not sure copying whatever they do is necessarily good for PHP as a whole. HHVM case is basically static compilation of monolithic application, as far as I remember, which is not how PHP is usually run. It is true that such mode negates many arguments against static typing, but it negates them only for specific narrow case of HHVM, not for PHP as a whole. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Integrate HHVM into PHP (Was: Re: [PHP-DEV] Request for comments - new PHP feature: return typing)
On Wed, Jul 10, 2013 at 10:58 AM, Patrick ALLAERT wrote: > Hello Florin, > > 2013/7/10 Florin Patan : >> Since you brought up the discussion, would you think it would make >> more sense to actually start and integrate HHVM into PHP rather that >> patching it up? >> Or better yet, rewrite it with a HH VM in mind? >> I know and fully understand it's a gigantic task but at some point in >> a software lifecycle there's only so much patching up you can do >> before you can't patch it anymore. >> Thanks. > > Not that this is not interesting, but this is deviating the discussion > so much than the original thread that it is worth having it as it's > own thread. > Please, remember to change the subject if you start an off-topic > discussion, it makes discussions easier to follow. > > Thanks, > Patrick Hi, Thank you for moving this into a separate thread. I'll look into HHVM in the following days/weeks but I think it's clear that HHVM brings some nice concepts both to the language and to the way PHP works, albeit compile it and so on. Also reading articles like this: http://ocramius.github.io/blog/accessing-private-php-class-members-without-reflection/ makes me very sad that this code is possible in PHP in order to overcome speed issues of the language. Could this be a topic of interest for more people, especially the core people? Best regards, Florin Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jul 10, 2013 at 8:30 PM, Sara Golemon wrote:
>> With regard to any sort of hinting, an issue of 'one of' return types
>> would need to be addressed (I hope).
>>
>> function foo(SomeClass $bar, int $baz) : bool, SomeClass {}
>>
>> Allowing for a failure (False) or a success (SomeClass).
>>
>> We (HHVM) deal with failure alternates by way of a "nullable" syntax:
>
> function foo(SomeClass $bar, int $baz) : ?SomeClass {}
>
> Means the function returns SomeClass or null. null being the "failure"
> case.
>
> We also do "mixed" for anything (basically, no type hint, but explicitly
> stated), and "numeric" for a less aggressive float/int/numeric-string
> (though that's more specific to arg types than return types).
>
>
>
>>
>> I think it would useful to have a Null hint (like C's void I suppose).
>> More to do with explicitly saying no return type, rather than saying
>> nothing which means an undefined return type.
>>
>> function foo(SomeClass $bar, scalar $baz) {} /** you can return
>> something, but who knows what will happen with it. **/
>> vs
>> function foo(SomeClass $bar, scalar $baz) : Null {} /** This method does
>> not return anything and to do so would be wrong. **/
>>
>>
> function foo() : void {} is our syntax. A null return value is an actual
> thing (a null thing), whereas no return is more explicit. I know that
> `return;` gets translated into `return null;` anyway, but we also look at
> the caller side (return_value_used) and warn about "attempt to use value
> from a function returning void" like C/C++ do.
>
>
> Another advantage of scalar is the ability to stop scalar only functions
>> from receiving objects, arrays, etc.. Currently no way to inhibit that
>> without type testing in the function.
>>
>> We don't currently do "any scalar", though we do have "numeric" (as
> mentioned above). I agree with you that "scalar" would be a nice meta-type.
>
>
>
>> And, if PHP evolves to allow for __toScalar(), then an object can
>> represent itself as a scalar for those situations where the scalar type
>> hint is required. I think this may be a bit much initially though (unless
>> some clever bod has already worked all this out). Being able to cast an
>> instance from type A to type B via __autocast_ where is the
>> resultant type ... ha ha ... OK that really is just pushing things. Maybe.
>>
>> Going off-topic here, but I worry that __toScalar() would collide in a
> messy way with __toString() (and other, future __to() behavior). Not
> severely against it, mind you, but I think we (PHP) need to be cautious
> about going down that road.
>
> -Sara
>
> P.S. - Your reply only went to me, but I assume you wanted to include
> internals@ so I put them back in the To: line.
Thanks for your input Sara, everything sounds very interesting. In all
fairness I haven't looked at HHVM but I from what you described about
this particular feature sounds good.
Should I conclude that there's enough interest for this feature and
move from a gist to a RFC? If so, I would definitely need someone to
help out with the implementation.
Best regards,
Florin
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
> With regard to any sort of hinting, an issue of 'one of' return types
> would need to be addressed (I hope).
>
> function foo(SomeClass $bar, int $baz) : bool, SomeClass {}
>
> Allowing for a failure (False) or a success (SomeClass).
>
> We (HHVM) deal with failure alternates by way of a "nullable" syntax:
function foo(SomeClass $bar, int $baz) : ?SomeClass {}
Means the function returns SomeClass or null. null being the "failure"
case.
We also do "mixed" for anything (basically, no type hint, but explicitly
stated), and "numeric" for a less aggressive float/int/numeric-string
(though that's more specific to arg types than return types).
>
> I think it would useful to have a Null hint (like C's void I suppose).
> More to do with explicitly saying no return type, rather than saying
> nothing which means an undefined return type.
>
> function foo(SomeClass $bar, scalar $baz) {} /** you can return
> something, but who knows what will happen with it. **/
> vs
> function foo(SomeClass $bar, scalar $baz) : Null {} /** This method does
> not return anything and to do so would be wrong. **/
>
>
function foo() : void {} is our syntax. A null return value is an actual
thing (a null thing), whereas no return is more explicit. I know that
`return;` gets translated into `return null;` anyway, but we also look at
the caller side (return_value_used) and warn about "attempt to use value
from a function returning void" like C/C++ do.
Another advantage of scalar is the ability to stop scalar only functions
> from receiving objects, arrays, etc.. Currently no way to inhibit that
> without type testing in the function.
>
> We don't currently do "any scalar", though we do have "numeric" (as
mentioned above). I agree with you that "scalar" would be a nice meta-type.
> And, if PHP evolves to allow for __toScalar(), then an object can
> represent itself as a scalar for those situations where the scalar type
> hint is required. I think this may be a bit much initially though (unless
> some clever bod has already worked all this out). Being able to cast an
> instance from type A to type B via __autocast_ where is the
> resultant type ... ha ha ... OK that really is just pushing things. Maybe.
>
> Going off-topic here, but I worry that __toScalar() would collide in a
messy way with __toString() (and other, future __to() behavior). Not
severely against it, mind you, but I think we (PHP) need to be cautious
about going down that road.
-Sara
P.S. - Your reply only went to me, but I assume you wanted to include
internals@ so I put them back in the To: line.
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
> While playing with GO I did found that this type of syntax is a bit better.
>
Yeah, we played with a few formats (including the one originally proposed
and found some issues (like specifying closures as return types: function
function($foo, $bar) ($foo) { return makeCallback($foo); } Even if you
add <> around the return type, that's still a bit.. weird.
> Since you brought up the discussion, would you think it would make
> more sense to actually start and integrate HHVM into PHP rather that
> patching it up?
>
HHVM isn't built on PHP (apart from a few very small pieces) so
"integrating" it would mean, well... replacing it. It's like suggesting to
integrate linux into windows. :p
> Or better yet, rewrite it with a HH VM in mind?
>
I do think we (again, wearing my PHP hat) should look at plugging in LLVM
or something similar. In my perfect world PHP and HHVM both have enough to
offer that users get to use the tool most appropriate for their needs. For
HHVM that means working on the build system and the runtime. For PHP that
means speeding up and extending the language. We'll never match because
the two projects don't agree on every piece of philosophy, but we can try
to keep close enough to avoid major issues for end users.
-Sara
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
Hello,
I'm new with php internal. Here is my first answer but i use php everyday.
I think that the return type is needed in php. When you make an interface,
why are you not sure of the return of the function made by the user ?
Of course you can specified it as comment but if you want to be sure of the
return you have to test it and when the class is implementing your
interface...
That's definitively weird, isn't it?
I use PHPStorm (and I'm probably not the only one here, haha) and love so
much the warning when I'm wrong with return type.
Why is it a feature of phpstorm and not of the language ? Weird. Again.
I hope i help !
Bye.
Le 10 juil. 2013 10:08, "Florin Patan" a écrit :
> On Wed, Jul 10, 2013 at 1:42 AM, Sara Golemon wrote:
> > I know this conversation kinda stopped a couple weeks ago, but I want to
> > throw into the ring that HHVM already has a syntax for return type
> hinting
> > and it'd be awesome if we (with my PHP hat on) brought the two
> > implementations together rather than take them further apart.
> >
> > In HHVM's case a function might look something like:
> >
> > function foo(SomeClass $bar, int $baz) : bool {
> >
> > }
> >
>
> Hi Sara,
>
>
> Thanks for the input.
> While playing with GO I did found that this type of syntax is a bit better.
> Since you brought up the discussion, would you think it would make
> more sense to actually start and integrate HHVM into PHP rather that
> patching it up?
> Or better yet, rewrite it with a HH VM in mind?
> I know and fully understand it's a gigantic task but at some point in
> a software lifecycle there's only so much patching up you can do
> before you can't patch it anymore.
> Thanks.
>
>
> Best regards,
> Florin
>
> Florin Patan
> https://github.com/dlsniper
> http://www.linkedin.com/in/florinpatan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
[PHP-DEV] Integrate HHVM into PHP (Was: Re: [PHP-DEV] Request for comments - new PHP feature: return typing)
Hello Florin, 2013/7/10 Florin Patan : > Since you brought up the discussion, would you think it would make > more sense to actually start and integrate HHVM into PHP rather that > patching it up? > Or better yet, rewrite it with a HH VM in mind? > I know and fully understand it's a gigantic task but at some point in > a software lifecycle there's only so much patching up you can do > before you can't patch it anymore. > Thanks. Not that this is not interesting, but this is deviating the discussion so much than the original thread that it is worth having it as it's own thread. Please, remember to change the subject if you start an off-topic discussion, it makes discussions easier to follow. Thanks, Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jul 10, 2013 at 1:42 AM, Sara Golemon wrote:
> I know this conversation kinda stopped a couple weeks ago, but I want to
> throw into the ring that HHVM already has a syntax for return type hinting
> and it'd be awesome if we (with my PHP hat on) brought the two
> implementations together rather than take them further apart.
>
> In HHVM's case a function might look something like:
>
> function foo(SomeClass $bar, int $baz) : bool {
>
> }
>
Hi Sara,
Thanks for the input.
While playing with GO I did found that this type of syntax is a bit better.
Since you brought up the discussion, would you think it would make
more sense to actually start and integrate HHVM into PHP rather that
patching it up?
Or better yet, rewrite it with a HH VM in mind?
I know and fully understand it's a gigantic task but at some point in
a software lifecycle there's only so much patching up you can do
before you can't patch it anymore.
Thanks.
Best regards,
Florin
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
> function foo(SomeClass $bar, int $baz) : bool {
>
> }
>
This does have the advantage that function declarations are still grepable.
In my experience this is one of the loudest complaints about previous ideas.
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
I know this conversation kinda stopped a couple weeks ago, but I want to
throw into the ring that HHVM already has a syntax for return type hinting
and it'd be awesome if we (with my PHP hat on) brought the two
implementations together rather than take them further apart.
In HHVM's case a function might look something like:
function foo(SomeClass $bar, int $baz) : bool {
}
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
Hi. At the moment we can type hint array, classes, interfaces, callable, etc. As PHP is loosely typed and has type juggling thinking of (or at least trying to get PHP to enforce) a particular type (string, int, float, boolean) would be the wrong way to go - too many different behaviours (block if not a suitable type, block if not a suitable castable value, nonblocking with auto juggling, etc.). But if we consider that type juggling is the domain of the type 'scalar', then this would/could act as a suitable hinter. If a method has been designed to accept a scalar, there is nothing to stop the passing in of a resource, callable, closure or object, etc. But with the type hint, in my head, it is now no different to any other type hint. scalar, callable, interface, class, array (and others I'm sure). This isn't about trying to cast the value to a type - PHP is intrinsically loosely typed and that is core to everything. But as the core can easily tell an array from a callable, then a scalar would seem to fit right in. And if we can have scalar type hinting, scalar return type hinting would/should also be possible. Is this a feasible option? -- Richard Quadling Twitter : @RQuadling EE : http://e-e.com/M_248814.html Zend : http://bit.ly/9O8vFY
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
Johannes,
2013/6/26 Johannes Schlüter :
> So a function author doesn't trust himself and therefore we change the
> language syntax?
In the following example:
class Foo {
public function bar($input) {
$return = Baz::foo($input);
if (!$return instanceof ReturnType)
trigger_error("Cannot divide by zero", E_USER_ERROR); //
or throwing some RuntimeException
return $return;
}
}
Baz class can be from a 3rd party software and I may want to enforce
the fact that my Foo::bar() method returns an instance of ReturnType
or throw an exception or trigger an error.
This is moez easily written with this proposition:
class Foo {
public function bar($input) {
return Baz::foo($input);
}
}
With the same reasoning you had, you would avoid using parameter type
hinting and interfaces for your own project if there's no other people
using it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 6:02 PM, Stas Malyshev wrote: > Hi! > >> Currently PHP doesn't support what could be a good feature for code >> quality, return typing (or if you prefer to call it: return type >> hinting). > > What changed since the last time we discussed this? > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 Hi, Well I don't want to sound disrespectful, but to be honest, nothing really. Just the year and the fact that I don't want to allow for double return types, like object or null or false, like in the other proposal, if you would read the gist. While I would like to have full type hinting available, including scalars as well, I think we could greatly benefit from it even without them. Like I've said, it's about code quality, something that PHP programmers lack today badly because PHP is so flexible (don't even try to argue with that). As for the argument of don't design features that are optional, like you've said in the past discussion, here's a optional feature that everyone uses it today: argument type hinting. Is it optional, yes? Could we live without it? Yes. Would everyone be sane without it? Not sure. PHP is too flexible for its own good. The fact that we have good use cases for such a feature, just look at the thread so far, makes is useful to consider. And I don't understand why having return typing would be such a bad thing when we already have argument typing, which is a half baked feature (even worst, no?) as it doesn't allow for scalar hinting. And just having this half baked feature in the language makes is very unattractive for some people and reduces the code quality, but for others it's extremely useful, do you want to argue that we don't need this because ? Best regards Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
Hi! > Currently PHP doesn't support what could be a good feature for code > quality, return typing (or if you prefer to call it: return type > hinting). What changed since the last time we discussed this? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 4:48 PM, Johannes Schlüter wrote: > On Wed, 2013-06-26 at 16:40 +0200, Ferenc Kovacs wrote: > > > > > > I think that the return typehints a bit easier topic than the input type > > hinting(for scalars), because that affects the caller, while return type > > hinting is more contained: you write the function, you put the return > > typehint there, if the method tries to return something else, then your > > code is at fault. > > So even if we would allow return typehints for scalars that would only > > affects those functions where the developer opts-in. > > So a function author doesn't trust himself and therefore we change the > language syntax? > > johannes > > or not trusting the subsystem that he/she calls, and he/she wants to make a hard promise about the return value. I could also mention, that this feature could be used in static analysis and IDEs(albeit most IDEs out there already supports docblocks). I'm not saying that this feature is a must, I just wanted to emphasize that it is a little bit less touchy subject than the (scalar) input typehints. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 3:35 PM, Julien Pauli wrote:
> On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT
> wrote:
>>
>> 2013/6/26 Maxwell :
>> > Sherif,
>> > I have to disagree with you on this in the same way that we have type
>> > hints
>> > for input variables on methods, this could also be useful.
>> > Consider an interface with a getter method defined. As it stands now in
>> > php, they're not entirely useful, since you can't define what type of
>> > object your expecting from the implementer. That greatly reduces the
>> > functionality of an interface and this proposal gives solution to that
>> > problem.
>> >
>> > Florin,
>> > I think the overall concept is good, I want to see something like this
>> > in
>> > the future, but I think this might be the wrong approach. I don't think
>> > we
>> > should be hinting primitives. if we're going to have a return type hint
>> > on
>> > a method, I would have it match the functionality of the input type
>> > hints
>> > for functions we already have, where you can hint at an instance of an
>> > object type, such as Iterator or StdClass, or an array, but not hint
>> > primitives such as int and string, like I currently see in the draft.
>> > Also, you should be aware that your proposed syntax for the return type
>> > (
>> > ) is interfering with:
>> > https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
>> > me.
>>
>> Thanks Maxwell, you summarized very well what I was thinking about it.
>> So +1 from me for the general feature at a first glance, but it should
>> then be very close to what is possible with input type hinting.
>>
>> It makes it possible to write interfaces that acts like specifications
>> and to easier the writing of:
>>
>> class Foo {
>> public function bar($input) {
>> $return = Baz::foo($input);
>> if (!$return instanceof ReturnType)
>> trigger_error("Cannot divide by zero", E_USER_ERROR); //
>> or throwing some RuntimeException
>>
>> return $return;
>> }
>> }
>>
>> to:
>>
>> class Foo {
>> public function bar($input) {
>> return Baz::foo($input);
>> }
>> }
>
>
> +1 for the global idea as this would help so much OO programs and framework
> based programs.
>
> But what Sherif said proves as well the limits of the idea. PHP is not
> strongly typed. So each check, should it be type hinting or return type
> hinting, has to be done at runtime , which is bad for performances.
>
> Not talking about the type juggling which could lead the programmer as
> shooting himself.
>
> Julien.Pauli
Hi,
Type juggling is explicitly not allowed in the draft and I would hope
it can remain the same in the final implementation.
That's actually one of the things I want to prevent.
I love PHP because of type juggling which can be very handy at times
but for such feature this would be a total no no.
As for limited applicability, I think that frameworks could benefit
greatly from this as well as systems where you really count on having
the least surprise possible from code. And as more people turn to PHP
to bootstrap their startup, idea or whatnot, having more code quality
features would only help the language to maintain its traction and
improve the life all-around.
Best regards
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 4:48 PM, Johannes Schlüter wrote: > On Wed, 2013-06-26 at 16:40 +0200, Ferenc Kovacs wrote: > >> > >> I think that the return typehints a bit easier topic than the input type >> hinting(for scalars), because that affects the caller, while return type >> hinting is more contained: you write the function, you put the return >> typehint there, if the method tries to return something else, then your >> code is at fault. >> So even if we would allow return typehints for scalars that would only >> affects those functions where the developer opts-in. > > So a function author doesn't trust himself and therefore we change the > language syntax? > > johannes > All, Thanks for the feedback so far. I've added the typing for scalars as I thought it would be nice to have them but if it's easier to start with supporting what we already have for argument hinting then it would be a great win for the language nonetheless. To address the performance concern issues, I think the performance issues should be very little, like a call to instanceof for example, but I can't say for sure. Of course benchmarks for the actual implementation will need to be made and a manual entry should note that using this feature might have a performance impact if really needed (as I would imagine in 15000 function calls, something that you might see in todays frameworks it could have a more visible impact). @johannes it's not about the author of the function doesn't trust itself, it's about I'm writing a interface and I expect to receive a array but someone returns a string or a single value. That's why I've said that the feature is more about code quality that new toys for developers. Those who opt-in for using this in interfaces would guarantee that every implementation of their interface would be consistent in return type, just like what we have today for arguments, where you can guarantee that you'll have the type you need in your method. If the feedback will be positive for this, as it is right now, I would also like to start working on a patch for this in 2-3 weeks maybe so this is a early request for help for anyone that could point me out in the right direction or champion this patch. I'll make another request when I'll be ready to start working on the patch. Best regards. Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, 2013-06-26 at 16:40 +0200, Ferenc Kovacs wrote: > > > I think that the return typehints a bit easier topic than the input type > hinting(for scalars), because that affects the caller, while return type > hinting is more contained: you write the function, you put the return > typehint there, if the method tries to return something else, then your > code is at fault. > So even if we would allow return typehints for scalars that would only > affects those functions where the developer opts-in. So a function author doesn't trust himself and therefore we change the language syntax? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
2013/6/26 Marco Pivetta : > What about disabling the check in some environments (prod)? It would work > like an assertion I suppose. (Feel free to shoot at me if you think it's a > bad idea) This is typically something that has always been rejected in the past. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 4:21 PM, Patrick ALLAERT wrote: > 2013/6/26 Julien Pauli : > > But what Sherif said proves as well the limits of the idea. PHP is not > > strongly typed. So each check, should it be type hinting or return type > > hinting, has to be done at runtime , which is bad for performances. > > It doesn't mean you have to use it, just that it might be used instead > of implementing a manual check in every function/method callers, or, > alternatively, in the function/method itself. > Being done at runtime by the language will for sure not be worst for > performance than doing it manually in pure PHP. > > > Not talking about the type juggling which could lead the programmer as > > shooting himself. > > Sure! Hence why *if* this is taken into account, it should really be > done the same way as it is done for input parameter hinting, to not > introduce what we already don't want there. > > I think that the return typehints a bit easier topic than the input type hinting(for scalars), because that affects the caller, while return type hinting is more contained: you write the function, you put the return typehint there, if the method tries to return something else, then your code is at fault. So even if we would allow return typehints for scalars that would only affects those functions where the developer opts-in. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
2013/6/26 Julien Pauli : > But what Sherif said proves as well the limits of the idea. PHP is not > strongly typed. So each check, should it be type hinting or return type > hinting, has to be done at runtime , which is bad for performances. It doesn't mean you have to use it, just that it might be used instead of implementing a manual check in every function/method callers, or, alternatively, in the function/method itself. Being done at runtime by the language will for sure not be worst for performance than doing it manually in pure PHP. > Not talking about the type juggling which could lead the programmer as > shooting himself. Sure! Hence why *if* this is taken into account, it should really be done the same way as it is done for input parameter hinting, to not introduce what we already don't want there. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On 26 June 2013 15:35, Julien Pauli wrote: > On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT >wrote: But what Sherif said proves as well the limits of the idea. PHP is not > strongly typed. So each check, should it be type hinting or return type > hinting, has to be done at runtime , which is bad for performances. > > Not talking about the type juggling which could lead the programmer as > shooting himself. > > Julien.Pauli > What about disabling the check in some environments (prod)? It would work like an assertion I suppose. (Feel free to shoot at me if you think it's a bad idea) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT wrote:
> 2013/6/26 Maxwell :
> > Sherif,
> > I have to disagree with you on this in the same way that we have type
> hints
> > for input variables on methods, this could also be useful.
> > Consider an interface with a getter method defined. As it stands now in
> > php, they're not entirely useful, since you can't define what type of
> > object your expecting from the implementer. That greatly reduces the
> > functionality of an interface and this proposal gives solution to that
> > problem.
> >
> > Florin,
> > I think the overall concept is good, I want to see something like this in
> > the future, but I think this might be the wrong approach. I don't think
> we
> > should be hinting primitives. if we're going to have a return type hint
> on
> > a method, I would have it match the functionality of the input type hints
> > for functions we already have, where you can hint at an instance of an
> > object type, such as Iterator or StdClass, or an array, but not hint
> > primitives such as int and string, like I currently see in the draft.
> > Also, you should be aware that your proposed syntax for the return type (
> > ) is interfering with:
> > https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
> > me.
>
> Thanks Maxwell, you summarized very well what I was thinking about it.
> So +1 from me for the general feature at a first glance, but it should
> then be very close to what is possible with input type hinting.
>
> It makes it possible to write interfaces that acts like specifications
> and to easier the writing of:
>
> class Foo {
> public function bar($input) {
> $return = Baz::foo($input);
> if (!$return instanceof ReturnType)
> trigger_error("Cannot divide by zero", E_USER_ERROR); //
> or throwing some RuntimeException
>
> return $return;
> }
> }
>
> to:
>
> class Foo {
> public function bar($input) {
> return Baz::foo($input);
> }
> }
>
+1 for the global idea as this would help so much OO programs and framework
based programs.
But what Sherif said proves as well the limits of the idea. PHP is not
strongly typed. So each check, should it be type hinting or return type
hinting, has to be done at runtime , which is bad for performances.
Not talking about the type juggling which could lead the programmer as
shooting himself.
Julien.Pauli
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
2013/6/26 Maxwell :
> Sherif,
> I have to disagree with you on this in the same way that we have type hints
> for input variables on methods, this could also be useful.
> Consider an interface with a getter method defined. As it stands now in
> php, they're not entirely useful, since you can't define what type of
> object your expecting from the implementer. That greatly reduces the
> functionality of an interface and this proposal gives solution to that
> problem.
>
> Florin,
> I think the overall concept is good, I want to see something like this in
> the future, but I think this might be the wrong approach. I don't think we
> should be hinting primitives. if we're going to have a return type hint on
> a method, I would have it match the functionality of the input type hints
> for functions we already have, where you can hint at an instance of an
> object type, such as Iterator or StdClass, or an array, but not hint
> primitives such as int and string, like I currently see in the draft.
> Also, you should be aware that your proposed syntax for the return type (
> ) is interfering with:
> https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
> me.
Thanks Maxwell, you summarized very well what I was thinking about it.
So +1 from me for the general feature at a first glance, but it should
then be very close to what is possible with input type hinting.
It makes it possible to write interfaces that acts like specifications
and to easier the writing of:
class Foo {
public function bar($input) {
$return = Baz::foo($input);
if (!$return instanceof ReturnType)
trigger_error("Cannot divide by zero", E_USER_ERROR); //
or throwing some RuntimeException
return $return;
}
}
to:
class Foo {
public function bar($input) {
return Baz::foo($input);
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
Sherif,
I have to disagree with you on this in the same way that we have type hints
for input variables on methods, this could also be useful.
Consider an interface with a getter method defined. As it stands now in
php, they're not entirely useful, since you can't define what type of
object your expecting from the implementer. That greatly reduces the
functionality of an interface and this proposal gives solution to that
problem.
Florin,
I think the overall concept is good, I want to see something like this in
the future, but I think this might be the wrong approach. I don't think we
should be hinting primitives. if we're going to have a return type hint on
a method, I would have it match the functionality of the input type hints
for functions we already have, where you can hint at an instance of an
object type, such as Iterator or StdClass, or an array, but not hint
primitives such as int and string, like I currently see in the draft.
Also, you should be aware that your proposed syntax for the return type (
) is interfering with:
https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
me.
On Wed, Jun 26, 2013 at 5:08 AM, Sherif Ramadan wrote:
> On Wed, Jun 26, 2013 at 5:50 AM, Florin Patan
> wrote:
>
> > Hello PHP internals,
> >
> >
> > Currently PHP doesn't support what could be a good feature for code
> > quality, return typing (or if you prefer to call it: return type
> > hinting).
> >
> > Since the procedure says that before any real RFC should be done, the
> > interest for this topic should be gauged, I've drafted something here:
> > https://gist.github.com/dlsniper/5863012
> >
> > The goals for this discussion are:
> > - gauge the interest in having such a feature in PHP.NEXT
> > - find weak spots in the draft
> > - find potential problems with the suggested way of doing the
> > implementation
> > - determine if the advantages would outweigh the disadvantages and
> > this should go forward as a RFC
> >
> > As you can see, the draft doesn't include any patch and since my C
> > skills are mostly nonexistent, I currently can't provide one
> > unfortunately. I would however love to do it with proper guidance from
> > someone that could spare some of his/her time to help me out.
> >
> > This said, thank you very much for your time, consideration and
> > feedback on this subject.
> >
> >
> > Best regards,
> > Florin
> >
> > Florin Patan
> > https://github.com/dlsniper
> > http://www.linkedin.com/in/florinpatan
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> PHP really doesn't need function return type declaration since PHP doesn't
> even support variable declaration. This would make sense in a language like
> C or C++ where the compiler can do static analyses to determine potential
> errors before compiling.
>
> Since PHP is a loosely typed dynamic language, however, the fact that a
> function can return something of any type is quite liberating and it turns
> out that you don't need the static analyses to write better code with PHP,
> because most of the errors static analyses helps you with aren't really the
> things you are most concerned with. For example consider the following bug:
>
> function userTimezone($userId, PDO $db) {
> $result = [];
> if (!($stmt = $db->prepare('SELECT `timezone` FROM users WHERE
> users.`id` = ?'))) {
> return false;
> }
> if ($stmt->execute([$userId])) {
> $result = $stmt->fetchAll(PDO::FETCH_ASSOC);
> }
> return array_pop($result);
> }
> ?>
>
> If in the above code PDO::prepare returns false (upon failure) for any
> reason $stmt will not be of the expected type. In that case the function
> returns a boolean false to indicate failure (or it can throw an exception
> as well). If the Exception is throw the function's return value is still
> implicitly null. However, the return type of the function isn't what we
> actually care about here, because it doesn't solve our real problem. The
> real problem we care about is the fact that the function failed and
> couldn't keep its promise. If we force the function to only return an array
> we can't tell the difference between an empty result set or a failure case
> unless we strictly stick to exceptions. In none of those cases was the
> function's return value type hint helpful.
>
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 5:50 AM, Florin Patan wrote:
> Hello PHP internals,
>
>
> Currently PHP doesn't support what could be a good feature for code
> quality, return typing (or if you prefer to call it: return type
> hinting).
>
> Since the procedure says that before any real RFC should be done, the
> interest for this topic should be gauged, I've drafted something here:
> https://gist.github.com/dlsniper/5863012
>
> The goals for this discussion are:
> - gauge the interest in having such a feature in PHP.NEXT
> - find weak spots in the draft
> - find potential problems with the suggested way of doing the
> implementation
> - determine if the advantages would outweigh the disadvantages and
> this should go forward as a RFC
>
> As you can see, the draft doesn't include any patch and since my C
> skills are mostly nonexistent, I currently can't provide one
> unfortunately. I would however love to do it with proper guidance from
> someone that could spare some of his/her time to help me out.
>
> This said, thank you very much for your time, consideration and
> feedback on this subject.
>
>
> Best regards,
> Florin
>
> Florin Patan
> https://github.com/dlsniper
> http://www.linkedin.com/in/florinpatan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
PHP really doesn't need function return type declaration since PHP doesn't
even support variable declaration. This would make sense in a language like
C or C++ where the compiler can do static analyses to determine potential
errors before compiling.
Since PHP is a loosely typed dynamic language, however, the fact that a
function can return something of any type is quite liberating and it turns
out that you don't need the static analyses to write better code with PHP,
because most of the errors static analyses helps you with aren't really the
things you are most concerned with. For example consider the following bug:
prepare('SELECT `timezone` FROM users WHERE
users.`id` = ?'))) {
return false;
}
if ($stmt->execute([$userId])) {
$result = $stmt->fetchAll(PDO::FETCH_ASSOC);
}
return array_pop($result);
}
?>
If in the above code PDO::prepare returns false (upon failure) for any
reason $stmt will not be of the expected type. In that case the function
returns a boolean false to indicate failure (or it can throw an exception
as well). If the Exception is throw the function's return value is still
implicitly null. However, the return type of the function isn't what we
actually care about here, because it doesn't solve our real problem. The
real problem we care about is the fact that the function failed and
couldn't keep its promise. If we force the function to only return an array
we can't tell the difference between an empty result set or a failure case
unless we strictly stick to exceptions. In none of those cases was the
function's return value type hint helpful.
[PHP-DEV] Request for comments - new PHP feature: return typing
Hello PHP internals, Currently PHP doesn't support what could be a good feature for code quality, return typing (or if you prefer to call it: return type hinting). Since the procedure says that before any real RFC should be done, the interest for this topic should be gauged, I've drafted something here: https://gist.github.com/dlsniper/5863012 The goals for this discussion are: - gauge the interest in having such a feature in PHP.NEXT - find weak spots in the draft - find potential problems with the suggested way of doing the implementation - determine if the advantages would outweigh the disadvantages and this should go forward as a RFC As you can see, the draft doesn't include any patch and since my C skills are mostly nonexistent, I currently can't provide one unfortunately. I would however love to do it with proper guidance from someone that could spare some of his/her time to help me out. This said, thank you very much for your time, consideration and feedback on this subject. Best regards, Florin Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
