Re: [fw-db] A question on coding design used for DB Statements.

Thanks again. I think the solution is good enough and understand that making
a new abstract method could break some already existing code.

Sadly, right now I'm in a fresh installation of Fedora 12 Alpha, so I don't
have direct access to Zend code (And the connection is not very good... not
looking forward to download), but I remember to have seen at least 2 more
methods that were in the same situation as _prepare.

Also, it seems like I was late by a day >=( You beat me! :)

Thanks for the feedback.

Ralph Schindler-2 wrote:
>
>
>
> Mamsaac,
>
>
>> method MUST be implemented, but there's no enforcing of it. I can see
>> that
>> extending classes (the one that I checked the most was
>> Zend_Db_Statement_Pdo) do implement the method.
>
> Ironically, I've recently noticed the same thing and create
>
> http://framework.zend.com/issues/browse/ZF-7708
>
> fixed in:
>
> http://framework.zend.com/code/changelog/Standard_Library/standard/trunk/library/Zend/Db?cs=17856
>
> This tends to happen with software that grows organically. I am sure it
> was on oversight.
>
>> So, I wonder why _prepare is not declared in Zend_Db_Statement as
>> "abstract
>> protected function _prepare($sql);".
>
> Since there is the possibility that people are implementing either the
> interface and/or extending the base class Zend_Db_Statement, I did not
> want to create a possible BC break in their code. So, instead of an
> abstract method that is required to be implemented, the base
> implementation now has an empty method called _prepare() that could be
> overridden in the extending classes. This is the safest route to go so
> that there is no BC break in cases where people have extended the base
> class.
>
> -ralph
>
>
>

--
View this message in context: http://www.nabble.com/A-question-on-coding-design-used-for-DB-Statements.-tp25193487p25285167.html
Sent from the Zend DB mailing list archive at Nabble.com.