> > First of all, one quick note: there is a convention here that you should > not post above the quoted text, so please keep that in mind. >
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 :) > As a basic premise, retrieving the SQL is already possible at present: > > ``` > $sql = $stmt->queryString; > ``` > > What you are trying to implement for SQLite this time makes it possible to > retrieve the SQL in either its pre-binding or post-binding state, so it is > slightly more capable than the property above. > 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. If so, I think it would be better to make these new features methods > instead, which would also make it clearer that they are SQLite-specific > functionality. > > This has another advantage as well: it would make it possible to declare > the return type explicitly. > 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. -- Ilia Alshanetsky Technologist, CTO, Entrepreneur E: [email protected] T: @iliaa B: http://ilia.ws
