> Sorry my bad. PHP convention is a bit different from the mail client default. 
> I will improve, but habits take a while to break, so I can't promise this is 
> the last one :) 

No worries, I make that kind of mistake all the time too :)

> This is a slightly different functionality and connotation as you've 
> correctly pointed out. Therefore, it definitely warrants having it due to the 
> different functionality/capability. 

Implementing every feature that exists would increase the maintenance burden on 
the codebase, so it may be worth being a little cautious in deciding whether 
this should be implemented.

I suspect this is probably something Kamil is also concerned about.

Of course, if a good use case becomes clear in the discussion going forward, I 
would not oppose implementing it.

> I don't feel strongly about one way or the other. I'm happy to revise this 
> into a function if the consensus is that everyone is more comfortable with 
> parameters allowing either pre/post binding state to be returned, probably 
> defaulting to the pre-binding state.
> I don't think 2 methods are needed for functionality that is functionally 
> very similar. 
> 
> That being said, I still prefer an attribute because this isn't an actionable 
> function (like sqliteCreateFunction) but rather something that retrieves 
> information, which to me seems more appropriate for attribute retrieval 
> similar to Pdo\Pgsql::ATTR_RESULT_MEMORY_SIZE for example. 
> I don't think this warrants its own function and the value of setting a 
> return type seems minimal.

> Looking at pdo/PgSQL and pdo/SQlite they both limit custom functions to 
> things that change data. However, pdo/MySQL and pdo/Firebird break the 
> convention, each has a single custom function for info retrieval, so there 
> isn't technically as convention universally followed convention here.

I’m sorry, I just realized something very important.

The place where this should be implemented is the statement class, not the 
driver, right?
Drivers have subclasses, but statements do not.

So implementing this as a specialized method would not really be very practical 
after all…

One possible approach would be to add a method on the driver and pass the 
statement as an argument, but that seems very confusing to me.

So in this case, the implementation approach used in your PR may be the only 
realistic option after all…

Regards,

Saki


Reply via email to