Not sure i get what you mean. With "abstract functions" I include also
those in interfaces.
I haven't tried 7.2 yet, but i think what I'm proposing is already
supported (+ kelunik's RFC):
```
interface A{
function x(stdClass $foo);
}
interface B extends A{
function x($foo): stdClass;
}
An abstract function is a partial interface: I see no value in adding
exceptions to interface implementations, especially if you add that:
* only works with abstract classes, not interfaces
* has a too narrow use-case scenario (need more necessity and scenarios
with common patterns)
* just
Hello internals, I've just created a new RFC, you can read it at:
https://wiki.php.net/rfc/allow-abstract-function-override
Note: I have absolutely no idea how difficult implementing this would be,
as I have no C/internals knowledge. Thus, patches are very welcome - thank
you in advance if you
On 1/3/17 12:58 am, Adam Baratz wrote:
Merging responses here...
Are PARAM_STR_UNICODE, ATTR_UNICODE_STRINGS and PARAM_STR_ASCII the most
appropriate names?
Good point. Maybe instead:
* PDO::PARAM_STR_NATL
* PDO::ATTR_NATL_STRINGS
* PDO::PARAM_STR_CHAR
How does this
Results for project PHP master, build date 2017-02-27 20:29:02-08:00
commit: d98c31a
previous commit:b806287
revision date: 2017-02-27 19:21:51+00:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
The average PHP extension is dependent only on the PHP runtime it was
built for and probably one or more 3rd party libraries. However, a
special class of extensions (such as PDO drivers and much of the XML
family) have dependencies on other PHP extensions which may (or may
not) be preset at the
Merging responses here...
Are PARAM_STR_UNICODE, ATTR_UNICODE_STRINGS and PARAM_STR_ASCII the most
> appropriate names?
Good point. Maybe instead:
- PDO::PARAM_STR_NATL
- PDO::ATTR_NATL_STRINGS
- PDO::PARAM_STR_CHAR
How does this interact with different character sets used for the
>
