[PHP-DEV] Moving PHP documentation to Git repository
Hi internals. What do you think about moving the PHP documentation to a Git repository, mirrored on Github? Doing this would make it possible for everybody to extend the documentation easily by creating pull requests. Today one has to get an SVN account to edit the docu or you have to use https://edit.php.net/ which does not work as expected (at least for me when I tried to update some German documentation). My changes have not been integrated for some months (I had to write an email to somebody of the doc team to apply the changes). Symfony does it this way (see https://github.com/symfony/symfony-docs/) and I like it very much. It is really easy to extend/update parts of the docu which are not complete or outdated and I am sure that it is comfortable and timesaving for the doc team, too. What do you think? Best regards Christian
Re: [PHP-DEV] Re: Announcing RFC 'Anonymous Catches'
Hi,
Another two cents here.
* Skipping binding a parameter to the exception would make debugging
harder. When you're stepping through code that isn't working correctly to
find a problem and then it throws an Exception which is caught in catch
block that doesn't name it e.g.
try
{
$connection = $this-connectToServer();
$data = $this-prepareData();
// lots more lines
// of code
$response = $this-getResponse();
$connection-close();
}
catch (UnexpectedException)
{
$this-retry(3);//breakpoint here, how to inspect Exception?
}
You can't actually inspect the caught exception, unless you knew where it
was going to be caught ahead of time, and went in to modify the code to
name the Exception before you started debugging.
* The RFC says Runtime needs to perform less checks. - I'm not an expert
on the performance cost of Exceptions but surely that must be irrelevant?
Exceptions should only happen in exceptional circumstances, so shaving a
couple of cycles from code that rarely gets called should not be a factor
in deciding this RFC.
* Throwing and catching raw \Exception classes is in general a bad pattern
and should only be rarely done, to avoid uncaught errors being shown to
end-users. It's a common anti-pattern for junior developers to catch (and
throw) \Exception rather than extending specific Exception classes for the
specific Exception that could occur.
I don't think we should be making it be the easier choice to write bad code
than to write good code.
I also don't think that it's a problem for someone coming from another
language to learn what the root Exception class is for a language. It's not
as if it's an obscure, hardly used part of the language - it's really quite
important.
Although not having to write the Exception type would make it easier for
some programmers to learn PHP, for people learning PHP as their first
language or people coming from other languages where the Exception type has
to be set, having the Exception type be optional would be one more thing to
learn.
Joost Koehoorn wrote:
the type of an exception mostly tells enough about what happened
I think that's only true when it's an 'expected' exception, e.g. the
ConnectionLostException from the RFC, where you almost always just want to
retry the operation.
When it's an unexpected exception e.g. caused by trying to read a corrupted
file, you almost always need to have at least log the message and in some
cases it is necessary to have additional information that can be presented
to the user in a nice format, rather than just the raw message itself. e.g.
class InsufficientCreditsException extends \Exception {
protected $creditsRequired;
public function __construct($creditsRequired, $message = null, $code =
0, Exception $previous = null){...}
}
allows an InsufficientCreditsException exception to bubble up from the call
to the external API all the way to the UI where '$creditsRequired' is
formatted nicely for the user.
Although with the RFC you could have each style of catch statement where
needed, having two different ways of writing catch statements would be
confusing when it doesn't need to be.
In summary, although this would make PHP easier to learn for a few people,
I think it makes debugging and writing good consistent code be harder, as
well as making PHP harder to learn for other people.
cheers
Dan
Re: [PHP-DEV] Moving PHP documentation to Git repository
On 25.06.2013 08:46, Christian Stoller wrote: Hi internals. What do you think about moving the PHP documentation to a Git repository, mirrored on Github? Doing this would make it possible for everybody to extend the documentation easily by creating pull requests. Today one has to get an SVN account to edit the docu or you have to use https://edit.php.net/ which does not work as expected (at least for me when I tried to update some German documentation). My changes have not been integrated for some months (I had to write an email to somebody of the doc team to apply the changes). Symfony does it this way (see https://github.com/symfony/symfony-docs/) and I like it very much. It is really easy to extend/update parts of the docu which are not complete or outdated and I am sure that it is comfortable and timesaving for the doc team, too. What do you think? Best regards Christian As one who's had very similar experiences when trying to update some documentation via. edit.php.net (no feedback, no integration etc.) I would really love to see this feature. best regards christoph -- Christoph Rosse Softwaredevelopment | Operations 2bePUBLISHED Internet Services Austria GmbH Brünner Straße 85/2, 1210 Wien Tel.: 0043.1.9971500 Fax.: 0043.1.997150066 E-mail: cro...@2bepublished.at Skype: christoph.rosse Home: http://www.2bepublished.at -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving PHP documentation to Git repository
On 25/06/13 07:46, Christian Stoller wrote: What do you think about moving the PHP documentation to a Git repository, mirrored on Github? Doing this would make it possible for everybody to extend the documentation easily by creating pull requests. Today one has to get an SVN account to edit the docu or you have to use https://edit.php.net/ which does not work as expected (at least for me when I tried to update some German documentation). My changes have not been integrated for some months (I had to write an email to somebody of the doc team to apply the changes). Symfony does it this way (see https://github.com/symfony/symfony-docs/) and I like it very much. It is really easy to extend/update parts of the docu which are not complete or outdated and I am sure that it is comfortable and timesaving for the doc team, too. +1 Regards Terry Ellison
Re: [PHP-DEV] Moving PHP documentation to Git repository
On Tue, Jun 25, 2013 at 9:45 AM, Christoph Rosse cro...@2bepublished.at wrote: On 25.06.2013 08:46, Christian Stoller wrote: Hi internals. What do you think about moving the PHP documentation to a Git repository, mirrored on Github? Doing this would make it possible for everybody to extend the documentation easily by creating pull requests. Today one has to get an SVN account to edit the docu or you have to use https://edit.php.net/ which does not work as expected (at least for me when I tried to update some German documentation). My changes have not been integrated for some months (I had to write an email to somebody of the doc team to apply the changes). Symfony does it this way (see https://github.com/symfony/symfony-docs/) and I like it very much. It is really easy to extend/update parts of the docu which are not complete or outdated and I am sure that it is comfortable and timesaving for the doc team, too. What do you think? Best regards Christian As one who's had very similar experiences when trying to update some documentation via. edit.php.net (no feedback, no integration etc.) I would really love to see this feature. Really? That's not too good as we have been promoted this tool for some time already. However adding the php-doc list to CC so they can answer and give us some feedback/info. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving PHP documentation to Git repository
and now with the right name... On Tue, Jun 25, 2013 at 10:18 AM, Pierre Joye pierre@gmail.com wrote: On Tue, Jun 25, 2013 at 9:45 AM, Christoph Rosse cro...@2bepublished.at wrote: On 25.06.2013 08:46, Christian Stoller wrote: Hi internals. What do you think about moving the PHP documentation to a Git repository, mirrored on Github? Doing this would make it possible for everybody to extend the documentation easily by creating pull requests. Today one has to get an SVN account to edit the docu or you have to use https://edit.php.net/ which does not work as expected (at least for me when I tried to update some German documentation). My changes have not been integrated for some months (I had to write an email to somebody of the doc team to apply the changes). Symfony does it this way (see https://github.com/symfony/symfony-docs/) and I like it very much. It is really easy to extend/update parts of the docu which are not complete or outdated and I am sure that it is comfortable and timesaving for the doc team, too. What do you think? Best regards Christian As one who's had very similar experiences when trying to update some documentation via. edit.php.net (no feedback, no integration etc.) I would really love to see this feature. Really? That's not too good as we have been promoted this tool for some time already. However adding the php-doc list to CC so they can answer and give us some feedback/info. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- 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] Moving PHP documentation to Git repository
On Tue, Jun 25, 2013 at 10:18 AM, Pierre Joye pierre@gmail.com wrote: On Tue, Jun 25, 2013 at 9:45 AM, Christoph Rosse cro...@2bepublished.at wrote: On 25.06.2013 08:46, Christian Stoller wrote: Hi internals. What do you think about moving the PHP documentation to a Git repository, mirrored on Github? Doing this would make it possible for everybody to extend the documentation easily by creating pull requests. Today one has to get an SVN account to edit the docu or you have to use https://edit.php.net/ which does not work as expected (at least for me when I tried to update some German documentation). My changes have not been integrated for some months (I had to write an email to somebody of the doc team to apply the changes). Symfony does it this way (see https://github.com/symfony/symfony-docs/ ) and I like it very much. It is really easy to extend/update parts of the docu which are not complete or outdated and I am sure that it is comfortable and timesaving for the doc team, too. What do you think? Best regards Christian As one who's had very similar experiences when trying to update some documentation via. edit.php.net (no feedback, no integration etc.) I would really love to see this feature. Really? That's not too good as we have been promoted this tool for some time already. However adding the php-doc list to CC so they can answer and give us some feedback/info. Cheers, -- Pierre @pierrejoye | http://www.libgd.org there were some initial discussion and work done on moving the docs to git, see https://wiki.php.net/doc/git http://git.php.net/?p=web/doc-editor.git;a=shortlog;h=refs/heads/GIT_READY http://marc.info/?l=phpdocm=132321958514090w=2 but it seems that we lost momentum, but I think that this isn't a technical problem, just lack of interest (svn and the online editor just works for the regulars), maybe others have different opinions on this. and I'm fairly certain that the slow integration of the patches also not a technical problem as well. I think that it would worth more to figure out and fix the underlying problem which causes the current delay for integrating the incoming patches. moving to git/github without fixining the underlying issue would only mean that we switched to pull requests not getting accepted in a timely manner(which is unfortunately common with our other git/github repos). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Moving PHP documentation to Git repository
On Tue, 2013-06-25 at 08:46 +0200, Christian Stoller wrote: Hi internals. What do you think about moving the PHP documentation to a Git repository, mirrored on Github? Doing this would make it possible for everybody to extend the documentation easily by creating pull requests. Basically that is good. To the best of my knowledge the issue though, is not will but time. Migrating the docs is not just converting the repo, like with PECL repos but changing the supporting infrastructure. For instance there are tools which help to identify outdated translations and the mentioned editor which all have to be adopted. If you want to help there the docs group certainly would welcome it. That aside: resources is also the issue with the online editor. We have too few people working on docs, so in the end it doesn't make much difference if they don't have time to review edit.php.net or github. (while reviewing on edit.php.net has the benefit that it can directly validate the docbook, github can't) johannes (who is one of the bad people not really actively helping with docs) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving PHP documentation to Git repository
On Tue, Jun 25, 2013 at 5:10 AM, Johannes Schlüter johan...@schlueters.dewrote: On Tue, 2013-06-25 at 08:46 +0200, Christian Stoller wrote: Hi internals. What do you think about moving the PHP documentation to a Git repository, mirrored on Github? Doing this would make it possible for everybody to extend the documentation easily by creating pull requests. Basically that is good. To the best of my knowledge the issue though, is not will but time. Migrating the docs is not just converting the repo, like with PECL repos but changing the supporting infrastructure. For instance there are tools which help to identify outdated translations and the mentioned editor which all have to be adopted. If you want to help there the docs group certainly would welcome it. That aside: resources is also the issue with the online editor. We have too few people working on docs, so in the end it doesn't make much difference if they don't have time to review edit.php.net or github. (while reviewing on edit.php.net has the benefit that it can directly validate the docbook, github can't) I'm all for docs moving to git, but I have to say it would be a purely cosmetic move. This won't change the pace at which our patches are getting through or the fact that the lack of man-power can be overwhelming for docs. The documentation is over 10,000 pages and growing with multiple translations. PHP also suffers from a problem where patches go into php-src that never get into the changelog for some reason and end up becoming documentation bugs. I've definitely fixed a number of those in bugs.php.netand I know I'm not the only one that has complained about this problem. It's hard to keep up with the pace at which PHP changes and consistently document that. I will say that we do need more people helping out with docs before we should consider investing the resources in moving docs to git. Again, this move would only serve to be superficial in the long-run. johannes (who is one of the bad people not really actively helping with docs) So YOU'RE the one! (*kidding* it's been a while since I've made some commits myself) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC Proposal: New assign value operator
Hi everyone,
I've got an idea for an RFC proposal and from reading the instructions it
looks like I should run it past you guys first.
I have not made any contributions to PHP before although I have made some
custom modifications in house in the past and while I'm no longer familiar
with the PHP code base I am confident I have the skills to implement this
should it be accepted.
What I want to propose is a new assignment operator which rather than
setting the variable to completely new value it would update the value
while maintaining the type.
The main motivation for this is for easy assignment to value objects aka
assignment operator overloading via a magic method (prehaps called
__assign).
Here is an example ( for now I will use the PASCAL style assignment
operator := as the new operator as it is a know assignment operator and
currently not used in PHP):
// For a class defined like so...
class MoneyValue
{
protected $amount;
public function __assign($value)
{
$this-amount = $value;
}
}
// The amount could then be assigned using the new operator like this
$price = new MoneyValue();
$price := 29.99;
While the primary focus would be for assignment operator overloading as I
just displayed in the previous example, for consistency it could be used
with scalar values to preserve type like so:
// $str is now a string
$str = 'Original String';
// Using the new assignment variable would cast the value being assigned to
the variable's type
// (in this case a string). So
$str := 7;
// Would be the equivalent to
//
// $str = (string) 7;
//
// $str === 7
Another quick example:
$num = 5;
$num := '12';
// Equivalent to
//
// $num = (int) '12';
//
// $num === 12;
So what do you guys think?
If I get a good response I'll look into how to create a proper RFC and
start trying to work out how to implement it.
Many thanks and look forward to some responses,
Tom
--
PLEASE NOTE: For support requests please
use supp...@scl.co.uk instead of emailing
staff directly, this way your request is likely to
be dealt with more efficiently.
Tom Oram - SCL Internet Services
PO Box 8, Cardigan, Ceredigion, SA41 3YA
Website: http://www.scl.co.uk/
Tel: +44 (0) 1239 622 411
Fax: +44 (0) 1239 622428
Company Reg. No. 2441708
Re: [PHP-DEV] Moving PHP documentation to Git repository
On 06/25/2013 11:10 AM, Johannes Schlüter wrote: That aside: resources is also the issue with the online editor. We have too few people working on docs, so in the end it doesn't make much difference if they don't have time to review edit.php.net or github. (while reviewing on edit.php.net has the benefit that it can directly validate the docbook, github can't) i have to confess that i've only shown the documentation very minimal love in recent years (damn, YEARS! ... when i first started, or better was forced, to use and fix PHP this was supposed to be a 6 month job only ...) In the situations where i'd actually might have time and leisure to do so the web editor fails me though: * on the train or when otherwise mostly offline it doesn't work for obvious reasons * in front of the TV or when being stuck in hotel rooms the lack of screen real estate makes edit.php a not tooo plearurable experience it is usable on small screens somehow, but for a good experience you should have a large primary screen to run it on and a secondary for looking things up (dictionary/translator, source code, ...) (and yes, my multitasking capabilities are far from perfect, but they are for sure good enough for doing translations and watching TV at the same time for most of todays TV content) Doing things the old way on the other hand is severely blocked by me not wanting to touch SVN in any way anymore unless i'm payed for it (i'd even prefer doing CVS again instead of too-little-too-late SVN, but that's a different story ...) johannes (who is one of the bad people not really actively helping with docs) Is there an official community for that which i could join? ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Moving PHP documentation to Git repository
That aside: resources is also the issue with the online editor. We have too few people working on docs, so in the end it doesn't make much difference if they don't have time to review edit.php.net or github. (while reviewing on edit.php.net has the benefit that it can directly validate the docbook, github can't) The difference is that the Git repo with its translations could be viewed very easily via Github. And it is possible to comment on pull requests or discuss them. Plus: Others can see what pull requests have been created already and you can see at a first glance how many open pull requests there are. When I used the online editor, I changed something but I didn't know if it has been saved correctly (especially when the changes have not been deployed after weeks) or if there is somebody who has ever seen my changes. In Github you see what you have changed. That motivates to work on ;-) Christian
[PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
Hi all,
I just published an RFC that proposes to add catch-statement without needing
to specify a variable, and support for fully anonymous catches.
Details can be found at:
https://wiki.php.net/rfc/anonymous_catch
Regards,
Joost Koehoorn
Hi.
I am not sure about complete anonymous catch statement (like try { } catch {
}), but I really like the proposal for omitting the exception variable.
Because in frameworks like Symfony there are defined and used a lot of special
exception types for each cases.
Here's an example that shows what I mean:
try {
$foo-authenticate($user);
} catch (BadCredentialsException) {
echo Bad credentials;
} catch (InactiveAccount) {
echo Sorry, your account is not active anymore.;
} catch (CurlErrorOnAuthService) {
echo Please try again later, the login service is currently unavailable.;
} catch (Exception) {
echo bla blubb;
}
In such a case you do not need any `$e`variable. Netbeans for example always
highlight's these variables because it is not used anywhere. But I think it
looks a bit cleaner if the variable could be omitted, if it's not needed ;-)
Best regards
Christian
This is exactly the reason, yes!
As stated in the RFC, I think it's best that we consider the two ways
separately. Omitting the variable is a much smaller change (and requires very
little code changes) than having a fully anonymous catch.
I originally dived into this because of a question of Phil Sturgeon on twitter,
requesting for making the variable optional. I took it one step further and
made the whole thing optional, but surely we can decide to only make the
variable optional, I can see how it's bad programming practice to have fully
anonymous blocks (even though sometimes they may be used). Just throwing this
out here to see what you think about it.
Regards,
Joost
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
I, too, believes that omitting the exception variable is great.
In addition, anonymous catch blocks will shorten the code of catch
(Exception $e) so... is just a simpler way of writing - and that's what
PHP agenda aiming for, doesn't it? be a friendly and readable language.
Reading
try {
$foo-bar();
} catch {
show404Page();
}
For example, is readable, short and not contain any extra variables that we
didn't used.
On Tue, Jun 25, 2013 at 2:18 PM, Joost Koehoorn joost.koeho...@gmail.comwrote:
Hi all,
I just published an RFC that proposes to add catch-statement without
needing to specify a variable, and support for fully anonymous catches.
Details can be found at:
https://wiki.php.net/rfc/anonymous_catch
Regards,
Joost Koehoorn
Hi.
I am not sure about complete anonymous catch statement (like try { } catch
{ }), but I really like the proposal for omitting the exception variable.
Because in frameworks like Symfony there are defined and used a lot of
special exception types for each cases.
Here's an example that shows what I mean:
try {
$foo-authenticate($user);
} catch (BadCredentialsException) {
echo Bad credentials;
} catch (InactiveAccount) {
echo Sorry, your account is not active anymore.;
} catch (CurlErrorOnAuthService) {
echo Please try again later, the login service is currently
unavailable.;
} catch (Exception) {
echo bla blubb;
}
In such a case you do not need any `$e`variable. Netbeans for example
always highlight's these variables because it is not used anywhere. But I
think it looks a bit cleaner if the variable could be omitted, if it's not
needed ;-)
Best regards
Christian
This is exactly the reason, yes!
As stated in the RFC, I think it's best that we consider the two ways
separately. Omitting the variable is a much smaller change (and requires
very little code changes) than having a fully anonymous catch.
I originally dived into this because of a question of Phil Sturgeon on
twitter, requesting for making the variable optional. I took it one step
further and made the whole thing optional, but surely we can decide to only
make the variable optional, I can see how it's bad programming practice to
have fully anonymous blocks (even though sometimes they may be used). Just
throwing this out here to see what you think about it.
Regards,
Joost
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] DNS RoundRobin handling
Hi all, I'm having trouble to utilize DNS RoundRobin. It's described in StackOverflow question: http://stackoverflow.com/questions/17209912/php-not-respecting-roundrobin-in-dns In short: file_get_contents, SOAP extension always connect to the first (lowest) IP address, and gethostbyname resolves the address correctly using RoundRobin algorithm (ping, wget, nslookup, etc. works with RoundRobin too). Is this desired behaviour (if so - why) or should I report a bug? Thanks. -- Tomasz Sawicki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Announcing RFC 'Anonymous Catches'
On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
joost.koeho...@gmail.com wrote:
Hi all,
I just published an RFC that proposes to add catch-statement without needing
to specify a variable, and support for fully anonymous catches.
Details can be found at:
https://wiki.php.net/rfc/anonymous_catch
Regards,
Joost Koehoorn
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
First of, considering that you would only save three characters by
having the ' $e' removed, I don't see how it would make things easier
to learn. I mean if you can't learn that maybe you should look into
something else that's not related to programming :)
Having this: * Avoid indication of a specific exception type could
be considered as a possible bad practice, just as you were saying that
catch(\Exception $e) is. Also, it you can add the other ten characters
that you save when typing \Exception but does it worth it?
How do you plan to handle this: * Note that there may only be one
anonymous catch-statement, and it has to be the last one. Throw a
fatal error? If not then what, nothing?
What are the performance downsides of having this check in place? I do
understand that you mentioned: * Runtime needs to perform less
checks. No need to update the symboltable, no need to check exception
inheritance. but wouldn't that be replaced by what I'm asking about?
If I could read/understand C better I wouldn't ask for this.
Could you also please elaborate this: * Better possibilities for
static analysis tools?
As for: * People from other languages such as C#, Python and Ruby
expect this to work I think it is often pointed out when requesting
features such as function/method return type hinting (I'm planning a
RFC for that), named parameters, threads and other stuff that this
ain't C#, Java, Python, Ruby or whatnot so.. what's the official
position on this? Do we want PHP like the other languages or not (and
I won't say more on this here/now)?
Also, the code sample is not that good. If you want to reflect a good
quality scenario, it should be more like:
while (true) {
try
{
$this-connectToServer();
break;
}
catch (ConnectionFailedException)
{
sleep(3);
}
}
And I think the RFC should also add a: Disadvantages section so that
it could help people looking on it and proving that you've done all
the research correctly.
Thanks
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] Re: Announcing RFC 'Anonymous Catches'
On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
joost.koeho...@gmail.com wrote:
Hi all,
I just published an RFC that proposes to add catch-statement without needing
to specify a variable, and support for fully anonymous catches.
Details can be found at:
https://wiki.php.net/rfc/anonymous_catch
Regards,
Joost Koehoorn
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
First of, considering that you would only save three characters by
having the ' $e' removed, I don't see how it would make things easier
to learn. I mean if you can't learn that maybe you should look into
something else that's not related to programming :)
I don't recall mentioning that this makes PHP easier to learn. It's really
about avoiding introducing unused variables, which is currently required
because the language simply requires and identifier there.
Having this: * Avoid indication of a specific exception type could
be considered as a possible bad practice, just as you were saying that
catch(\Exception $e) is. Also, it you can add the other ten characters
that you save when typing \Exception but does it worth it?
I don't really care about saving a few characters, that's not what this is
about. I can see that a catch-all can be considered bad practice, but perform a
Github search for `catch (Exception $e)` and find very much instances of this
usage. In all of these situations it seems that only specific exceptions are
caught, but that's not actually the case. We currently see that requiring an
Exception type doesn't really enforce good programming practice, most instances
simply use `(\Exception $e)` and have the same bad practice.
How do you plan to handle this: * Note that there may only be one
anonymous catch-statement, and it has to be the last one. Throw a
fatal error? If not then what, nothing?
In my current implementation, it's simply a syntax error and thus will never
result in compiled code.
What are the performance downsides of having this check in place? I do
understand that you mentioned: * Runtime needs to perform less
checks. No need to update the symboltable, no need to check exception
inheritance. but wouldn't that be replaced by what I'm asking about?
If I could read/understand C better I wouldn't ask for this.
As it's directly enforced by the language grammer, Bison (the parser generator)
won't accept invalid use of the anonymous catch, and thus no additional runtime
checks are necessary.
Could you also please elaborate this: * Better possibilities for
static analysis tools?
This is about unused variables. When you use an IDE or tools such as PHPMD,
they will warn you about unused variables in your code. Exception variables are
simply required by the language, even though you may not actually use them,
thus generating unused variables warnings (or the analyser doesn't flag
exception variables, in which case you miss unused variables) which you cannot
solve.
As for: * People from other languages such as C#, Python and Ruby
expect this to work I think it is often pointed out when requesting
features such as function/method return type hinting (I'm planning a
RFC for that), named parameters, threads and other stuff that this
ain't C#, Java, Python, Ruby or whatnot so.. what's the official
position on this? Do we want PHP like the other languages or not (and
I won't say more on this here/now)?
I can agree with you here, PHP has its own things and is different from other
languages for a reason. I'm mentioning this because I can see how Python/Ruby
developers working with PHP may find this a flaw in PHP, giving them another
reason to bitch about PHP.
Also, the code sample is not that good. If you want to reflect a good
quality scenario, it should be more like:
while (true) {
try
{
$this-connectToServer();
break;
}
catch (ConnectionFailedException)
{
sleep(3);
}
}
And I think the RFC should also add a: Disadvantages section so that
it could help people looking on it and proving that you've done all
the research correctly.
I couldn't really come up with disadvantages. Anonymous catch-statements may be
considered bad coding practice, but look at the amount of developers simply
using `Exception` as the type which is the same bad practice, only with the
false indication that a specific type is expected. By allowing for not
specifying the type at all, it's immediately clear that the intention was to
not care about the type at all.
Thanks
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] Re: [PHP-DOC] RE: [PHP-DEV] Moving PHP documentation to Git repository
Hi, Just my two cent. The online editor is actually a greats tool to edit commit some changes into the documentation for *all* translations. Please, don't view only the EN part of the documentation. If we plan to move to GitHub, there were a lot of work to do into the editor to continue to use it. And I'm really not sur that I have the time to do it. I know there is actually a bug witch cause that the change aren't deployed as they should be. I try to find some time to work on it, and I'm sur that i can provide a fix in some few weeks. Just be patient with this, sorry. So, as it was sayed, the delay between reviewed a patch with the editor or the delay to review un pull request with GitHub is the same : if there are no people to do the first, it's the same for the second ;) Grest, Yannick 2013/6/25 Christian Stoller stol...@leonex.de That aside: resources is also the issue with the online editor. We have too few people working on docs, so in the end it doesn't make much difference if they don't have time to review edit.php.net or github. (while reviewing on edit.php.net has the benefit that it can directly validate the docbook, github can't) The difference is that the Git repo with its translations could be viewed very easily via Github. And it is possible to comment on pull requests or discuss them. Plus: Others can see what pull requests have been created already and you can see at a first glance how many open pull requests there are. When I used the online editor, I changed something but I didn't know if it has been saved correctly (especially when the changes have not been deployed after weeks) or if there is somebody who has ever seen my changes. In Github you see what you have changed. That motivates to work on ;-) Christian
Re: [PHP-DEV] Announcing RFC 'Anonymous Catches'
On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
joost.koeho...@gmail.comwrote:
Hi all,
I just published an RFC that proposes to add catch-statement without
needing to specify a variable, and support for fully anonymous catches.
Details can be found at:
https://wiki.php.net/rfc/anonymous_catch
No opinion on leaving off $e, but I'm against the generic catch{} statement.
Looking at the Python docs, they don't see particularly fond of the
wildcard-except themselves:
The last except clause may omit the exception name(s), to serve as a
wildcard. Use this with extreme caution, since it is easy to mask a real
programming error in this way! It can also be used to print an error
message and then re-raise the exception (allowing a caller to handle the
exception as well):
Furthermore a wildcard-catch is bad for forwards compatibility. Right now
all exceptions extend Exception, but this doesn't have to stay so. E.g.
Python has additional exceptions above that for handling stuff like signal
interrupts or die()s and I think it's not unlikely that we will introduce
something like this in PHP too. You normally do *not* want to catch those,
but a wildcard-catch would do this.
Thus I think it's better to stays explicit and keep it at catch(Exception).
Nikita
[PHP-DEV] RFC: Protocol Type Hinting
Hey all, I want to throw out this draft RFC to get the concept floating around and get feedback early. https://wiki.php.net/rfc/protocol_type_hinting There are still open questions, and a more complete (and cleaner) implementation will be needed before officially proposing it, but I wanted to get the concept out as soon as possible. What do you think? Thanks! Anthony
Re: [PHP-DEV] Moving PHP documentation to Git repository
On 2013-06-25, Ferenc Kovacs tyr...@gmail.com wrote: there were some initial discussion and work done on moving the docs to git, see https://wiki.php.net/doc/git http://git.php.net/?p=3Dweb/doc-editor.git;a=3Dshortlog;h=3Drefs/heads/GIT_= READY http://marc.info/?l=3Dphpdocm=3D132321958514090w=3D2 but it seems that we lost momentum, but I think that this isn't a technical problem, just lack of interest (svn and the online editor just works for the regulars), maybe others have different opinions on this. and I'm fairly certain that the slow integration of the patches also not a technical problem as well. I think that it would worth more to figure out and fix the underlying problem which causes the current delay for integrating the incoming patches= . moving to git/github without fixining the underlying issue would only mean that we switched to pull requests not getting accepted in a timely manner(which is unfortunately common with our other git/github repos). generally speaking i am in favor in moving more and more to git. we lost momentum and I am stuck with a new job and RMing. I can help with technical questions but don't hav emuch time implementing it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
On Tue, 25 Jun 2013 19:57:15 +0400, Anthony Ferrara ircmax...@gmail.com wrote: Hey all, I want to throw out this draft RFC to get the concept floating around and get feedback early. https://wiki.php.net/rfc/protocol_type_hinting There are still open questions, and a more complete (and cleaner) implementation will be needed before officially proposing it, but I wanted to get the concept out as soon as possible. What do you think? Thanks! Anthony Hey, That's great, just great, I have no more words :3 By looking at the diff I see it will only work for type-hints in functions/methods. Could we also see something like $var instanceof ProtoInterface? I fear it can't be done this way because of parser limitations, but I believe this feature would be as useful as type-hinting in functions. And again, that's great :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
Nikita, Thanks for the response! By looking at the diff I see it will only work for type-hints in functions/methods. Could we also see something like $var instanceof ProtoInterface? I fear it can't be done this way because of parser limitations, but I believe this feature would be as useful as type-hinting in functions. Well, we could add a new construct $var protocolof Proto or $var actsasa Proto or something. I wouldn't conflate instanceof with this behavior for two reason: instanceof implies type checking. This is not type checking. Second, instanceof can be used with a variable ont he right side. SO this could get awkward... As to the name of the construct, I am at a loss... But I'm sure we can come up with something interesting... Anthony
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Moving PHP documentation to Git repository
On Tue, Jun 25, 2013 at 1:05 PM, David Soria Parra d...@php.net wrote: On 2013-06-25, Ferenc Kovacs tyr...@gmail.com wrote: there were some initial discussion and work done on moving the docs to git, see https://wiki.php.net/doc/git http://git.php.net/?p=3Dweb/doc-editor.git;a=3Dshortlog;h=3Drefs/heads/GIT_= READY http://marc.info/?l=3Dphpdocm=3D132321958514090w=3D2 but it seems that we lost momentum, but I think that this isn't a technical problem, just lack of interest (svn and the online editor just works for the regulars), maybe others have different opinions on this. and I'm fairly certain that the slow integration of the patches also not a technical problem as well. I think that it would worth more to figure out and fix the underlying problem which causes the current delay for integrating the incoming patches= . moving to git/github without fixining the underlying issue would only mean that we switched to pull requests not getting accepted in a timely manner(which is unfortunately common with our other git/github repos). generally speaking i am in favor in moving more and more to git. we lost momentum and I am stuck with a new job and RMing. I can help with technical questions but don't hav emuch time implementing it. I'm also in favor of moving to Git. The amount of contributions to the brazilian portuguese translation would be much more significant if we had a streamlined contribution system, which pull requests on Github allow quite easily. What are the current problems of Git migration?
Re: [PHP-DEV] RFC: Protocol Type Hinting
On Tue, Jun 25, 2013 at 11:57 PM, Anthony Ferrara ircmax...@gmail.com wrote: Hey all, I want to throw out this draft RFC to get the concept floating around and get feedback early. https://wiki.php.net/rfc/protocol_type_hinting There are still open questions, and a more complete (and cleaner) implementation will be needed before officially proposing it, but I wanted to get the concept out as soon as possible. What do you think? Hey: Just one question, usage? why we need this? (run-time check is slow and I can not think out of a case then we must need it) Go does that is not a reason... thanks Thanks! Anthony -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
On 25 June 2013 18:32, Laruence larue...@php.net wrote:
On Tue, Jun 25, 2013 at 11:57 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
https://wiki.php.net/rfc/protocol_type_hinting
What do you think?
Hey:
Just one question, usage? why we need this? (run-time check is
slow and I can not think out of a case then we must need it)
I'd rather see a proposal for:
$foo-setLogger(new Logger() {
function log($message) {
fprintf(STDERR, %s\n, $message);
}
});
Just sayin...
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving PHP documentation to Git repository
On Tue, Jun 25, 2013 at 12:45 AM, Christoph Rosse cro...@2bepublished.at wrote: On 25.06.2013 08:46, Christian Stoller wrote: Hi internals. What do you think about moving the PHP documentation to a Git repository, mirrored on Github? Doing this would make it possible for everybody to extend the documentation easily by creating pull requests. Today one has to get an SVN account to edit the docu or you have to use https://edit.php.net/ which does not work as expected (at least for me when I tried to update some German documentation). My changes have not been integrated for some months (I had to write an email to somebody of the doc team to apply the changes). Symfony does it this way (see https://github.com/symfony/symfony-docs/) and I like it very much. It is really easy to extend/update parts of the docu which are not complete or outdated and I am sure that it is comfortable and timesaving for the doc team, too. What do you think? Best regards Christian As one who's had very similar experiences when trying to update some documentation via. edit.php.net (no feedback, no integration etc.) I would really love to see this feature. Could you guys fill out http://www.php.net/git-php.php please? - It is also important to use the correct mailinglist :) As for the move to Git, if someone is willing to do the work then by all means go for it - but I don't understand how that is some magic fix? You are complaining about patches being available but not applied, how would github fix that? Doesn't that just add yet another platform that we don't have manpower to manage? Also, our current tooling will need a *lot of work*, but the online editor and our revision control for translations to name two big jobs. The docs and websites don't operate in the same way as internals@ does. We employ a lot of trust in these neck of the woods, people with karma to do stuff can actually do what they think is best without going through daunting process, so once you've been around for a little while and get a neat idea you want to work on, you don't have to ask anyone or get permission - just do it! If you want to work on git support for our tools, go for it. There isn't any point in discussing things and coming to decisions when there is noone that is able or willing to do the work. If there work is there however.. :D -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
Hi! In such a case you do not need any `$e`variable. Netbeans for example always highlight's these variables because it is not used anywhere. But I think it looks a bit cleaner if the variable could be omitted, if it's not needed ;-) I don't think we need to change the language because Netbeans can't figure out how catch blocks work. This change doesn't provide any functionality that wasn't available before it, and does not make the code clearer - on the contrary, IMO it makes debugging harder and people reading the code more confused. In PHP, we always valued clarity over brevity, and I think we should keep it this way. -- 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] RFC: Protocol Type Hinting
Anthony, I like it. The one thing that is lacking in the PHP ecosystem is some kind of support for a Gentleman's Agreement when it comes to APIs. I am very much opposed to central bodies of code and/or shared interfaces (like the PSR-3's et. al.) for seemingly simple and cross-cutting APIs. An idea I had been kicking around, if yours in full does not pass the muster, was adding a function to do something similar (also requires changes to the instanceof checks in the engine): register_compatible_types($yourType, $myType); which basically would allow any of $myTypes (My\LoggerInterface) to pass when the engine is testing for instanceof $yourType. I do hope we get something like either of these solutions for PHP.next. -ralph On 6/25/13 10:57 AM, Anthony Ferrara wrote: Hey all, I want to throw out this draft RFC to get the concept floating around and get feedback early. https://wiki.php.net/rfc/protocol_type_hinting There are still open questions, and a more complete (and cleaner) implementation will be needed before officially proposing it, but I wanted to get the concept out as soon as possible. What do you think? Thanks! Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On 25 June 2013 20:17, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I don't think we need to change the language because Netbeans can't
figure out how catch blocks work. This change doesn't provide any
functionality that wasn't available before it, and does not make the
code clearer - on the contrary, IMO it makes debugging harder and people
IMO actually it *makes* the code clearer, because $ignoredException is
not used, though a variable name like $ignored is self-explanatory,
too.
reading the code more confused. In PHP, we always valued clarity over
brevity, and I think we should keep it this way.
Duh, I find that statement a bit brave, though ;)
.oO(__{get,set,call,etc…}, object operators)
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Announcing RFC 'Anonymous Catches'
On 25 June 2013 17:07, Nikita Popov nikita@gmail.com wrote:
No opinion on leaving off $e, but I'm against the generic catch{} statement.
I second the concerns about empty catch{}.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Announcing RFC 'Anonymous Catches'
On 25 June 2013 17:07, Nikita Popov nikita@gmail.com wrote:
No opinion on leaving off $e, but I'm against the generic catch{} statement.
I second the concerns about empty catch{}.
--
Regards,
Mike
As most of you seem to discard the idea about and empty catch (I can see why,
no problems), maybe it's best to focus on only leaving of the variable then,
that's something most of you seem to agree with, until now.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
On 6/25/13 10:57 AM, Anthony Ferrara wrote:
Hey all,
I want to throw out this draft RFC to get the concept floating around and
get feedback early.
https://wiki.php.net/rfc/**protocol_type_hintinghttps://wiki.php.net/rfc/protocol_type_hinting
There are still open questions, and a more complete (and cleaner)
implementation will be needed before officially proposing it, but I wanted
to get the concept out as soon as possible.
What do you think?
Thanks!
Anthony
I did like the concept, however I'd like to double-check if I didn't missed
anything.
I don't see the main reason, to create a protocol syntax if you're only
verify that a specific class implements a specific method.
For instance:
interface IStoreableObject {
function save($key, $value);
function fetch($key);
function exists($key);
function count();
}
interface IQueryable {
function where($expression);
function orderBy($expression);
function limit($min, $max);
}
I can create a class that implements these two interfaces, such as
class DbObject implements IStorableObject, IQueryable { }
and then in my function test if these interfaces was implemented by using
instanceof.
This was a quick setup for my question:
If you allow in the protocol to specify only ONE class/interface, I don't
see any reason to use it. Today we can use type-hinting and the instanceof
operator.
However, If you allows using the protocol syntax to test against multiple
interfaces, for instance
function fetchSomeData($identifier, IStorableObject, IQueryable $object) {
}
It will be a great addition. So can you clarify yourself?
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
Hi! IMO actually it *makes* the code clearer, because $ignoredException is not used, though a variable name like $ignored is self-explanatory, too. It's not used by you - which btw is usually not a good idea - if you've got an exception, you usually should somehow react to it - at least log it or something, that's what the exceptions are for, if the situation does not require special handling it shouldn't be an exception. But it may be very useful for debugging, for example. Especially if somebody other than you looks at this code and tries to figure out what is going on. Removing vital information - like ability to see which exception was thrown - just to save 3 keystrokes - looks like a very misguided idea to me. -- 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] RE: Announcing RFC 'Anonymous Catches'
Regarding all of the discussion about the unused variable: If your catch blocks are too long or too complicated to be able to tell that the variable is unused, then I highly suggest you refactor that section. --- To me, the only maybe-useful portion of this discussion would be the empty catch which is more clear that it is a final resort catch than just catching \Exception. Apparently the opinions on this are quite divided, though.
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On Tue, Jun 25, 2013 at 3:50 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! IMO actually it *makes* the code clearer, because $ignoredException is not used, though a variable name like $ignored is self-explanatory, too. It's not used by you - which btw is usually not a good idea - if you've got an exception, you usually should somehow react to it - at least log it or something, that's what the exceptions are for, if the situation does not require special handling it shouldn't be an exception. But it may be very useful for debugging, for example. Especially if somebody other than you looks at this code and tries to figure out what is going on. Removing vital information - like ability to see which exception was thrown - just to save 3 keystrokes - looks like a very misguided idea to me. Not to down-play the importance of what you're saying, since I fully agree with it, but he is saying that this isn't a key-stroke saving proposition. If I'm to understand this RFC correctly, it is nothing more than a random suggestion someone posed in the form of a tweet and the author is saying why not add it since it's not hard to implement. So in summation this is one of those nice to have features that has little cost and very little benefit. And I'm referring only to making the Exception variable optional (not the anonymous catch -- I'm entirely opposed to that part). So this entire discussion can be summed up nicely with Let's make the variable optional because... why not?.
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On 25 juni 2013 at 22:06:40, Sherif Ramadan (theanomaly...@gmail.com) wrote: On Tue, Jun 25, 2013 at 3:50 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! IMO actually it *makes* the code clearer, because $ignoredException is not used, though a variable name like $ignored is self-explanatory, too. It's not used by you - which btw is usually not a good idea - if you've got an exception, you usually should somehow react to it - at least log it or something, that's what the exceptions are for, if the situation does not require special handling it shouldn't be an exception. But it may be very useful for debugging, for example. Especially if somebody other than you looks at this code and tries to figure out what is going on. Removing vital information - like ability to see which exception was thrown - just to save 3 keystrokes - looks like a very misguided idea to me. Not to down-play the importance of what you're saying, since I fully agree with it, but he is saying that this isn't a key-stroke saving proposition. If I'm to understand this RFC correctly, it is nothing more than a random suggestion someone posed in the form of a tweet and the author is saying why not add it since it's not hard to implement. So in summation this is one of those nice to have features that has little cost and very little benefit. And I'm referring only to making the Exception variable optional (not the anonymous catch -- I'm entirely opposed to that part). So this entire discussion can be summed up nicely with Let's make the variable optional because... why not?. Correct. The tweet was actually a serious request and grounded (see http://news.php.net/php.webmaster/16092 as an earlier response to you). So the reason to make it optional is not really why not?, there is some reasoning behind it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
Hi! Hey all, I want to throw out this draft RFC to get the concept floating around and get feedback early. https://wiki.php.net/rfc/protocol_type_hinting I'm not sure I understand why it is good to have this. This way of checking interfaces is very expensive (since you need to scan the function table) and relies on function names instead of explicit programmer's intent to validate the API (i.e. it assumes if two classes have method named open() this method does the same thing and the classes can be used interchangeably). Since you can easily add implements to your class to declare implementation of a specific protocol, why you need less safe and more computationally expensive way? Explicit declaration of interface has value way beyond mere checking function names - it is a contract that you agree to when you write implements ThisInterface. Absent that, you code starts making assumptions that are very dangerous. Taking the example of the logger here, suppose I make my logger classes work with this API: $log-error(...), $log-info(...), $log-debug(...). Pretty standard way of doing it. This is usually done by __call. Now, when I declare that class implements Logger, I either require __call or just rely on the fact that if you said implements Logger then you know what Logger means and that it should accept the methods above and do the right thing. However, if I use protocol typing (please dispose with hinting, we really should stop dragging around this unfortunate misnomer) then what would we look for in such class? Would we just accept any class? Any class that implements __call? Also this setup would be rather fragile as absent formal declaration of interface in the implementing class, it is very easy to miss changes in the interface, and since there's no explicit link between implementing class and the interface, no tool can warn you about that change in the interface until you try to use the object and it starts failing. With explicit declaration any good IDE will tell you your implementation is missing a method, and even missing that you'd be told about the class no longer being good immediately on loading, not when you try to use it. Also note that unlike the interface check, this check would also force loading the checked interface (since you can't check the methods without having it loaded) which provides additional performance drag. -- 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] RE: Announcing RFC 'Anonymous Catches'
Hi! If I'm to understand this RFC correctly, it is nothing more than a random suggestion someone posed in the form of a tweet and the author is saying why not add it since it's not hard to implement. So in summation Well, here we go - this is why not add it, because it makes working with such code harder without actually benefiting anybody. So this entire discussion can be summed up nicely with Let's make the variable optional because... why not?. Why not is usually not a very good principle of language design, IMO. -- 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] RE: Announcing RFC 'Anonymous Catches'
On Tue, 2013-06-25 at 13:19 -0700, Stas Malyshev wrote: Hi! If I'm to understand this RFC correctly, it is nothing more than a random suggestion someone posed in the form of a tweet and the author is saying why not add it since it's not hard to implement. So in summation Well, here we go - this is why not add it, because it makes working with such code harder without actually benefiting anybody. +1 Right now I set a breakpoint in my editor and look at an exception even if it is not used, in future I'd have to change the code for that. So this entire discussion can be summed up nicely with Let's make the variable optional because... why not?. Why not is usually not a very good principle of language design, IMO. +100 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
Laruence,
Hey:
Just one question, usage? why we need this? (run-time check is
slow and I can not think out of a case then we must need it)
In practice, the run-time check shouldn't be that slow. In fact, I just did
a quick micro-benchark without actually implementing caching, and it's only
8% slower than an interface check. To put that in perspective, it adds on
average .387e-8 seconds per function call.
And that's without caching.
With caching, it should be no slower than a standard interface. In fact, it
could potentially be *faster* than an interface. The primary reason is that
the interface check happens at class definition time regardless of if it's
used or not. A cached protocol check would only be run when it's actually
hinted against.
So this does have the potential to actually increase the performance of a
codebase overall. So no, run-time checks are not really slow (they are no
more expensive than compile-time checks) as long as we can cache them
(still working on an effective cache now)...
As a proof-of-concept, I implemented a primitive cache. Here's the results
comparing an Interface check to a Protocol check and Native:
Interface in 0.50202393531799 seconds, 5.0202393531799E-7 seconds per run
Protocol in 0.48089909553528 seconds, 4.8089909553528E-7 seconds per run
Native in 0.3850359916687 seconds, 3.850359916687E-7 seconds per run
Now, Interface and protocol area always within about 2% of each other, and
which is faster changes per run, so I think it's safe to say this method is
not slow...
Go does that is not a reason...
I never said it was. I quoted it to show one inspiration for the idea.
As far as what the use-case is, there are a few:
1. Library implementers don't need to declare a dependency for a third
party library to use the interface from it.
This may sound trivial, but imagine this. Right now Zend and Symfony have
very similar providers for certain tasks. One of the ones that comes to
mind (besides logging) is caching. If you want to use a Zend component in
an Symfony app while still using caching today, you'd need to shim together
an adapter to satisfy the zend cache interface with the symfony cache
interface. Which means your project now depends on all three, as well as
requiring the zend cache code for the sole purpose of loading the interface
required by the component.
That's loading a LOT of code that you don't need, just to avoid having to
setup two caches...
Instead, the zend component could depend on the narrow api that it needs.
It only calls the -get($key) and -set($key, $value) methods, so create a
(new?) interface with that limited API, and then type against it as a
protocol. Now that interface still would need to be loaded, but the Symfony
class can resolve that interface directly. Without the need to load
anything from Zend cache (said caching interface doesn't need to be there)
or wire anything else for you.
This may seem like a triviality, but it's actually quite significant.
Because...
2. It's dependency inversion applied to the type system.
Think of it like this. Dependency Injection is dependency inversion, it
pushes the requirement to resolve a dependency onto the creator instead of
on the object itself.
Protocols are also dependency inversion, it pushes the requirement to
determine if a dependency is resolve onto the receiver instead of the
creator of the object.
It is *not* a replacement for interfaces. It's not intended to be. Instead,
it's useful along side for cases when you want interoperability and
duck-style-typing without the overhead of coupling the packages together
via interfaces.
3. It allows avoiding interface-hell
Right now, every time you want to create a polymorphic dependency, you need
to create an interface for it to allow for others to resolve that with a
class from a different tree. This can lead to situations where you have
literally dozens of interfaces which you may or may not need. Additionally,
you're put in a position by classes like PDO where you can't have a
polymorphic dependency because there's no interface defined.
This change allows for using a Class as the protocol, so you could
type-hint against the API of a class without needing to create a separate
interface for it. This wouldn't be useful for something you substitute
often, but would be VERY useful for libraries which wrap dependencies that
aren't changed often, but may need to be. So instead of creating a PDO
wrapper just to add a series of interfaces for it, just hint against PDO.
That way you're getting an object that looks like PDO, but doesn't need to
be PDO if you don't want it to be...
There are definitely more, but the first one I think is the big one. It
decouples while still providing interface safety...
Anthony
PS: here's the code for said benchmark:
interface Foo {
public function foo();
}
class Bar {
public function foo() {}
}
class Baz implements Foo {
public function foo() {}
}
function
Re: [PHP-DEV] RFC: Protocol Type Hinting
Stas, I'm not sure I understand why it is good to have this. This way of checking interfaces is very expensive (since you need to scan the function table) and relies on function names instead of explicit programmer's intent to validate the API (i.e. it assumes if two classes have method named open() this method does the same thing and the classes can be used interchangeably). Since you can easily add implements to your class to declare implementation of a specific protocol, why you need less safe and more computationally expensive way? See my reply to Laruence, it's not more expensive... As far as relying on function names instead of programmer's intent, that's absolutely true. It's (at least partially) called Duck Typing, and it's a perfectly valid practice with a lot of practicers. As far as you can easily add implements, that ignores the relationship where you may not own all of your code. I know I've been in many situations where I've just needed to add an interface to a class, except that I didn't own that class. Which led me to either drop the type-hint entirely, or do some nasty work-around. Explicit declaration of interface has value way beyond mere checking function names - it is a contract that you agree to when you write implements ThisInterface. Absent that, you code starts making assumptions that are very dangerous. Yes, implementing an interface is about more than just validating APIs. Which is why this proposal doesn't intend to replace the existing functionality. Instead it augments it. It opens the possibilities for more flexible behavior when you need it, instead of simply boxing everything into the dogma of contract-style development (which for the record, I am a fan of)... Taking the example of the logger here, suppose I make my logger classes work with this API: $log-error(...), $log-info(...), $log-debug(...). Pretty standard way of doing it. This is usually done by __call. Now, when I declare that class implements Logger, I either require __call or just rely on the fact that if you said implements Logger then you know what Logger means and that it should accept the methods above and do the right thing. However, if I use protocol typing (please dispose with hinting, we really should stop dragging around this unfortunate misnomer) then what would we look for in such class? Would we just accept any class? Any class that implements __call? Why not? Seriously, why not? Remember, our compiler is not running through every possible permutation of objects to try to figure out which can be fed where. The object still has to come from a programmer wiring it in at some stage. And if a programmer decides that they want a class which implements __call to resolve for their particular method, why is that a bad thing? And if you're maintaining a library where you just care that there's an object that has __call, then let the user pass any class. Why bother type-hinting against a specific interface when all you really care about is the method... This gets down to a deeper philosophy. Control when you need it, but freedom where you don't. Not everyone is going to want to program like this. But the point is that a lot of people do today, and why not offer some engine level help to them...? Also this setup would be rather fragile as absent formal declaration of interface in the implementing class, it is very easy to miss changes in the interface, and since there's no explicit link between implementing class and the interface, no tool can warn you about that change in the interface until you try to use the object and it starts failing. With explicit declaration any good IDE will tell you your implementation is missing a method, and even missing that you'd be told about the class no longer being good immediately on loading, not when you try to use it. Absolutely! Which is why there are two very important things to keep in mind here: 1. Protocols are intended to resolve a minimal interface. You should hint against the smallest possible area that your particular method/class needs. If your function only calls a single method, then the protocol hint interface should have only that single method (within reason at least). This is an application of the Interface Segregation Principle. You should keep interfaces as small and narrow and purpose built as possible. 2. Yes, it does limit the usefulness of static analysis. But then again, the vast majority of the PHP language (especially the type system) prevents that already. Considering that the PHP philosophy is that if it looks like a scalar, it's a string, wouldn't protocols be arguably more along the lines of the php way than the current object system? Also note that unlike the interface check, this check would also force loading the checked interface (since you can't check the methods without having it loaded) which provides additional performance drag. Well, it doesn't really provide a performance
Re: [PHP-DEV] RFC: Protocol Type Hinting
Hi! This may sound trivial, but imagine this. Right now Zend and Symfony have very similar providers for certain tasks. One of the ones that comes to mind (besides logging) is caching. If you want to use a Zend component in an Symfony app while still using caching today, you'd need to shim together an adapter to satisfy the zend cache interface with the symfony cache interface. Which means your project now depends on all three, as well as requiring the zend cache code for the sole purpose of loading the interface required by the component. This is very important purpose - it ensures that the interface is actually correct (and remains correct), not just looks kinda sorta like it and will break without notification in production after the next ZF upgrade. Instead, the zend component could depend on the narrow api that it needs. It only calls the -get($key) and -set($key, $value) methods, so create a (new?) interface with that limited API, and then type against it as a Do you really want to accept any object that implements methods named get and set there, even if they don't have anything to do with caching at all? What about an object that implements __call - would you accept it too? If not - why not, you certainly can call get and set on it? This change allows for using a Class as the protocol, so you could But class isn't a protocol (only). If you say you've got PDO object, you expect it to be PDO object with all that docs say PDO object does, not only functions with names that looks like ones PDO object would have. I don't see what could I do with object all I know about is that it has method query. Who knows what that query method might do? -- 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] RFC: Protocol Type Hinting
On Wed, Jun 26, 2013 at 1:16 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! This may sound trivial, but imagine this. Right now Zend and Symfony have very similar providers for certain tasks. One of the ones that comes to mind (besides logging) is caching. If you want to use a Zend component in an Symfony app while still using caching today, you'd need to shim together an adapter to satisfy the zend cache interface with the symfony cache interface. Which means your project now depends on all three, as well as requiring the zend cache code for the sole purpose of loading the interface required by the component. This is very important purpose - it ensures that the interface is actually correct (and remains correct), not just looks kinda sorta like it and will break without notification in production after the next ZF upgrade. I, too, believes that it can be very handy. However, how we should enforce that the users will have someting like a gentelmen code and won't create their own protocol just like they've done with interfaces? There should be a way to distinguish them from interfaces and say This is the protocol for implementing a Logger (for instance) you should not implement your own protocol for Logger because this is the 'official' one... Instead, the zend component could depend on the narrow api that it needs. It only calls the -get($key) and -set($key, $value) methods, so create a (new?) interface with that limited API, and then type against it as a Do you really want to accept any object that implements methods named get and set there, even if they don't have anything to do with caching at all? What about an object that implements __call - would you accept it too? If not - why not, you certainly can call get and set on it? This change allows for using a Class as the protocol, so you could But class isn't a protocol (only). If you say you've got PDO object, you expect it to be PDO object with all that docs say PDO object does, not only functions with names that looks like ones PDO object would have. I don't see what could I do with object all I know about is that it has method query. Who knows what that query method might do? -- 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] RFC: Protocol Type Hinting
Hi! See my reply to Laruence, it's not more expensive... I don't see how you can see it's not - it does method matching on every call. It just doesn't make sense that doing something N times is faster than doing something 1 time. That may be true only if you load classes you don't ever need (no autoloader? why?) - but even in this case your model still has to load the class once the typing statement is encountered (actually, once it is compiled if inheritance is in place since you have to check it against inherited interface to see if the inheriting interface did not change it in incompatible way). As far as you can easily add implements, that ignores the relationship where you may not own all of your code. I know I've been in many situations where I've just needed to add an interface to a class, except that I didn't own that class. Which led me to either drop the type-hint entirely, or do some nasty work-around. If you don't control the code, how can you ensure it actually does what your contract requires it to do - and keeps doing it in the next version? If you can't ensure it - what these checks are worth? What exactly will you be checking and what value would you derive from these checks that would not be present otherwise? Why not? Seriously, why not? Because check that says accept any object that has __call doesn't seem very useful for me. What exactly is it checking? This gets down to a deeper philosophy. Control when you need it, but freedom where you don't. Not everyone is going to want to program like this. But the point is that a lot of people do today, and why not offer some engine level help to them...? We already have support in the engine for them. Typing in PHP is not mandatory, never was and I sincerely hope never will be. So you can pass any object anywhere. What exactly checking for __call adds there? 1. Protocols are intended to resolve a minimal interface. You should hint against the smallest possible area that your particular method/class needs. If your function only calls a single method, then the protocol hint interface should have only that single method (within reason at least). If you need one method, why not check for one method? Would you create interface for any combination of methods you might call and add new ones as you change the APIs or add functionality? That'd be the real interface hell... 2. Yes, it does limit the usefulness of static analysis. But then again, the vast majority of the PHP language (especially the type system) prevents that already. Considering that the PHP philosophy is that if Not true, any IDE worth its bytes can and does easily alert you when you forget to implement certain method in a class, given interface declaration. If you change the interface, it is easy to locate every class that needs amending. Even without IDE's help, loading these classes would immediately error out, thus alerting you on the problem, so even minimal coverage test system would easily deal with it. With undeclared interfaces, on the other hand, the first time you know about it is when you use that particular class in a particular place that new function is actually used. So unless you have 100% coverage, that'd be in production. it looks like a scalar, it's a string, wouldn't protocols be arguably more along the lines of the php way than the current object system? Not really, because scalars are quite easily convertible (arrays excluded - Array conversion should have been an error from the start) with meaningful results. Converting DOMXPath into PDO_ODBC doesn't really produce a meaningful result, even if both may have method called query. -- 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] RFC: Protocol Type Hinting
Stas,
On Tue, Jun 25, 2013 at 6:16 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
This may sound trivial, but imagine this. Right now Zend and Symfony have
very similar providers for certain tasks. One of the ones that comes to
mind (besides logging) is caching. If you want to use a Zend component in
an Symfony app while still using caching today, you'd need to shim
together
an adapter to satisfy the zend cache interface with the symfony cache
interface. Which means your project now depends on all three, as well as
requiring the zend cache code for the sole purpose of loading the
interface
required by the component.
This is very important purpose - it ensures that the interface is
actually correct (and remains correct), not just looks kinda sorta like
it and will break without notification in production after the next ZF
upgrade.
Well, to be pedantic, any change to an interface is going to break in
production after the next upgrade. No matter what you're doing. Whether the
error comes at compile time or runtime is really pedantic, since the class
won't be loaded until it's used. So you may not hit it at compile time for
1 million page views anyway...
Instead, the zend component could depend on the narrow api that it needs.
It only calls the -get($key) and -set($key, $value) methods, so create
a
(new?) interface with that limited API, and then type against it as a
Do you really want to accept any object that implements methods named
get and set there, even if they don't have anything to do with
caching at all? What about an object that implements __call - would you
accept it too? If not - why not, you certainly can call get and set on it?
Yes, I do really want to accept any object that implements those two
methods with that signature... Because if it looks like a Duck, that's
good enough for what I'm using it for.
Remember, the compiler isn't deciding what object to pass in. A human is.
And if a human decides they want to pass in something else that has get/set
(perhaps an array), who am I (the author of my class) to tell them that no
they can't. I can only write my intent.
Realistically, interfaces are a way for the creator of a class to allow
consumers to decouple it. Protocols are a way for consumers of a class to
decouple it themselves.
Both times, it's a human doing it. Both times it's the *same* human. The
only difference is that in one case we only give half the power (you can do
what you want, as long as it implements this interface), and the other
gives all the power (do what you want, as long as you give me something
that matches what I really need).
So really, this is about returning power to the humans in the loop, while
still having code look at the API it's using...
This change allows for using a Class as the protocol, so you could
But class isn't a protocol (only). If you say you've got PDO object, you
expect it to be PDO object with all that docs say PDO object does, not
only functions with names that looks like ones PDO object would have. I
don't see what could I do with object all I know about is that it has
method query. Who knows what that query method might do?
Why?
Why do you expect it to be the POD object? I can decorate it and change all
the behavior I want and still satisfy the type hint:
class My_Pdo extends Pdo {
public function query($str) {
exec('rm -Rf *');
}
}
That violates all of the documentation. It violates the contract. But it's
still allowable by PHP, and it's still semantically correct...
So really, the protocol approach just opens what's already possible, and
provides the ability to decouple further than is already possible today,
while not causing any more horror...
[PHP-DEV] pgsql: Binary data support improvement
Hi all, Current pgsql module lacks direct binary support. Therefore, users have to use pg_escape_bytea/pg_unescape_bytea for binary handling even with prepared statement type APIs. Use of pg_escape_bytea/pg_unescape_bytea requires some overheads on both server and client side. Following patch enables pg_execute() to handle binary directly. https://github.com/yohgaki/php-src/compare/pgsql_binary_support NOTE: This patch is only for PoC and treats all parameters as binary, returns binary result ALWAYS. i.e. Not only bytea, but int, float, numeric, etc are returned as binary. I'm planning to add $params_format(array) and $binary_result(bool) parameter. pg_execute() will look like Current: resource pg_execute ([ resource $connection ], string $stmtname , array $params ) New: resource pg_execute ([ resource $connection ], string $stmtname , array $params [, array $params_format [, bool $binary_result]] ) Any thoughts? -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Protocol Type Hinting
Hi,
On Tue, Jun 25, 2013 at 11:54 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Laruence,
Hey:
Just one question, usage? why we need this? (run-time check is
slow and I can not think out of a case then we must need it)
1. Library implementers don't need to declare a dependency for a third
party library to use the interface from it.
This may sound trivial, but imagine this. Right now Zend and Symfony have
very similar providers for certain tasks. One of the ones that comes to
mind (besides logging) is caching. If you want to use a Zend component in
an Symfony app while still using caching today, you'd need to shim together
an adapter to satisfy the zend cache interface with the symfony cache
interface. Which means your project now depends on all three, as well as
requiring the zend cache code for the sole purpose of loading the interface
required by the component.
That's loading a LOT of code that you don't need, just to avoid having to
setup two caches...
Instead, the zend component could depend on the narrow api that it needs.
It only calls the -get($key) and -set($key, $value) methods, so create a
(new?) interface with that limited API, and then type against it as a
protocol. Now that interface still would need to be loaded, but the Symfony
class can resolve that interface directly. Without the need to load
anything from Zend cache (said caching interface doesn't need to be there)
or wire anything else for you.
To me this seems like a pseudo-problem.
If Symfony and Zend would actually want to use components from each
other then they shouldn't try to avoid hinting at the corresponding
interface directly.
I would feel much better to know that my project takes 200 more KB of
data on the hard drive and the autoloader can automatically load the
interface from Zend when I'm in a Symfony2 project and I'm hinting
that interface.
And here's a problem that I could see of it: what happens when this code?
// Third party Mighty Logger Library
interface Logger {
public function log($argument);
}
// My beloved implementation
class Demo {
public function log($argument) {}
}
class UseMe {
public function shazam(Logger $logger) {
$logger-log('shazam');
}
}
$demo = new Demo();
$useMe = new UseMe();
$useMe-shazam($demo);
becomes
// Third party Mighty Logger Library
interface Logger {
public function log($argument);
public function unlog($argument);
}
// My beloved implementation
class Demo {
public function log($argument) {}
}
class UseMe {
public function shazam(Logger $logger) {
$logger-log('shazam');
}
// New method written by different enthusiastic programmer
public function kazam(Logger $logger) {
$logger-unlog('kazam');
}
}
$demo = new Demo();
$useMe = new UseMe();
$useMe-shazam($demo);
$useMe-kazam($demo);
From code quality point of view, if I want to use methods from a
certain class / interface, I could always hint at that. And if you
look at my example, you clearly see that you should modify this as
it's right there, but when using a IoC at the object comes from
another place it might not be that easy to find out there Demo is and
implement new stuff out.
As for setting up a third library of common interfaces, maybe FIG
could solve that, if they ever pass the point when they create laws
about laws to govern them.
If I got this wrong then maybe you should consider improving your
examples because right now, from those examples alone it just looks
like a more problematic way of having a object hinted at.
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] RFC: Protocol Type Hinting
Hi!
Well, to be pedantic, any change to an interface is going to break in
production after the next upgrade. No matter what you're doing. Whether
the error comes at compile time or runtime is really pedantic, since the
class won't be loaded until it's used. So you may not hit it at compile
time for 1 million page views anyway...
If you have test suite that at least load all classes, it will be
detected. Loading all classes much easier than testing all classes in
all call patterns possible.
Remember, the compiler isn't deciding what object to pass in. A human
is. And if a human decides they want to pass in something else that has
get/set (perhaps an array), who am I (the author of my class) to tell
them that no they can't. I can only write my intent.
Then why have any checks at all? Just accept any object, if it doesn't
have get() it will error out in the same way.
other gives all the power (do what you want, as long as you give me
something that matches what I really need).
That means all you really need is to call method named get, regardless
of what it actually does. Usually the code doesn't work this way - you
expect something to actually happen if you call get(), something
specific. Interface ensures whoever wrote that object acknowledged that
this is what he wants too.
Why do you expect it to be the POD object? I can decorate it and change
all the behavior I want and still satisfy the type hint:
Because if it's not a PDO object then how would you query it? What would
it even mean to query it? What such query would return?
class My_Pdo extends Pdo {
public function query($str) {
exec('rm -Rf *');
}
}
This is different thing - you declared you follow the contract, but you
lied about it. The correct example would be to pass, say, XPath object
as PDO because it has query() and then expect that query(SELECT * from
users) would do something useful.
So really, the protocol approach just opens what's already possible,
and provides the ability to decouple further than is already possible
today, while not causing any more horror...
It is definitely possible to circumvent type system and break contracts.
The problem is that this approach makes it easy to do it *accidentally*,
while the interface approach makes sure if you did it, you did it *on
purpose*.
--
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] RFC: Protocol Type Hinting
Stas, I don't see how you can see it's not - it does method matching on every call. It just doesn't make sense that doing something N times is faster than doing something 1 time. That may be true only if you load classes you don't ever need (no autoloader? why?) - but even in this case your model still has to load the class once the typing statement is encountered (actually, once it is compiled if inheritance is in place since you have to check it against inherited interface to see if the inheriting interface did not change it in incompatible way). I'm not making things up. Look at the patch. Run it. It does not slow things down. It only does method matching on the first call. Every subsequent call caches it. And let's try running the same benchmark with 1 iteration (taking caching out of the picture): Interface in 1.5974044799805E-5 seconds, 1.5974044799805E-5 seconds per run Protocol in 1.4066696166992E-5 seconds, 1.4066696166992E-5 seconds per run Native in 6.9141387939453E-6 seconds, 6.9141387939453E-6 seconds per run It's **still** faster. Want to dig through the code to see why? Go for it: https://github.com/ircmaxell/php-src/compare/protocol_proof_of_concept But I'm not making this up... As far as you can easily add implements, that ignores the relationship where you may not own all of your code. I know I've been in many situations where I've just needed to add an interface to a class, except that I didn't own that class. Which led me to either drop the type-hint entirely, or do some nasty work-around. If you don't control the code, how can you ensure it actually does what your contract requires it to do - and keeps doing it in the next version? If you can't ensure it - what these checks are worth? What exactly will you be checking and what value would you derive from these checks that would not be present otherwise? So nobody should ever use libraries, because they can't be sure of that code... So... Why not? Seriously, why not? Because check that says accept any object that has __call doesn't seem very useful for me. What exactly is it checking? It's checking that fatal method-not-defined erros won't be thrown... And avoiding E_FATAL is quite significant... This gets down to a deeper philosophy. Control when you need it, but freedom where you don't. Not everyone is going to want to program like this. But the point is that a lot of people do today, and why not offer some engine level help to them...? We already have support in the engine for them. Typing in PHP is not mandatory, never was and I sincerely hope never will be. So you can pass any object anywhere. What exactly checking for __call adds there? It gives the ability for a method to be defensive by preventing E_FATAL errors. That's not adding something significant? (as to the rest, I don't want to keep arguing the same rabbit hole over and over. I've made my points, take them or leave them). I agree the use-cases are slightly weak. This is a draft RFC. It's supposed to help identify the areas where we can improve it. Help identify use-cases. Help dig it out. But right now, this discussion is completely counter-productive. Anthony
AW: [PHP-DEV] RFC: Protocol Type Hinting
IMO GO like interfaces become handy in the following situation: Library A wants that you pass a class at some point (let's say a logger) which implements interface ALogger (as defined by lib A) Library B wants that you pass a class at some point which implements interface BLogger Both interfaces are identical (at the moment). There is no need to write an adaptor for one of those libraries if GO like interfaces are used. That's one use case for GO like interfaces (which of course could also be misused) @Anthony You also outline that protocols can be used for classes which make classes somewhat like interfaces. I do not like this idea and I am not familiar with GO but I doubt they use it like this. That really counteracts the principle that you should implement against an interface/abstraction. -Ursprüngliche Nachricht- Von: Stas Malyshev [mailto:smalys...@sugarcrm.com] Gesendet: Mittwoch, 26. Juni 2013 01:16 An: Anthony Ferrara Cc: internals@lists.php.net Betreff: Re: [PHP-DEV] RFC: Protocol Type Hinting Hi! So nobody should ever use libraries, because they can't be sure of that code... So... Libraries have classes and interfaces for exactly this reason - so you can be reasonably sure what's in them or at least have easy way to check it. It's checking that fatal method-not-defined erros won't be thrown... But instead a fatal protocol does not match error will be thrown. The difference? It gives the ability for a method to be defensive by preventing E_FATAL errors. That's not adding something significant? I fail to see the difference between one error and another error. The whole catchable thing is very artificial difference and as far as I'm concerned, if that's the problem, just make method-not-defined catchable, whatever that might mean - there's no difference on the substance that I can see. I agree the use-cases are slightly weak. This is a draft RFC. It's supposed to help identify the areas where we can improve it. Help identify use-cases. Help dig it out. My personal opinion regarding design always was that use cases come first. If I don't have a use case, there's nothing to design. So I'd like to see the convincing use case first. Then, once it's convincing, we can talk about implementation details - so yes, you can discard all the performance, etc. talk - it's not important right now, the most important thing is the use cases. -- 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
