Re: [PHP-DEV] Type hinting
Am 28.05.2010 20:07, schrieb Stas Malyshev: On top of that, your boilerplate throws exception. Strict typing would error out. That's very different thing (exceptions can be handled hierarchically, errors can't). So replacing that with strict type probably won't do the same. The optional scalar type hinting would raise a catchable fatal error that could be converted to an exception. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Commit messages and ChangeLog (Re: [PHP-DEV] ChangeLog)
On May 28, 2010, at 7:43 PM, Pierre Joye wrote: Is anybody using this file? If this is thee case could somebody then make sure it's being updated (and maybe take care of ChangeLog-200[6-9].gz being created) else I'd suggest dropping them. An outdated file might be confusing for users expecting content like we have in the NEWS file there. I do, what's about only changing how it is generated to generated changes since last release instead? I'd to add that unless we add everything in the NEWS file, the ChangeLog remains the only way to have a list of all changes (without doing manually). Isn't that what svn log -v now provides? The format is slightly different of course, but it does provide the same info. By without doing it manually, I meant when one fetches a release or a snapshot. The ChangeLog files aren't updated because no one ever ported the ChangeLog crons from CVS to SVN. It wouldn't be very difficult - in fact one of the open-source scripts already out there for the purpose would seem appropos, it just hasn't been done. They seem to be standard fare in FOSS projects, so I'm -1 for removing the functionality, but +1 for removing the useless archives from all active branches. I wish I could volunteer to do the port, but I have too much on my plate right now :( -- Gwynne smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] ChangeLog
2010/5/29 Johannes Schlüter johan...@schlueters.de: Hey, On Fri, 2010-05-28 at 23:50 +0200, Pierre Joye wrote: I'd to add that unless we add everything in the NEWS file, the ChangeLog remains the only way to have a list of all changes (without doing manually). Having the file is absolutely fine with me, while I can fulfill my needs with svn annotate and svn log. But if we ship it, it should be correct and at least since 5.2.0 we ship a wrong (not updated) file. And that I consider bad. So I ask somebody to either remove it or make sure it's updated (automatically or by adding instructions to README.RELEASE_PROCESS) in all places. Maybe simply do it at release time? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ChangeLog
Hey, On Fri, 2010-05-28 at 23:50 +0200, Pierre Joye wrote: I'd to add that unless we add everything in the NEWS file, the ChangeLog remains the only way to have a list of all changes (without doing manually). Having the file is absolutely fine with me, while I can fulfill my needs with svn annotate and svn log. But if we ship it, it should be correct and at least since 5.2.0 we ship a wrong (not updated) file. And that I consider bad. So I ask somebody to either remove it or make sure it's updated (automatically or by adding instructions to README.RELEASE_PROCESS) in all places. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
My biggest issue as a user is the fatal errors. Why are we blowing up on something that should throw some kind of useful argument exception? I end up in my applications using instanceof everywhere because their is important cleanup to be done before the end of the request. For example I can't afford for php to just blow up in our account setup script, we are reaching out to multiple non-transactional external resources. Some of our long running command line processes have the same issue. I am all for type hinting but the fatal errors or catchabale fatal errors are just silly. Exceptions make so much more sense to me. -Chris On May 29, 2010 10:19 AM, Zeev Suraski z...@zend.com wrote: At 11:33 29/05/2010, Sebastian Bergmann wrote: The optional scalar type hinting [snip] Sebastian, I understand why proponents of strict typing are putting 'optional' next to it to suggest that people don't have to use it, ergo those who don't intend to use it shouldn't care. As numerous people (myself included) explained, any feature we add to the language ends up being necessary for users to understand - far beyond those who may have wanted to intentionally use it in the first place. Of course it's optional. Using for loops is also optional - nobody forces you to use them. Even functions are optional. Objects? Completely optional. Why ont add some optional Ruby syntax support, along with optional Perl syntax support? Optional malloc() free() functions? Optional pointer arithmetic? Those who don't want to use it wouldn't have to. Let's not fool ourselves by saying an optional feature doesn't bring clutter to the language. It does. Auto-converting type hints included - but unlike strict type checking - the value they bring is arguably higher than the clutter complexity associated with them. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.ne...
Re: [PHP-DEV] Type hinting
At 20:28 29/05/2010, Chris Stockton wrote: My biggest issue as a user is the fatal errors. Why are we blowing up on something that should throw some kind of useful argument exception? I end up in my applications using instanceof everywhere because their is important cleanup to be done before the end of the request. For example I can't afford for php to just blow up in our account setup script, we are reaching out to multiple non-transactional external resources. Some of our long running command line processes have the same issue. I am all for type hinting but the fatal errors or catchabale fatal errors are just silly. Exceptions make so much more sense to me. IMHO we shouldn't be getting to any kind of fatal error/exception situation, which is why I like the idea of auto-conversion plus E_STRICT in the 'weird conversion' scenarios (the API function shouldn't care - it got what it asked for; The caller would get notified that he passed something that probably doesn't make sense). But as to why errors and not exceptions - we have a guideline that language constructs don't through exceptions. It's up to users whether they want to use exceptions or not. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
At 20:34 29/05/2010, Zeev Suraski wrote: At 20:28 29/05/2010, Chris Stockton wrote: My biggest issue as a user is the fatal errors. Why are we blowing up on something that should throw some kind of useful argument exception? I end up in my applications using instanceof everywhere because their is important cleanup to be done before the end of the request. For example I can't afford for php to just blow up in our account setup script, we are reaching out to multiple non-transactional external resources. Some of our long running command line processes have the same issue. I am all for type hinting but the fatal errors or catchabale fatal errors are just silly. Exceptions make so much more sense to me. IMHO we shouldn't be getting to any kind of fatal error/exception situation, which is why I like the idea of auto-conversion plus E_STRICT in the 'weird conversion' scenarios (the API function shouldn't care - it got what it asked for; The caller would get notified that he passed something that probably doesn't make sense). But as to why errors and not exceptions - we have a guideline that language constructs don't through exceptions. It's up to users whether they want to use exceptions or not. s/through/throw, oops :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Sat, May 29, 2010 at 7:34 PM, Zeev Suraski z...@zend.com wrote:
At 20:28 29/05/2010, Chris Stockton wrote:
My biggest issue as a user is the fatal errors. Why are we blowing up on
something that should throw some kind of useful argument exception? I end up
in my applications using instanceof everywhere because their is important
cleanup to be done before the end of the request. For example I can't afford
for php to just blow up in our account setup script, we are reaching out to
multiple non-transactional external resources. Some of our long running
command line processes have the same issue. I am all for type hinting but
the fatal errors or catchabale fatal errors are just silly. Exceptions
make so much more sense to me.
IMHO we shouldn't be getting to any kind of fatal error/exception
situation, which is why I like the idea of auto-conversion plus E_STRICT in
the 'weird conversion' scenarios (the API function shouldn't care - it got
what it asked for; The caller would get notified that he passed something
that probably doesn't make sense).
But as to why errors and not exceptions - we have a guideline that language
constructs don't through exceptions. It's up to users whether they want to
use exceptions or not.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'm thinking about the type hinting in php for a while, and there is my 2
cent about this.
As an API developer, I need a way, to easily force my input into a proper
type, with ease, without dataloss, and without code duplication.
As an API consumer, I don't want to bother much about my API calls, as long
as my passed arguments are in the accepted form(I don't want to
convert '123' into 123), and I don't want to create yet another custom error
handler, to fetch the potentially triggered errors, and I cannot allow, that
one unhandled catcable fatal error ruin my application.
So basically I need type jugling(weak type hinting) + exceptions instead of
catchable errors.
But I know that the core should't throw exceptions, so we can't go to that
direction.
What if we introduce a new spl interface, which propose auto boxing for the
scalar types + exceptions for the type missmatch.
I mean, if you call that class with scalar arguments, the scalar values will
be converted to the matching spl class instance.
This way, you could hint your types for the interface without forcing the
api consumer to bother to convert '123' to 123 before passing it to the
method.
But if the consumer passes '123abc' when I'm hinting SplInt, then it will
throw an InvalidArgumentException or such.
So for example:
class foo implements WeakTypeHinting{
public function bar(SplInt $baz){
return $baz++;
}
}
$foo = new foo;
echo $foo-bar(1);
// 2
echo $foo-bar('2');
// 3
echo $foo-bar('3a')
// InvalidArgumentException
Feel free to discuss.
Tyrael
