RE: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
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. The Netbeans thing was just an example/addition. 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 If you have an exception like `BadCredentialsException` and throw it during authentication if the user has entered wrong login data, than you have such a situation right? But do you need any further information? No - in the catch block it may be enough to create a message for the user saying: wrong username or password. Maybe you only use generic exceptions like `RuntimeException`. This can be an exception for almost everything. But if you have defined an exception for one special case, to interrupt your code, and catch such an exception you will always know why this exception has been thrown. -- Christian Stoller LEONEX Internet GmbH
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On 25 June 2013 22:23, Johannes Schlüter johan...@schlueters.de wrote: 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. Hrm, this is a very good point! 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. Nothing more to add. -- 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'
2013/6/25 Nikita Popov nikita@gmail.com:
but I'm against the generic catch{} statement.
I'm sharing Nikita's opinion, with the difference of a bit more
enthusiasm on leaving off the variable as it could make it more
obvious that there is no intention in using the variable, and that no
memory should be kept for it. This might be better than doing:
try {
[...]
} catch (Exception $ignore) {
unset($ignore);
}
[...]
However, I see other cases where a variable is technically required
but not used:
abstract class AbstractPrinter {
abstract public function print($message);
}
class Printer extends AbstractPrinter {
public function print($message) {
echo $message;
}
}
class BlackholePrinter extends AbstractPrinter {
public function print($message) {
}
}
In the previous example, $message is not used in
BlackholePrinter::print() (as well as in AbstractPrinter::print()).
How do you intend to make that consistent with: catch(Exception) ?
Patrick
--
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 Wed, Jun 26, 2013 at 8:31 AM, Christian Stoller stol...@leonex.de wrote: 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. The Netbeans thing was just an example/addition. 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 If you have an exception like `BadCredentialsException` and throw it during authentication if the user has entered wrong login data, than you have such a situation right? But do you need any further information? No - in the catch block it may be enough to create a message for the user saying: wrong username or password. Maybe you only use generic exceptions like `RuntimeException`. This can be an exception for almost everything. But if you have defined an exception for one special case, to interrupt your code, and catch such an exception you will always know why this exception has been thrown. -- Christian Stoller LEONEX Internet GmbH Hi, I believe that the example you provided, the one with 'BadCredentialsException', is a good example of a bad design and usage of exceptions, at least from my point of view. The fact that frameworks like Symfony2, Zend Framework or other php libraries/frameworks (ab)use the exceptions it doesn't mean that it's a good thing or you should have exceptions for everything. The provided example could just as well return false; for the login function and that's it, no? Exceptions should be used for exceptional cases where the application can't recover automatically from them. They are, even as their name suggests, exceptional cases, while a bad credential for a user login is not :) I also believe, and I might not be the only one with this, that exceptions used for flow control is a good sign of bad design. If you follow this way of thinking, everytime you throw an exception, you would want to catch it and perform some work with it, like logging it for example. So why would you make the variable optional then? 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] pgsql: Binary data support improvement
Sorry, missed the list... On 26 June 2013 09:54, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Make, 2013/6/26 Michael Wallner m...@php.net I didn't look at the code yet, but how do you know about binary format conventions of all possible types returned? Users can only specify if the result is returned as text or binary. i.e. If a user set $binary_result to TRUE, then all results(fields) are returned as binary. pgsql module does not care what binary is returned and users are responsible for correct handling. Therefore, it's only useful for bytea data type for almost all users. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pgsql: Binary data support improvement
On 26/06/2013 00:44, Yasuo Ohgaki wrote: New: resource pg_execute ([ resource $connection ], string $stmtname , array $params [, array $params_format [, bool $binary_result]] ) Any thoughts? Using binary format requires knowledge of the internal representation expected by the backend. For example, integers must be passed in network byte order, quoting the libpq documentation. Although it is possible to specify whether or not each parameter is binary, the same is not possible for the result due to a limitation in libpq. Meaning that $binary_result can only be used for queries returning one or more bytea fields. I would be happier if we could make this transparent to the user, but I don't see any feasible way to do this, at least for the results. I have mixed feelings... I see where this might come in handy, but I think it would be a bit too user-unfriendly. PDO_pgsql on the other hand, when used with explicit parameter binding, could automatically use binary format for LOB fields. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
Hi, On Wed, 26 Jun 2013 02:57:46 +0400, Stas Malyshev smalys...@sugarcrm.com wrote: 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. But you (as a library dev) still have interfaces. You still use them. This discussion got really big in a short period of time, but we all know all this change does is gives us an ability to not write additional code. Some people already stated it - you just won't need to create adapters and it's cool. There's a lot of cases where you need to wire to different libraries and for that matter you create THIRD library and call it something like %lib1-name%%lib2-name%Adapter where you, in the best case, should create classes that inherit from some lib1's or lib2's classes (and just add implements Lib2Interface), or if there's some static methods - you are forced to create decorator which implements needed interfaces - and that is what will give a far more overhead than some runtime engine-level checks. What about static analysis, it just lays on YOUR shoulders, if you so want static analysis to work properly you just write code which implements interfaces. But if it's fine for you, then it's fine, it's easy. PS sorry for caps in some places -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pgsql: Binary data support improvement
Hi Matteo, 2013/6/26 Matteo Beccati p...@beccati.com I have mixed feelings... I see where this might come in handy, but I think it would be a bit too user-unfriendly. I have mixed feelings for supporting direct binary support, too. Main intension is faster bytea(binary) handling. Without binary support, client has to encode binary via pg_escape_bytea and server decode it before saving bytea data. When selecting, server encode it by using PQescapeByeta algorithm, then client decode it by pg_unescape_bytea. PDO_pgsql on the other hand, when used with explicit parameter binding, could automatically use binary format for LOB fields. AFAIK, PDO doesn't handle bytea data natively. There may be clever usage, but binary support is only for faster bytea handling. API isn't great, so if there are objections, I'll spend time rather than this. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 5:50 AM, Florin Patan florinpa...@gmail.com wrote:
Hello PHP internals,
Currently PHP doesn't support what could be a good feature for code
quality, return typing (or if you prefer to call it: return type
hinting).
Since the procedure says that before any real RFC should be done, the
interest for this topic should be gauged, I've drafted something here:
https://gist.github.com/dlsniper/5863012
The goals for this discussion are:
- gauge the interest in having such a feature in PHP.NEXT
- find weak spots in the draft
- find potential problems with the suggested way of doing the
implementation
- determine if the advantages would outweigh the disadvantages and
this should go forward as a RFC
As you can see, the draft doesn't include any patch and since my C
skills are mostly nonexistent, I currently can't provide one
unfortunately. I would however love to do it with proper guidance from
someone that could spare some of his/her time to help me out.
This said, thank you very much for your time, consideration and
feedback on this subject.
Best regards,
Florin
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
PHP really doesn't need function return type declaration since PHP doesn't
even support variable declaration. This would make sense in a language like
C or C++ where the compiler can do static analyses to determine potential
errors before compiling.
Since PHP is a loosely typed dynamic language, however, the fact that a
function can return something of any type is quite liberating and it turns
out that you don't need the static analyses to write better code with PHP,
because most of the errors static analyses helps you with aren't really the
things you are most concerned with. For example consider the following bug:
?php
function userTimezone($userId, PDO $db) {
$result = [];
if (!($stmt = $db-prepare('SELECT `timezone` FROM users WHERE
users.`id` = ?'))) {
return false;
}
if ($stmt-execute([$userId])) {
$result = $stmt-fetchAll(PDO::FETCH_ASSOC);
}
return array_pop($result);
}
?
If in the above code PDO::prepare returns false (upon failure) for any
reason $stmt will not be of the expected type. In that case the function
returns a boolean false to indicate failure (or it can throw an exception
as well). If the Exception is throw the function's return value is still
implicitly null. However, the return type of the function isn't what we
actually care about here, because it doesn't solve our real problem. The
real problem we care about is the fact that the function failed and
couldn't keep its promise. If we force the function to only return an array
we can't tell the difference between an empty result set or a failure case
unless we strictly stick to exceptions. In none of those cases was the
function's return value type hint helpful.
Re: [PHP-DEV] RFC Proposal: New assign value operator
On 25 June 2013 11:01, Tom Oram t...@scl.co.uk wrote:
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
Hi.
I'm not going to comment on the merits as such, but I'd be interested in
knowing what problem this RFC would solve?
Considering PHP has type juggling scalars, it would SEEM (I may have missed
the point) that this could result in data loss when the enforced conversion
results in 0/False/.
$num = 8;
$num := data from user; // 0
Unless that is the expected behaviour.
Where would this RFC change be used?
And having said all of that, I'm not against it, just want to see what it
would be useful for that isn't already part of PHP's toolbox.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
AW: [PHP-DEV] RFC Proposal: New assign value operator
As far as I see it, it is kind of an operator overload mechanism for the assign
operator.
This can be useful for small utility classes such as Money, Email etc.
An example was given:
$price = new MoneyValue();
$price := 29.99;
Instead of writing something like:
$price = new MoneyValue();
$price-setPrice(29.99);
The benefit is small, but can lead to better readable code. But since it is
only for the assign operator and not for + - etc., for me the question remains
open why not writing something like this directly:
$price = new MoneyValue(29.99);
-Ursprüngliche Nachricht-
Von: Richard Quadling [mailto:rquadl...@gmail.com]
Gesendet: Mittwoch, 26. Juni 2013 12:51
An: Tom Oram
Cc: PHP internals
Betreff: Re: [PHP-DEV] RFC Proposal: New assign value operator
On 25 June 2013 11:01, Tom Oram t...@scl.co.uk wrote:
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
Hi.
I'm not going to comment on the merits as such, but I'd be interested in
knowing what problem this RFC would solve?
Considering PHP has type juggling scalars, it would SEEM (I may have missed the
point) that this could result in data loss when the enforced conversion results
in 0/False/.
$num = 8;
$num := data from user; // 0
Unless that is the expected behaviour.
Where would this RFC change be used?
And having said all of that, I'm not against it, just want to see what it would
be useful for that isn't already part of PHP's toolbox.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
--
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 26 juni 2013 at 08:35:59, Michael Wallner (m...@php.net) wrote: On 25 June 2013 22:23, Johannes Schlüter johan...@schlueters.de wrote: 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. Hrm, this is a very good point! 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. Nothing more to add. -- Regards, Mike This is a little pathetic. Someone sums it up to Why not, which is not the case, we have grounded arguments for this, and then all agree that Why not is not a reason to add something. Surely it isn't. You mention bad coding practices. Sure, we should avoid them. Unused variables is a bad coding practice. So, we should avoid them. Luckily, it's easy to avoid them with catch-statements, because we can simply make the variable optional. I recently wrote a CLI tool in C# to import data from Team Foundation Server. During an update, I try to download every new commits from where I last stopped (so, from commit latest+1). That fails with a ChangesetNotFoundException when no such commit exists, fair enough. I cannot test beforehand whether that exception will be thrown (that would mean I needed two calls to the server, now it's in one round) so it's totally expected. I'm doing this for 100.000 files and I don't want to do anything with the exception, it's nothing more than an indication that we're already up-to-date for that file. Done. In PHP I would have an unused variable, which trips up my static analysis tool that keeps warning me about the bad coding practice of having an unused variable. I agree, it's bad to have that variable defined but PHP won't let me get rid of it. Another reason for people to bitch about PHP. Luckily, we can do something about it, and it happens to be easy. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP-DEV] RFC Proposal: New assign value operator
On Wed, 2013-06-26 at 13:54 +0200, Robert Stoll wrote: As far as I see it, it is kind of an operator overload mechanism for the assign operator. This can be useful for small utility classes such as Money, Email etc. An example was given: $price = new MoneyValue(); $price := 29.99; Instead of writing something like: $price = new MoneyValue(); $price-setPrice(29.99); The benefit is small, but can lead to better readable code. But since it is only for the assign operator and not for + - etc., for me the question remains open why not writing something like this directly: $price = new MoneyValue(29.99); I see no benefit. It adds a new operator with new semantics which one has to learn to understand the code and which is hard to Google. Also such objects seem to be value objects, so it should be immutable thus allowing code like $price = new MoneyValue(); $price-setPrice(29.99); looks like bad design. If you have to type $price = new MoneyValue(29.99); often you can shorten it use MoneyValue as MV; $price = new MV(29.99); sure still longer than := but no new syntax and more explicit. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] RFC Proposal: New assign value operator
The property is most likely private and you don’t have to bother about it anyway. But yes, for pure PHP users it might seems confusing since PHP variables have no types. If you are familiar with types and operator overloading than it is more readable IMO I assign the new price 29.99 to the variable $price What’s wrong with that? Is quite straight forward no? $price-setPrice(29.99); is straight forward as well IMO but your eyes need to read more than := Yet, as I said, it is a small benefit and without overloading of + - almost negligible. With + - etc. it would be possible to do things like $price += 1.50; $price *= 2; Etc. IMO better readable than $price-add(1.50); $price-multiplyBy(2); Cheers Von: Peter Lind [mailto:peter.e.l...@gmail.com] Gesendet: Mittwoch, 26. Juni 2013 14:00 An: Robert Stoll Cc: Richard Quadling; Tom Oram; PHP internals Betreff: Re: [PHP-DEV] RFC Proposal: New assign value operator On 26 June 2013 13:54, Robert Stoll rst...@tutteli.ch wrote: As far as I see it, it is kind of an operator overload mechanism for the assign operator. This can be useful for small utility classes such as Money, Email etc. An example was given: $price = new MoneyValue(); $price := 29.99; Instead of writing something like: $price = new MoneyValue(); $price-setPrice(29.99); The benefit is small, but can lead to better readable code. Better readable code? It looks like you're reassigning $price, not assigning to a property of $price. If anything it is less readable and will lead to countless WTF moments. Just my immediate thoughts on seeing the examples. Regards Peter -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
Sherif,
I have to disagree with you on this in the same way that we have type hints
for input variables on methods, this could also be useful.
Consider an interface with a getter method defined. As it stands now in
php, they're not entirely useful, since you can't define what type of
object your expecting from the implementer. That greatly reduces the
functionality of an interface and this proposal gives solution to that
problem.
Florin,
I think the overall concept is good, I want to see something like this in
the future, but I think this might be the wrong approach. I don't think we
should be hinting primitives. if we're going to have a return type hint on
a method, I would have it match the functionality of the input type hints
for functions we already have, where you can hint at an instance of an
object type, such as Iterator or StdClass, or an array, but not hint
primitives such as int and string, like I currently see in the draft.
Also, you should be aware that your proposed syntax for the return type (
type ) is interfering with:
https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
me.
On Wed, Jun 26, 2013 at 5:08 AM, Sherif Ramadan theanomaly...@gmail.comwrote:
On Wed, Jun 26, 2013 at 5:50 AM, Florin Patan florinpa...@gmail.com
wrote:
Hello PHP internals,
Currently PHP doesn't support what could be a good feature for code
quality, return typing (or if you prefer to call it: return type
hinting).
Since the procedure says that before any real RFC should be done, the
interest for this topic should be gauged, I've drafted something here:
https://gist.github.com/dlsniper/5863012
The goals for this discussion are:
- gauge the interest in having such a feature in PHP.NEXT
- find weak spots in the draft
- find potential problems with the suggested way of doing the
implementation
- determine if the advantages would outweigh the disadvantages and
this should go forward as a RFC
As you can see, the draft doesn't include any patch and since my C
skills are mostly nonexistent, I currently can't provide one
unfortunately. I would however love to do it with proper guidance from
someone that could spare some of his/her time to help me out.
This said, thank you very much for your time, consideration and
feedback on this subject.
Best regards,
Florin
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
PHP really doesn't need function return type declaration since PHP doesn't
even support variable declaration. This would make sense in a language like
C or C++ where the compiler can do static analyses to determine potential
errors before compiling.
Since PHP is a loosely typed dynamic language, however, the fact that a
function can return something of any type is quite liberating and it turns
out that you don't need the static analyses to write better code with PHP,
because most of the errors static analyses helps you with aren't really the
things you are most concerned with. For example consider the following bug:
?php
function userTimezone($userId, PDO $db) {
$result = [];
if (!($stmt = $db-prepare('SELECT `timezone` FROM users WHERE
users.`id` = ?'))) {
return false;
}
if ($stmt-execute([$userId])) {
$result = $stmt-fetchAll(PDO::FETCH_ASSOC);
}
return array_pop($result);
}
?
If in the above code PDO::prepare returns false (upon failure) for any
reason $stmt will not be of the expected type. In that case the function
returns a boolean false to indicate failure (or it can throw an exception
as well). If the Exception is throw the function's return value is still
implicitly null. However, the return type of the function isn't what we
actually care about here, because it doesn't solve our real problem. The
real problem we care about is the fact that the function failed and
couldn't keep its promise. If we force the function to only return an array
we can't tell the difference between an empty result set or a failure case
unless we strictly stick to exceptions. In none of those cases was the
function's return value type hint helpful.
Re: [PHP-DEV] RFC: Protocol Type Hinting
Hi,
As I see it, adapters not only serve declaration purpose, they also can
adapt the method and param names and even alter or tune the execution flow.
Imagine this simple case:
You have a protocol Duck with method walk() with few concrete
implementations. Later you have another instance of Duck, but its
corresponding method is called walkAround(). What would be the sane pattern
to solve this problem? Should we now implement an adapter for the protocol?
I think if we're interested in simplification, there should be a more
flexible way to create adapters instead, maybe with method/param mapping
abilities. E.g.:
class Duffy { function walkAround($speed, $distance) {} }
interface Duck { function walk($distance, $speed); }
adapter DuffyDuck extends Duffy implements Duck {
function walk($distance, $speed) as walkAround($speed, $distance);
}
or in a simpler case -
class Donald { function walk($distance, $speed); }
adapter DonaldDuck extends Donald implements Duck {}
It solves same problem as the proposal, but in explicit, maintainable and
analyzable way, IMHO.
On Wed, Jun 26, 2013 at 5:51 AM, Nikita Nefedov inefe...@gmail.com wrote:
Hi,
On Wed, 26 Jun 2013 02:57:46 +0400, Stas Malyshev smalys...@sugarcrm.com
wrote:
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.
But you (as a library dev) still have interfaces. You still use them.
This discussion got really big in a short period of time, but we all know
all this change does is gives us an ability to not write additional code.
Some people already stated it - you just won't need to create adapters and
it's cool.
There's a lot of cases where you need to wire to different libraries and
for that matter you create THIRD library and call it something like
%lib1-name%%lib2-name%Adapter where you, in the best case, should create
classes that inherit from some lib1's or lib2's classes (and just add
implements Lib2Interface), or if there's some static methods - you are
forced to create decorator which implements needed interfaces - and that is
what will give a far more overhead than some runtime engine-level checks.
What about static analysis, it just lays on YOUR shoulders, if you so want
static analysis to work properly you just write code which implements
interfaces. But if it's fine for you, then it's fine, it's easy.
PS sorry for caps in some places
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT patrickalla...@php.netwrote:
2013/6/26 Maxwell m...@maxvandervelde.com:
Sherif,
I have to disagree with you on this in the same way that we have type
hints
for input variables on methods, this could also be useful.
Consider an interface with a getter method defined. As it stands now in
php, they're not entirely useful, since you can't define what type of
object your expecting from the implementer. That greatly reduces the
functionality of an interface and this proposal gives solution to that
problem.
Florin,
I think the overall concept is good, I want to see something like this in
the future, but I think this might be the wrong approach. I don't think
we
should be hinting primitives. if we're going to have a return type hint
on
a method, I would have it match the functionality of the input type hints
for functions we already have, where you can hint at an instance of an
object type, such as Iterator or StdClass, or an array, but not hint
primitives such as int and string, like I currently see in the draft.
Also, you should be aware that your proposed syntax for the return type (
type ) is interfering with:
https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
me.
Thanks Maxwell, you summarized very well what I was thinking about it.
So +1 from me for the general feature at a first glance, but it should
then be very close to what is possible with input type hinting.
It makes it possible to write interfaces that acts like specifications
and to easier the writing of:
class Foo {
public function bar($input) {
$return = Baz::foo($input);
if (!$return instanceof ReturnType)
trigger_error(Cannot divide by zero, E_USER_ERROR); //
or throwing some RuntimeException
return $return;
}
}
to:
class Foo {
public function ReturnType bar($input) {
return Baz::foo($input);
}
}
+1 for the global idea as this would help so much OO programs and framework
based programs.
But what Sherif said proves as well the limits of the idea. PHP is not
strongly typed. So each check, should it be type hinting or return type
hinting, has to be done at runtime , which is bad for performances.
Not talking about the type juggling which could lead the programmer as
shooting himself.
Julien.Pauli
Re: [PHP-DEV] RFC: Protocol Type Hinting
Stas and all, But instead a fatal protocol does not match error will be thrown. The difference? A recoverable protocol does not match error. And the difference is that the check is pushed to the caller as opposed to within the function. 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 think we should. And I think we should turn all non-engine related fatals into exceptions. But both are beyond the scope of this proposal... 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. The use-cases did come first. Unfortunately they are not trivial to type out, and they are not trivial to really understand without actually playing with code. Which is one reason for this draft proposal... So that people can actually download the code and try it out. So that new use-cases beyond my own could be fit. So that people could try it out and comment and evolve the concept. As far as discard all the performance, etc talk, it was Laruence and yourself that brought that up here. And it's something that a lot of people have jumped on. I find it funny that I have proven at least 3 times in this thread that performance is equal to or faster than the current interface approach, yet it still keeps getting brought up... Funny how arguments that support a stance are thrown around, even when they are disproven (and then they are at best ignored)... Additionally, I'd like to make a note here. There's been a lot of talk about best practice in this thread. I think that's exactly the wrong way that language features should be judged. What's currently accepted as best practice is subject to change over time. In practice it does. Just look at the past 5 years of development in frameworks. We went from completely Class-Oriented procedural codebases like Cake and ZF1 to completely OOP designed frameworks like Symfony and ZF2. What the cool kids in the community (the only way I can really describe the vocal minority of OSS contributors) consider best practice has changed Dramatically in the past 5 years. Hell, it's changed drastically in the past 5 months. Internals should not be taking sides on what's good practice and what's bad practice (if it was, why the heck was goto introduced?). Instead, it should enable today's good practice to be followed. But it should not take a stand about bad practice. It's a slippery slope to make the best practice stand. For example, one could make the argument that ignoring errors is not best practice, so therefore every non-truely-fatal error thrown by PHP should be an exception, to force the user to not ignore it. Reasonable? I don't know. But if you want to go down the we need to follow best practice route, that's the logical conclusion... My point here is that we should be judging features by their merit alone, and not by how we would use them. We also should not be judging them based upon our preferred style, but on the overall case of what it aims to achieve. Bringing this back on point, Duck-typing is a very valid and accepted way of doing OOP. In fact most other dynamic languages use this as the basis for their OOP system. This proposal does nothing but attempt to allow a little more safety and self-documentation to a use-case that today is pretty free-for-all...
Re: [PHP-DEV] Who's incharge of github pull requests?
Hi, I saw some patches from you (mentioned in the blog post) has been pushed to git. About the FTP patch, as it requires further testing and an environment for such, and we do not have an active maintainer currently for the extension. It tend to have a delay until anyone with free time (most of we are volunteers), and cares about testing the patch for such extension, to get it applied. Thanks for contributing! 2013/6/16 Lior Kaplan lio...@zend.com: Hi, It seems the list of pull requests on github is getting bigger, who's inchange to review it? https://github.com/php/php-src/pulls I must say that my experience so far in trying to push patches through the bug system or pull request is quite deprsing (comparing to other open source projects): https://liorkaplan.wordpress.com/2013/06/05/getting-patches-into-php/ Kaplan -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 4:21 PM, Patrick ALLAERT patrickalla...@php.netwrote: 2013/6/26 Julien Pauli jpa...@php.net: But what Sherif said proves as well the limits of the idea. PHP is not strongly typed. So each check, should it be type hinting or return type hinting, has to be done at runtime , which is bad for performances. It doesn't mean you have to use it, just that it might be used instead of implementing a manual check in every function/method callers, or, alternatively, in the function/method itself. Being done at runtime by the language will for sure not be worst for performance than doing it manually in pure PHP. Not talking about the type juggling which could lead the programmer as shooting himself. Sure! Hence why *if* this is taken into account, it should really be done the same way as it is done for input parameter hinting, to not introduce what we already don't want there. I think that the return typehints a bit easier topic than the input type hinting(for scalars), because that affects the caller, while return type hinting is more contained: you write the function, you put the return typehint there, if the method tries to return something else, then your code is at fault. So even if we would allow return typehints for scalars that would only affects those functions where the developer opts-in. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
2013/6/26 Marco Pivetta ocram...@gmail.com: What about disabling the check in some environments (prod)? It would work like an assertion I suppose. (Feel free to shoot at me if you think it's a bad idea) shoot This is typically something that has always been rejected in the past. /shoot -- 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 4:28 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Stas and all,
But instead a fatal protocol does not match error will be thrown. The
difference?
A recoverable protocol does not match error. And the difference is that the
check is pushed to the caller as opposed to within the function.
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 think we should. And I think we should turn all non-engine related fatals
into exceptions. But both are beyond the scope of this proposal...
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.
The use-cases did come first. Unfortunately they are not trivial to type
out, and they are not trivial to really understand without actually playing
with code. Which is one reason for this draft proposal... So that people
can actually download the code and try it out. So that new use-cases beyond
my own could be fit. So that people could try it out and comment and evolve
the concept.
As far as discard all the performance, etc talk, it was Laruence and
yourself that brought that up here. And it's something that a lot of people
have jumped on. I find it funny that I have proven at least 3 times in this
thread that performance is equal to or faster than the current interface
approach, yet it still keeps getting brought up... Funny how arguments that
support a stance are thrown around, even when they are disproven (and then
they are at best ignored)...
Additionally, I'd like to make a note here. There's been a lot of talk
about best practice in this thread. I think that's exactly the wrong way
that language features should be judged. What's currently accepted as best
practice is subject to change over time. In practice it does. Just look at
the past 5 years of development in frameworks. We went from completely
Class-Oriented procedural codebases like Cake and ZF1 to completely OOP
designed frameworks like Symfony and ZF2. What the cool kids in the
community (the only way I can really describe the vocal minority of OSS
contributors) consider best practice has changed Dramatically in the past
5 years. Hell, it's changed drastically in the past 5 months.
Internals should not be taking sides on what's good practice and what's bad
practice (if it was, why the heck was goto introduced?). Instead, it should
enable today's good practice to be followed. But it should not take a stand
about bad practice.
It's a slippery slope to make the best practice stand. For example, one
could make the argument that ignoring errors is not best practice, so
therefore every non-truely-fatal error thrown by PHP should be an
exception, to force the user to not ignore it. Reasonable? I don't know.
But if you want to go down the we need to follow best practice route,
that's the logical conclusion...
My point here is that we should be judging features by their merit alone,
and not by how we would use them. We also should not be judging them based
upon our preferred style, but on the overall case of what it aims to
achieve.
Bringing this back on point, Duck-typing is a very valid and accepted way
of doing OOP. In fact most other dynamic languages use this as the basis
for their OOP system. This proposal does nothing but attempt to allow a
little more safety and self-documentation to a use-case that today is
pretty free-for-all...
Hey,
Could you please point out what happened in the past 5 months in PHP
that changed the landscape so drastically as you say? And don't
mention folks reinventing the wheel in OOP because that's not news :)
And could you also please answer this question: 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);
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, 2013-06-26 at 16:40 +0200, Ferenc Kovacs wrote: I think that the return typehints a bit easier topic than the input type hinting(for scalars), because that affects the caller, while return type hinting is more contained: you write the function, you put the return typehint there, if the method tries to return something else, then your code is at fault. So even if we would allow return typehints for scalars that would only affects those functions where the developer opts-in. So a function author doesn't trust himself and therefore we change the language syntax? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] RFC: Protocol Type Hinting
I had a quick look at GO and as far as I understand they do not use duck typing but a structural type system. http://golang.org/doc/faq#implements_interface Please change this in your RFC to avoid misunderstandings. -Ursprüngliche Nachricht- Von: Anthony Ferrara [mailto:ircmax...@gmail.com] Gesendet: Mittwoch, 26. Juni 2013 16:29 An: Stas Malyshev Cc: internals@lists.php.net Betreff: Re: [PHP-DEV] RFC: Protocol Type Hinting Stas and all, But instead a fatal protocol does not match error will be thrown. The difference? A recoverable protocol does not match error. And the difference is that the check is pushed to the caller as opposed to within the function. 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 think we should. And I think we should turn all non-engine related fatals into exceptions. But both are beyond the scope of this proposal... 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. The use-cases did come first. Unfortunately they are not trivial to type out, and they are not trivial to really understand without actually playing with code. Which is one reason for this draft proposal... So that people can actually download the code and try it out. So that new use-cases beyond my own could be fit. So that people could try it out and comment and evolve the concept. As far as discard all the performance, etc talk, it was Laruence and yourself that brought that up here. And it's something that a lot of people have jumped on. I find it funny that I have proven at least 3 times in this thread that performance is equal to or faster than the current interface approach, yet it still keeps getting brought up... Funny how arguments that support a stance are thrown around, even when they are disproven (and then they are at best ignored)... Additionally, I'd like to make a note here. There's been a lot of talk about best practice in this thread. I think that's exactly the wrong way that language features should be judged. What's currently accepted as best practice is subject to change over time. In practice it does. Just look at the past 5 years of development in frameworks. We went from completely Class-Oriented procedural codebases like Cake and ZF1 to completely OOP designed frameworks like Symfony and ZF2. What the cool kids in the community (the only way I can really describe the vocal minority of OSS contributors) consider best practice has changed Dramatically in the past 5 years. Hell, it's changed drastically in the past 5 months. Internals should not be taking sides on what's good practice and what's bad practice (if it was, why the heck was goto introduced?). Instead, it should enable today's good practice to be followed. But it should not take a stand about bad practice. It's a slippery slope to make the best practice stand. For example, one could make the argument that ignoring errors is not best practice, so therefore every non-truely-fatal error thrown by PHP should be an exception, to force the user to not ignore it. Reasonable? I don't know. But if you want to go down the we need to follow best practice route, that's the logical conclusion... My point here is that we should be judging features by their merit alone, and not by how we would use them. We also should not be judging them based upon our preferred style, but on the overall case of what it aims to achieve. Bringing this back on point, Duck-typing is a very valid and accepted way of doing OOP. In fact most other dynamic languages use this as the basis for their OOP system. This proposal does nothing but attempt to allow a little more safety and self-documentation to a use-case that today is pretty free-for-all... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 4:48 PM, Johannes Schlüter johan...@schlueters.de wrote: On Wed, 2013-06-26 at 16:40 +0200, Ferenc Kovacs wrote: I think that the return typehints a bit easier topic than the input type hinting(for scalars), because that affects the caller, while return type hinting is more contained: you write the function, you put the return typehint there, if the method tries to return something else, then your code is at fault. So even if we would allow return typehints for scalars that would only affects those functions where the developer opts-in. So a function author doesn't trust himself and therefore we change the language syntax? johannes All, Thanks for the feedback so far. I've added the typing for scalars as I thought it would be nice to have them but if it's easier to start with supporting what we already have for argument hinting then it would be a great win for the language nonetheless. To address the performance concern issues, I think the performance issues should be very little, like a call to instanceof for example, but I can't say for sure. Of course benchmarks for the actual implementation will need to be made and a manual entry should note that using this feature might have a performance impact if really needed (as I would imagine in 15000 function calls, something that you might see in todays frameworks it could have a more visible impact). @johannes it's not about the author of the function doesn't trust itself, it's about I'm writing a interface and I expect to receive a array but someone returns a string or a single value. That's why I've said that the feature is more about code quality that new toys for developers. Those who opt-in for using this in interfaces would guarantee that every implementation of their interface would be consistent in return type, just like what we have today for arguments, where you can guarantee that you'll have the type you need in your method. If the feedback will be positive for this, as it is right now, I would also like to start working on a patch for this in 2-3 weeks maybe so this is a early request for help for anyone that could point me out in the right direction or champion this patch. I'll make another request when I'll be ready to start working on the patch. Best regards. Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
Florin
Could you please point out what happened in the past 5 months in PHP
that changed the landscape so drastically as you say? And don't
mention folks reinventing the wheel in OOP because that's not news :)
The point was that best practice is volatile and temporal, and changes
depending on who you talk to. Therefore, it becomes a very poor criteria to
judge a language change by...
And could you also please answer this question: 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);
How would IDE be able to provide any useful information in this case,
like they do now with type hints?
The IDE would behave identically as it does now. The only way that the IDE
could provide you meaningful information today would be to track the
`$demo` variable from creation to being passed to those two methods. If the
IDE can track that and give you an error today, it can still give you the
same error tomorrow. Sure, if you implement the logger interface on Demo it
can find the error, and there's nothing stopping you from doing that. The
key is that it's not *required*...
And the key here is to realize that this feature is designed to decouple.
And that comes at a cost (reducing the ability for static analysis). But
you gain a very significant amount of flexility by it. And that's worth it
IMHO. If you don't program that way, I completely understand. But it is a
valid approach that's currently being used.
Yes, it's a nice academic feature, but if I'm doing a code review,
when I see that a class implements a certain interface or a parameter
has a certain type-hint then I can be sure that I won't need to review
the interface and the implementation to match all the possible methods
in that class and if I'm using a third party app review that as well
to make sure that the guy who's using this 'weak type-hinting' aka
protocol type hinting as you call it won't mess up.
In theory this sounds like a great argument. In practice, I don't think it
holds up. The main reason is that look at other languages. Look at Perl.
Look at JavaScript Look at Python. Look at Ruby. Look at Go. Look at C.
Look at C++. None of them have the contract based typing that PHP does. But
all of them get by just fine. And 2 of them use structural typing like this
(Go and C++).
I understand your idea, but for me, the problem that would generate in
real world scenario where you have junior programmers, trainees,
people that don't test the code before they deploy it (or that don't
write tests at all, like me).
See the point above...
Can you please address these issues?
Other than pointing out that these issues don't really exist in general
(they are just a perspective based on an approach, rather than inherent to
the concept), I'm not sure how... You have a different approach to code
than I do. That doesn't mean either of us is wrong. It just means we value
different things. And that's ok...
Anthony
Re: [PHP-DEV] RFC: Protocol Type Hinting
Robert, On Wed, Jun 26, 2013 at 10:52 AM, Robert Stoll rst...@tutteli.ch wrote: I had a quick look at GO and as far as I understand they do not use duck typing but a structural type system. http://golang.org/doc/faq#implements_interface Please change this in your RFC to avoid misunderstandings. Great idea. I'll update the RFC and code to call it structural typing instead of protocol. A much better term... Thanks!
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 3:35 PM, Julien Pauli jpa...@php.net wrote:
On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT patrickalla...@php.net
wrote:
2013/6/26 Maxwell m...@maxvandervelde.com:
Sherif,
I have to disagree with you on this in the same way that we have type
hints
for input variables on methods, this could also be useful.
Consider an interface with a getter method defined. As it stands now in
php, they're not entirely useful, since you can't define what type of
object your expecting from the implementer. That greatly reduces the
functionality of an interface and this proposal gives solution to that
problem.
Florin,
I think the overall concept is good, I want to see something like this
in
the future, but I think this might be the wrong approach. I don't think
we
should be hinting primitives. if we're going to have a return type hint
on
a method, I would have it match the functionality of the input type
hints
for functions we already have, where you can hint at an instance of an
object type, such as Iterator or StdClass, or an array, but not hint
primitives such as int and string, like I currently see in the draft.
Also, you should be aware that your proposed syntax for the return type
(
type ) is interfering with:
https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
me.
Thanks Maxwell, you summarized very well what I was thinking about it.
So +1 from me for the general feature at a first glance, but it should
then be very close to what is possible with input type hinting.
It makes it possible to write interfaces that acts like specifications
and to easier the writing of:
class Foo {
public function bar($input) {
$return = Baz::foo($input);
if (!$return instanceof ReturnType)
trigger_error(Cannot divide by zero, E_USER_ERROR); //
or throwing some RuntimeException
return $return;
}
}
to:
class Foo {
public function ReturnType bar($input) {
return Baz::foo($input);
}
}
+1 for the global idea as this would help so much OO programs and framework
based programs.
But what Sherif said proves as well the limits of the idea. PHP is not
strongly typed. So each check, should it be type hinting or return type
hinting, has to be done at runtime , which is bad for performances.
Not talking about the type juggling which could lead the programmer as
shooting himself.
Julien.Pauli
Hi,
Type juggling is explicitly not allowed in the draft and I would hope
it can remain the same in the final implementation.
That's actually one of the things I want to prevent.
I love PHP because of type juggling which can be very handy at times
but for such feature this would be a total no no.
As for limited applicability, I think that frameworks could benefit
greatly from this as well as systems where you really count on having
the least surprise possible from code. And as more people turn to PHP
to bootstrap their startup, idea or whatnot, having more code quality
features would only help the language to maintain its traction and
improve the life all-around.
Best regards
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Gauging Interest:RFC to add map() function
Hello,I would like to submit an RFC to add a new function to the PHP language. The function would be called "map()". The purpose of this function would be to take an existing value within a range and make it to a corresponding location within a new range.The map() method would have 5 required parameters, $originalLow, $originalHigh, $newLow, $newHigh, and $value.map() would be implement the following:function map($originalLow, $originalHigh, $newLow, $newHigh, $value) { return $newLow + ($value - $originalLow) * ($newHigh - $newLow) / ($originalHigh- $originalLow);}Example:Let's say we are teachers and are grading final exams. We have a policy that the best score is 100, and the worst score is a 70. Students scored between 55 and 92. We want to easily re-score the exams to be within the new score range, so we would use the new map() function. Let's begin with mapping the lowest score: $newScore =map(55, 92, 70, 100,55); //$newScore = 70 If we have all of our scores in an array: $scores = array(71, 65, 55, 85, 88, 86, 92, 77, 73);We could use a foreach loop to remap each value: $newScores = array(); foreach($score as $scores) { $newScores[] = map(55, 92, 70, 100, $score); } var_dump($newScores); /* array(9) { [0]= float(82.972972972973) [1]= float(78.108108108108) [2]= int(70) [3]= float(94.324324324324) [4]= float(96.756756756757) [5]= float(95.135135135135) [6]= int(100) [7]= float(87.837837837838) [8]= float(84.594594594595) } */Just like that, we have the new exam grades that fit our policy, within the proper scale, without having to do any of the messy math ourselves.While I do recognize that this is somewhat trivial to anyone who knows the proper formula, I feel as though it would serve the PHP community well. Much the same as the pow() or pi() functions do. I appreciate your thoughts on this matter and whether or not this is worth pursuing as an RFC.Thank you,Jeremy Curcioj.cur...@me.com
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 4:48 PM, Johannes Schlüter johan...@schlueters.dewrote: On Wed, 2013-06-26 at 16:40 +0200, Ferenc Kovacs wrote: I think that the return typehints a bit easier topic than the input type hinting(for scalars), because that affects the caller, while return type hinting is more contained: you write the function, you put the return typehint there, if the method tries to return something else, then your code is at fault. So even if we would allow return typehints for scalars that would only affects those functions where the developer opts-in. So a function author doesn't trust himself and therefore we change the language syntax? johannes or not trusting the subsystem that he/she calls, and he/she wants to make a hard promise about the return value. I could also mention, that this feature could be used in static analysis and IDEs(albeit most IDEs out there already supports docblocks). I'm not saying that this feature is a must, I just wanted to emphasize that it is a little bit less touchy subject than the (scalar) input typehints. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Gauging Interest:RFC to add map() function
Hello Jeremy,
On Wed, Jun 26, 2013 at 8:20 AM, Jeremy Curcio j.cur...@icloud.com wrote:
Hello,
I would like to submit an RFC to add a new function to the PHP language.
The function would be called map(). The purpose of this function would be
to take an existing value within a range and make it to a corresponding
location within a new range.
A map() function is normally part of functional programming and as such
would cause confusion and likely would not mean what most programmers would
assume. See python and JS docs:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map
http://docs.python.org/2/howto/functional.html
Yes; we do have array_map; but I still do not assume that this would be
a mathematical function.
The map() method would have 5 required parameters, $originalLow,
$originalHigh, $newLow, $newHigh, and $value.
map() would be implement the following:
function map($originalLow, $originalHigh, $newLow, $newHigh, $value) {
return $newLow + ($value - $originalLow) * ($newHigh - $newLow) /
($originalHigh- $originalLow);
}
I am curious with something that is so easy; why would you want it in core?
Example:
Let's say we are teachers and are grading final exams. We have a policy
that the best score is 100, and the worst score is a 70. Students scored
between 55 and 92. We want to easily re-score the exams to be within the
new score range, so we would use the new map() function. Let's begin with
mapping the lowest score:
$newScore = map(55, 92, 70, 100, 55); //$newScore = 70
If we have all of our scores in an array:
$scores = array(71, 65, 55, 85, 88, 86, 92, 77, 73);
We could use a foreach loop to remap each value:
$newScores = array();
foreach($score as $scores) {
$newScores[] = map(55, 92, 70, 100, $score);
}
var_dump($newScores);
/*
array(9) {
[0]=
float(82.972972972973)
[1]=
float(78.108108108108)
[2]=
int(70)
[3]=
float(94.324324324324)
[4]=
float(96.756756756757)
[5]=
float(95.135135135135)
[6]=
int(100)
[7]=
float(87.837837837838)
[8]=
float(84.594594594595)
}
*/
Just like that, we have the new exam grades that fit our policy, within
the proper scale, without having to do any of the messy math ourselves.
While I do recognize that this is somewhat trivial to anyone who knows the
proper formula, I feel as though it would serve the PHP community well.
Much the same as the pow() or pi() functions do. I appreciate your thoughts
on this matter and whether or not this is worth pursuing as an RFC.
Thank you,
Jeremy Curcio
j.cur...@me.com
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
Hi! Currently PHP doesn't support what could be a good feature for code quality, return typing (or if you prefer to call it: return type hinting). What changed since the last time we discussed this? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] UNKNOW:0, what is it?
Hello, Again, I have a segfault with RecursiveDirectoryIterator when I extend it. This time, I have a very strange value on my SplFileInfo extension (subclass). When I var_dump the value, I have UNKNOWN:0. This is not a string, not null, not false, just UNKNOW:0, without type. Any idea of what is it? Thanks :-). -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Gauging Interest:RFC to add map() function
I am curious with something that is so easy; why would you want it in core?A lot of the Math Functions could be considered "so easy".abs() could be written out as: function abs($n) {if ($n = 0) return $n;else return $n*-1; }pi() could be replaced by simply setting a global variable equal to 3.14159265358979floor() could be written out as: function floor($n) {$stop = strpos($n, '.'); if ($stop !== false) return substr($n,0,$stop);else return $n }ceil() could be written out as: function ceila($n) { $stop = strpos($n, '.'); if ($stop !== false)return 1+substr($n,0,$stop); else return $n; }The above examples are just a few that stick out to me I'm sure that looking through the list of available math functions would provide a few more examples. Keeping these examples in mind, I don't follow the logic of range mapping being too easy toimplementmanually whenever it is needed to not warrant being included in core.
Re: [PHP-DEV] Gauging Interest:RFC to add map() function
On Wed, 2013-06-26 at 16:09 +, Jeremy Curcio wrote: The above examples are just a few that stick out to me I'm sure that looking through the list of available math functions would provide a few more examples. Keeping these examples in mind, I don't follow the logic of range mapping being too easy to implement manually whenever it is needed to not warrant being included in core. The mentioned functions are very very very common math functions. Your map() is relatively specialized. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UNKNOW:0, what is it?
On Wed, 2013-06-26 at 18:05 +0200, Ivan Enderlin @ Hoa wrote: Hello, Again, I have a segfault with RecursiveDirectoryIterator when I extend it. This time, I have a very strange value on my SplFileInfo extension (subclass). When I var_dump the value, I have UNKNOWN:0. This is not a string, not null, not false, just UNKNOW:0, without type. Any idea of what is it? Thanks :-). Unknown is an unknown value in a structure when a zval is not properly set. Most likely you didn't call the parent's constructor. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UNKNOW:0, what is it?
On 26/06/13 18:19, Johannes Schlüter wrote: On Wed, 2013-06-26 at 18:05 +0200, Ivan Enderlin @ Hoa wrote: Hello, Again, I have a segfault with RecursiveDirectoryIterator when I extend it. This time, I have a very strange value on my SplFileInfo extension (subclass). When I var_dump the value, I have UNKNOWN:0. This is not a string, not null, not false, just UNKNOW:0, without type. Any idea of what is it? Thanks :-). Unknown is an unknown value in a structure when a zval is not properly set. Most likely you didn't call the parent's constructor. To bad, the constructor has been called :-(. The error is here: https://github.com/hoaproject/Iterator/blob/master/Recursive/Directory.php#L125. This is a line that causes the segfault. And at line 109, $this-getRelativePath() returns UNKNOWN:0. But if I var_dump $this-_relativePath directly (without using the method), I have a real value. I can't explain this. -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
All, I've updated the RFC, renaming Protocol Type Hinting to Structural Type Hinting (keeping the name of the file for historical reasons). I've also expanded out the use-cases with a dedicated section and two examples (middlewares and third-party specified standard interfaces)... Thoughts? Anthony On Wed, Jun 26, 2013 at 11:03 AM, Anthony Ferrara ircmax...@gmail.comwrote: Robert, On Wed, Jun 26, 2013 at 10:52 AM, Robert Stoll rst...@tutteli.ch wrote: I had a quick look at GO and as far as I understand they do not use duck typing but a structural type system. http://golang.org/doc/faq#implements_interface Please change this in your RFC to avoid misunderstandings. Great idea. I'll update the RFC and code to call it structural typing instead of protocol. A much better term... Thanks!
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 6:02 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Currently PHP doesn't support what could be a good feature for code quality, return typing (or if you prefer to call it: return type hinting). What changed since the last time we discussed this? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 Hi, Well I don't want to sound disrespectful, but to be honest, nothing really. Just the year and the fact that I don't want to allow for double return types, like object or null or false, like in the other proposal, if you would read the gist. While I would like to have full type hinting available, including scalars as well, I think we could greatly benefit from it even without them. Like I've said, it's about code quality, something that PHP programmers lack today badly because PHP is so flexible (don't even try to argue with that). As for the argument of don't design features that are optional, like you've said in the past discussion, here's a optional feature that everyone uses it today: argument type hinting. Is it optional, yes? Could we live without it? Yes. Would everyone be sane without it? Not sure. PHP is too flexible for its own good. The fact that we have good use cases for such a feature, just look at the thread so far, makes is useful to consider. And I don't understand why having return typing would be such a bad thing when we already have argument typing, which is a half baked feature (even worst, no?) as it doesn't allow for scalar hinting. And just having this half baked feature in the language makes is very unattractive for some people and reduces the code quality, but for others it's extremely useful, do you want to argue that we don't need this because ? Best regards Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Gauging Interest:RFC to add map() function
On Wed, Jun 26, 2013 at 9:20 AM, Jeremy Curcio j.cur...@icloud.com wrote: Hello, I would like to submit an RFC to add a new function to the PHP language. The function would be called map(). The purpose of this function would be to take an existing value within a range and make it to a corresponding location within a new range. The functionality provided is uncommon but perhaps usefu. However, I am *very* against the name `map` which has a very established meaning in the programming world; others have already mentioned this but I felt I should mention it again.
Re: [PHP-DEV] RFC: Protocol Type Hinting
Hi! I think we should. And I think we should turn all non-engine related fatals into exceptions. But both are beyond the scope of this proposal... So, the question of what is the difference between the two errors remains unanswered. If the whole diff is that one of the errors has word recoverable in the message, it's not substantial difference at all and one that does not require new syntax and big change in the language. Internals should not be taking sides on what's good practice and what's bad practice (if it was, why the heck was goto introduced?). Instead, it Can we please lay the goto argument to rest? The argument goto was introduced, so feature X must too, because goto was introduced didn't sound good even the first time... should enable today's good practice to be followed. But it should not take a stand about bad practice. In my opinion, we should. We should not take into the language any concept that anyone considers useful in some particular piece of code. PHP language is very widely used, and we should consider how it would influence this huge ecosystem and if the overall effect would be beneficial and justify complicating (if there is one) the whole language system. Language is a system of thought and a system of approaching communication. IMO, this means it should have some principles and not just be a random bag of things that somebody at one point or another decided to stick into it, they should make sense together. PHP doesn't have the best reputation in this regard, but we are trying to make it better, not worse. It does not mean we should avoid change. It means we should have good reasons for change and carefully consider it. Good use cases IMO are prerequisite for that. My point here is that we should be judging features by their merit alone, and not by how we would use them. We also should not be judging them based upon our preferred style, but on the overall case of what it aims to achieve. IMO there's no merit in the feature besides its use. That's the only merit a feature could or should ever have. Bringing this back on point, Duck-typing is a very valid and accepted way of doing OOP. In fact most other dynamic languages use this as the basis for their OOP system. This proposal does nothing but attempt to In fact, most other dynamic languages don't even have parameter typing. Neither Perl, Python, Ruby or Javascript have it. Let alone typing of the kind you suggest. What they have we have too. Duck typing for them doesn't mean what you propose - it means what we already have, checking type at the point of use. Check https://en.wikipedia.org/wiki/Duck_typing and see the examples - most of them don't have any typechecks. Referring to most dynamic languages while promoting this proposal is a bit misleading. -- 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] Gauging Interest:RFC to add map() function
The functionality provided is uncommon but perhaps usefu. However, I am*very* against the name `map` which has a very established meaning in theprogramming world; others have already mentioned this but I felt I shouldmention it again.I'd like to note that I am not married to the name. If there is a better wayto reference what the function is doing then that could be the namethen by all means it should be used.
Re: [PHP-DEV] UNKNOW:0, what is it?
On Wed, 2013-06-26 at 18:21 +0200, Ivan Enderlin @ Hoa wrote: On 26/06/13 18:19, Johannes Schlüter wrote: On Wed, 2013-06-26 at 18:05 +0200, Ivan Enderlin @ Hoa wrote: Hello, Again, I have a segfault with RecursiveDirectoryIterator when I extend it. This time, I have a very strange value on my SplFileInfo extension (subclass). When I var_dump the value, I have UNKNOWN:0. This is not a string, not null, not false, just UNKNOW:0, without type. Any idea of what is it? Thanks :-). Unknown is an unknown value in a structure when a zval is not properly set. Most likely you didn't call the parent's constructor. To bad, the constructor has been called :-(. The error is here: https://github.com/hoaproject/Iterator/blob/master/Recursive/Directory.php#L125. This is a line that causes the segfault. And at line 109, $this-getRelativePath() returns UNKNOWN:0. But if I var_dump $this-_relativePath directly (without using the method), I have a real value. I can't explain this. Try calling the parent ctor before doing anything with properties (i.e. setting _splFileInfoClass) If it doesn't fit please provide a complete reproduce script (and report a bug in any case) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UNKNOW:0, what is it?
Hi! Again, I have a segfault with RecursiveDirectoryIterator when I extend it. This time, I have a very strange value on my SplFileInfo extension (subclass). When I var_dump the value, I have UNKNOWN:0. This is not a string, not null, not false, just UNKNOW:0, without type. Any idea of what is it? Most likely it is a bug, unless you did something wrong. I'd suggest submitting bug report with reproducing code. -- 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] UNKNOW:0, what is it?
On 26/06/13 18:30, Johannes Schlüter wrote: On Wed, 2013-06-26 at 18:21 +0200, Ivan Enderlin @ Hoa wrote: On 26/06/13 18:19, Johannes Schlüter wrote: On Wed, 2013-06-26 at 18:05 +0200, Ivan Enderlin @ Hoa wrote: Hello, Again, I have a segfault with RecursiveDirectoryIterator when I extend it. This time, I have a very strange value on my SplFileInfo extension (subclass). When I var_dump the value, I have UNKNOWN:0. This is not a string, not null, not false, just UNKNOW:0, without type. Any idea of what is it? Thanks :-). Unknown is an unknown value in a structure when a zval is not properly set. Most likely you didn't call the parent's constructor. To bad, the constructor has been called :-(. The error is here: https://github.com/hoaproject/Iterator/blob/master/Recursive/Directory.php#L125. This is a line that causes the segfault. And at line 109, $this-getRelativePath() returns UNKNOWN:0. But if I var_dump $this-_relativePath directly (without using the method), I have a real value. I can't explain this. Try calling the parent ctor before doing anything with properties (i.e. setting _splFileInfoClass) If it doesn't fit please provide a complete reproduce script (and report a bug in any case) https://bugs.php.net/65136 here we are :-). -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Gauging Interest:RFC to add map() function
From: Jeremy Curcio [mailto:j.cur...@icloud.com] Sent: 26 June 2013 17:10 To: Mike Willbanks Cc: PHP Internals Subject: Re: [PHP-DEV] Gauging Interest:RFC to add map() function I am curious with something that is so easy; why would you want it in core? A lot of the Math Functions could be considered so easy. ... floor() could be written out as: ... [sort-of-floor implemented in PHP] ... The above examples are just a few that stick out to me I'm sure that looking through the list of available math functions would provide a few more examples. Keeping these examples in mind, I don't follow the logic of range mapping being too easy to implement manually whenever it is needed to not warrant being included in core. Actually, that floor implementation will give incorrect answers in quite a few cases. floor is very difficult to implement correctly and efficiently for floating point numbers, which is why PHP offers a builtin function which delegates to the standard c lib's implementation of floor. See https://github.com/php/php-src/blob/642721b38a9c5ebf336c81027c0dafd6f9246bd6/ext/standard/math.c#L320 That's the same for the other Math functions you have listed: there is real benefit to allowing access to the *correct* and efficient standard C implementations. This is not the case for the map function you have proposed: there is not a corresponding builtin function in the C standard library, which is why PHP doesn't offer it as a builtin. There is another serious problem with the proposal: the name map already has a specific meaning in programming languages: http://en.wikipedia.org/wiki/Map_(higher-order_function) http://php.net/manual/en/function.array-map.php For this proposal to have any traction, you need to: * demonstrate why PHP programmers need this implemented for them (e.g. for the floor func, it is easy to find tricky edge cases which justify the C lib's existence) * come up with a name which is self-explanatory and discoverable to users of PHP (i.e. if a PHP programmer needs to map floats from one range to another range in a linear fashion, what will they search for? 1-d affine transform PHP, perhaps?) TBH, I don't think this proposal has much chance of being accepted (I don't have voting rights BTW). Best, Rich Richard Bradley Tel : 020 7485 7500 ext 3230 | Fax : 020 7485 7575 softwire Sunday Times Best Small Companies - UK top 20 three years running Web : www.softwire.com | Addr : 325 Highgate Studios, 53-79 Highgate Road, London NW5 1TL Softwire Technology Limited. Registered in England no. 3824658. Registered Office : 13 Station Road, London N3 2SB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
Johannes,
2013/6/26 Johannes Schlüter johan...@schlueters.de:
So a function author doesn't trust himself and therefore we change the
language syntax?
In the following example:
class Foo {
public function bar($input) {
$return = Baz::foo($input);
if (!$return instanceof ReturnType)
trigger_error(Cannot divide by zero, E_USER_ERROR); //
or throwing some RuntimeException
return $return;
}
}
Baz class can be from a 3rd party software and I may want to enforce
the fact that my Foo::bar() method returns an instance of ReturnType
or throw an exception or trigger an error.
This is moez easily written with this proposition:
class Foo {
public function ReturnType bar($input) {
return Baz::foo($input);
}
}
With the same reasoning you had, you would avoid using parameter type
hinting and interfaces for your own project if there's no other people
using it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Gauging Interest:RFC to add map() function
Aside from the previously expressed reservations to the name map(), is anyone actually comfortable with *five* required arguments? That's serious cognitive overload; a more concise API is needed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] hex2bin: E_WARNING is too much for odd string?
Hi all,
hex2bin raises E_WARNING for odd length hex strings from PHP 5.4.1.
http://jp2.php.net/manual/en/function.hex2bin.php
However, just returning FALSE is easier for programmers.
Current behavior requires additional length check for bad hex to prevent
E_WARNING.
$str = 'abZ';
if (strlen($str)%2) {
// BAD hex - invalid length
} else if (hex2bin($str) {
// BAD hex - invalid char
}
Instead, it would better that hex2bin() just returns FALSE for invalid hex,
IMHO.
$str = 'abZ';
if (strlen($str)%2) {
// BAD hex - invalid length or char
}
I can understand current behavior as BC. However, it would better cleanup
bad spec sooner or later.
PHP 5.4: Raise E_ERROR and return FALSE for invalid length.
PHP 5.5: Just return FALSE.
or
PHP 5.4: Keep current behavior
PHP 5.4: Riase E_ERROR and return FALSE for invalid length.
PHP 5.5: Remove E_ERROR.
Any ideas?
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] Re: hex2bin: E_WARNING is too much for odd string?
Typo 2013/6/27 Yasuo Ohgaki yohg...@ohgaki.net PHP 5.4: Keep current behavior PHP 5.4: Riase E_ERROR and return FALSE for invalid length. PHP 5.5: Remove E_ERROR PHP 5.4: Keep current behavior PHP 5.5: Riase E_ERROR and return FALSE for invalid length. PHP 5.6: Remove E_ERROR -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] hex2bin: E_WARNING is too much for odd string?
On Wed, Jun 26, 2013 at 9:21 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, hex2bin raises E_WARNING for odd length hex strings from PHP 5.4.1. http://jp2.php.net/manual/en/function.hex2bin.php However, just returning FALSE is easier for programmers. Why is it easier? If you pass an odd length string to hex2bin you have malformed input, which is usually a bug on the programmers side. Not having a warning would make the issue harder to debug. Nikita
Re: [PHP-DEV] hex2bin: E_WARNING is too much for odd string?
Hi Nikita,
2013/6/27 Nikita Popov nikita@gmail.com
Why is it easier? If you pass an odd length string to hex2bin you have
malformed input, which is usually a bug on the programmers side. Not having
a warning would make the issue harder to debug.
It's good to have uniformed error handling.
Therefore, E_WARNING for 'bad chars' is alternative.
hex2bin('abcZ'); // E_WARNING for invalid char
hex2bin('abc'); // E_WARNING for invalid length
(Users can handle errors via custom error handler)
or
hex2bin('abcZ'); // return FALSE since there is invalid char
hex2bin('abc'); // return FALSE since it has invalid length
(Users should catch errors via their validation/error handling code)
I think either raising error or returning false is OK, but it's not good
have(mix) both for a function. It's not mandatory, though.
It would be nice if there is error/exception handling guideline for
module authors for uniform error/exception handling. IMHO.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] hex2bin: E_WARNING is too much for odd string?
Hi 2013/6/26 Yasuo Ohgaki yohg...@ohgaki.net: PHP 5.4: Keep current behavior PHP 5.4: Riase E_ERROR and return FALSE for invalid length. PHP 5.5: Remove E_ERROR. Never ever will we raise an E_ERROR. E_ERROR means that we left the Engine in a state from which we cannot recover from, standard library function should never prevent execution of a script as this will introduce inconsistency, if we leave the Engine in a 'recoverable' state, then we should use E_RECOVERABLE_ERROR, but this is far from that. We already fixed a few of those in the past, I believe when 5.3 was shipped, we had pretty much killed all of those along when the new parameter parsing API was being standardized. I agree that this E_WARNING is sort of serve, and we should just return false for invalid values, as we don't need to be THAT detailed, maybe an E_NOTICE could work better here even in case something fails and the developer must know WHY this happened, I believe we do this in a few places around the core and its extensions. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] hex2bin: E_WARNING is too much for odd string?
2013/6/27 Kalle Sommer Nielsen ka...@php.net 2013/6/26 Yasuo Ohgaki yohg...@ohgaki.net: PHP 5.4: Keep current behavior PHP 5.4: Riase E_ERROR and return FALSE for invalid length. PHP 5.5: Remove E_ERROR. Never ever will we raise an E_ERROR. E_ERROR means that we left the Oops. I meant E_WARNING which is current hex2bin() raising for invalid length. -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] hex2bin: E_WARNING is too much for odd string?
Hi Kalle, Thank you for notifying E_ERROR/E_WARNING mistake. 2013/6/27 Kalle Sommer Nielsen ka...@php.net We already fixed a few of those in the past, I believe when 5.3 was shipped, we had pretty much killed all of those along when the new parameter parsing API was being standardized. hex2bin() is PHP 5.4 function and the behavior was change by PHP 5.4.1 so that raise E_WARNING for invalid length. I agree that this E_WARNING is sort of serve, and we should just return false for invalid values I prefer returning FALSE. Raising E_WARING/E_NOTICE for all invalid hex would work, too. maybe an E_NOTICE could work better here even in case something fails and the developer must know WHY this happened, I believe we do this in a few places around the core and its extensions. Yes, there are. We would be better to have error/exception handling guideline for consistent behavior for future releases. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Who's incharge of github pull requests?
2013/6/26 Lior Kaplan lio...@zend.com: Hi Felipe, Indeed I saw more responsiveness for the pull requests (mine and others), thanks. The question was about the process of reviewing these requests. 1. Do we have someone in charge (making sure they pass some minimum requirements) or this is done sporadically ? There are some core devs looking and triaging pull requests, but nobody is officially in charge to. Everyone with the needed karma can to do it. 2. If we do it sporadically, how do we make sure things aren't lost or get stuck (causing us to lose good patches). Yes, most of us are volunteers (both the developers and the patch senders) and this reflects on time issues. With that said, both sides have interest of seeing more patches sent and accepted. As I have experience with this on other projects, I'm trying to help improve the status here. Of course, I'm willing to personally help here, so I'm not just asking you guys to handle this yourselves. Kaplan Cool, so ask for a git account and join us! http://www.php.net/git-php.php On Wed, Jun 26, 2013 at 5:28 PM, Felipe Pena felipe...@gmail.com wrote: Hi, I saw some patches from you (mentioned in the blog post) has been pushed to git. About the FTP patch, as it requires further testing and an environment for such, and we do not have an active maintainer currently for the extension. It tend to have a delay until anyone with free time (most of we are volunteers), and cares about testing the patch for such extension, to get it applied. Thanks for contributing! 2013/6/16 Lior Kaplan lio...@zend.com: Hi, It seems the list of pull requests on github is getting bigger, who's inchange to review it? https://github.com/php/php-src/pulls I must say that my experience so far in trying to push patches through the bug system or pull request is quite deprsing (comparing to other open source projects): https://liorkaplan.wordpress.com/2013/06/05/getting-patches-into-php/ Kaplan -- Regards, Felipe Pena -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Session Id Collisions
Hi, Sorry for the long delay, I've sent pull requests https://github.com/php/php-src/pull/368 https://github.com/php/php-src/pull/367 https://github.com/php/php-src/pull/366 Thank you for your time. -- Yasuo Ohgaki yohg...@ohgaki.net 2012/12/24 Yasuo Ohgaki yohg...@ohgaki.net Hi stats and others, Sorry for the delay. I've finally updated the strict session patch. Following diff is against PHP-5.3, but 5.4 and others will be mostly the same. https://github.com/yohgaki/php-src/commit/42dcd8ef7cd2f9f2071b16586822dadd647c96ef I was promised to create separate patch for session id collision detection, but the patch is also in the diff. I left comments for the if statement handles collision. If you still prefer to have separate patch, I'll do it when I send pull requests. If nobody has comment, I'll create patch for 5.4. If you read this patch closely, you'll see that this patch accesses PS(id) global directly due to limitation of current API. It would be good to have new API for 5.5, I think. BTW, this patch fixes bug #60634 as a side effect also. https://bugs.php.net/bug.php?id=60634 Comments are appreciated. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Re: hex2bin: E_WARNING is too much for odd string?
Hi all,
I've sent pull request for PHP-5.5 branch.
https://github.com/php/php-src/pull/369
It's simple 1 liner removes E_WARNING for invalid length.
Are there any objections?
If not I'll merge it to PHP-5.5 and master, then update docs.
--
Yasuo Ohgaki
yohg...@ohgaki.net
2013/6/27 Yasuo Ohgaki yohg...@ohgaki.net
Hi all,
hex2bin raises E_WARNING for odd length hex strings from PHP 5.4.1.
http://jp2.php.net/manual/en/function.hex2bin.php
However, just returning FALSE is easier for programmers.
Current behavior requires additional length check for bad hex to prevent
E_WARNING.
$str = 'abZ';
if (strlen($str)%2) {
// BAD hex - invalid length
} else if (hex2bin($str) {
// BAD hex - invalid char
}
Instead, it would better that hex2bin() just returns FALSE for invalid
hex, IMHO.
$str = 'abZ';
if (strlen($str)%2) {
// BAD hex - invalid length or char
}
I can understand current behavior as BC. However, it would better cleanup
bad spec sooner or later.
PHP 5.4: Raise E_ERROR and return FALSE for invalid length.
PHP 5.5: Just return FALSE.
or
PHP 5.4: Keep current behavior
PHP 5.4: Riase E_ERROR and return FALSE for invalid length.
PHP 5.5: Remove E_ERROR.
Any ideas?
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] ENT_ALL or similar option for htmlspecialchars[_decode]?
I just noticed that htmlspecialchars_decode doesn't convert entities like #10 and #13. Is there a bitmask I'm missing or are those simply not supported right now? If the latter, any thoughts on adding something along the lines of ENT_ALL to convert all valid entities from/to their respective characters? --Kris
Re: [PHP-DEV] Re: hex2bin: E_WARNING is too much for odd string?
On Wed, Jun 26, 2013 at 9:05 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, I've sent pull request for PHP-5.5 branch. https://github.com/php/php-src/pull/369 It's simple 1 liner removes E_WARNING for invalid length. Are there any objections? Yes, I object to removing the error in the same breath we're arguing for consistency. 5.4.0 through 5.4.3 (no error), 5.4.4 through 5.4.16 (error), 5.5.0 (error), 5.5.1 (no error)??? What kind of consistency is this? I thought you wanted to add an extra error for malformed hex, which I would have been fine with, but removing the error entirely? The error is useful. It informs the user that they may have buggy code since the function is clearly documented to expect even length hex encoded strings. If not I'll merge it to PHP-5.5 and master, then update docs.
Re: [PHP-DEV] Re: hex2bin: E_WARNING is too much for odd string?
Hi Sherif, I would like to have consistent behavior at least within a function. 2013/6/27 Sherif Ramadan theanomaly...@gmail.com I thought you wanted to add an extra error for malformed hex, which I would have been fine with, but removing the error entirely? The error is useful. It informs the user that they may have buggy code since the function is clearly documented to expect even length hex encoded strings. It is good to have additional errors for invalid inputs. It would be beneficial for many users. I've checked some conversion(decoder) functions quickly. Functions raise E_WARNING / E_NOTICE for invalid inputs unserialize() convert_uudecode() xmlreader module Functions simply return FALSE for invalid inputs base64_decode() pg_unescape_bytea() mb_decode_mimiheader() mb_decode_numericentity() mb_convert_kana() mb_convert_encoding() mb_convert_variables() Note: mbstring functions raise errors for invalid encoding, otherwise simply return FALSE. Functions do not check validity quoted_printable_decode() xml_utf8_decode() - replaces bad chars to '?' Functions have separate error message function json_decode() - returns FALSE, but can get errors via json_last_error() Decoding errors are usually a bug or some kind of attack, so I agree to add E_NOTICEs. Exception is decoders that supposed to accept external inputs. e.g. base64_decode() and mbstring functions. I think pg_unescape_bytea() should raise E_WARNING, so I'll add it later. Adding E_WARNING to it will never be BC issue. It's obvious bug. hex2bin() will not be used for handling external inputs almost always, so raising E_WARNING make sense. I've updated pull request. (Added E_WARNING for bad hex) https://github.com/php/php-src/pull/369 Everyone is OK with this? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] UNKNOW:0, what is it?
On Thu, Jun 27, 2013 at 12:47 AM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: On 26/06/13 18:30, Johannes Schlüter wrote: On Wed, 2013-06-26 at 18:21 +0200, Ivan Enderlin @ Hoa wrote: On 26/06/13 18:19, Johannes Schlüter wrote: On Wed, 2013-06-26 at 18:05 +0200, Ivan Enderlin @ Hoa wrote: Hello, Again, I have a segfault with RecursiveDirectoryIterator when I extend it. This time, I have a very strange value on my SplFileInfo extension (subclass). When I var_dump the value, I have UNKNOWN:0. This is not a string, not null, not false, just UNKNOW:0, without type. Any idea of what is it? Thanks :-). Unknown is an unknown value in a structure when a zval is not properly set. Most likely you didn't call the parent's constructor. To bad, the constructor has been called :-(. The error is here: https://github.com/hoaproject/Iterator/blob/master/Recursive/Directory.php#L125. This is a line that causes the segfault. And at line 109, $this-getRelativePath() returns UNKNOWN:0. But if I var_dump $this-_relativePath directly (without using the method), I have a real value. I can't explain this. Try calling the parent ctor before doing anything with properties (i.e. setting _splFileInfoClass) If it doesn't fit please provide a complete reproduce script (and report a bug in any case) https://bugs.php.net/65136 here we are :-). thanks for the report, fixed in https://github.com/php/php-src/commit/fa8611c81ee72839cdff3e72b18cc586feb4aa29 thanks -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
