> 6 авг. 2017 г., в 16:30, Dan Ackroyd <dan...@basereality.com> написал(а):
> Andrew Nester wrote:
>> I am thinking about writing an RFC for this and continue discussion there.
>> Will it be a good idea?
> You're apparently not very good at listening to suggestions, so I'll
> be more direct.
> I think you're wasting people's time until you actually try seeing if
> PDO can be made to work with userland classes or not.
> The next step should be you (or anyone else) attempting to make the
> required changes to PDO to make it work, to discover what changes
> would be needed to allow using userland classes.
> If it isn't known what is needed to do to support it working, there is
> no point raising the RFC.
> Johannes Schlüter wrote:
>> The actually question is: Why not?
> My understanding is that some of the internal code that calls userland
> functions and methods is basically bogus.
> I had a PR (which I haven't had the energy to get round to sorting
> out) to make the SPL call userland constructors correctly:
> My surprise level would be zero, if there were similar issues in PDO
> instantiating user classes, or other issues like the internal code
> accessing properties directly without going through method access.
> On the other hand, it might 'just work'.
Thanks for your feedback, I appreciate this.
Yes, I understand what you mean.
Fixing using this PDO attribute will solve issue with persistent PDO and will
allow to customize PDO in all cases.
But what I want to suggest is more straightforward way to customize PDO
behaviour and have proper type hints at the same time, because at my opinion
using PDO attributes for customization is not very straightforward.
I shown you some examples of use cases of these interfaces. As I think example
from Doctrine DBAL shows that this might be useful. Let me know if you would
like to see some others.
I would like to hear some arguments why my proposed solution will not work or
what exactly wrong with interfaces proposed and solution in general.
Thanks in advance.
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php