On Tue, Sep 13, 2011 at 2:07 AM, H.Merijn Brand <h.m.br...@xs4all.nl> wrote:
> The fact that the DBI is restrictive (or restricted) is a good thing.
> First of all most of the restrictions are based on well thoughtthrough
> decisions based on speed and use of resources. I do not have to take
> those decisions again when implementing a DBD. The whole infrastructure
> is there just for grabs, which is the second point. Even though
> possibly I could have written some of that code more efficiently in the
> DBD directly, I will not have the maintenance burden for that code, not
> do I have to verify that the code is working correctly. I have all
> other DBD's do that with - and for me.
So if there are parts of DBI where something, for instance, checks if
$unknown is a statement handle
by checking C<$unknown->isa('DBI::sth')> or something like that, which
would break attempted duck typing,
those could be deprecated in favor of a new C<eval {$unknown->isaSTH}>
convention, to support duck typing.
Duck typing is a useful architectural technique that can be supported
by removing the barriers to it; just because
duck typing is supported that doesn't mean that single inheritance has
to be deprecated.
Are there aspects of DBI as it is today that actually block duck
typing? introducing explicit WhatAmI functions
would not IMO be burdensome, and as they would be new and not
interfere with legacy isa() checks they wouldn't
break anything (except of course something that uses those names in
derived code -- not likely.)
