>
> Don't take it personnaly Bill, I've nothing against you, I just want
> to improve the way this module works. I'm extensively using the ZF and
> I thank you, the team, and the community for all the work done. But
> I'm still thinking there should be a closer look at this issue.
>
Thanks for that. I respect the intention to improve the framework. I'm not
involved as a contributor anymore, I'm just answering what my reasons were
for implementing it the way I did when I worked on it. It's up to you and
other motivated developers to get involved as contributors and guide the
future of the project.
Basically, I felt that it was confusing that a method may return different
types. I know PHP is a loosely typed language; it's not Java. So the
language permits this as a kind of "in-place" polymorphism, but in my
opinion, it's still not good design. Returning different types that are
related is okay (e.g. the Factory pattern), but returning totally distinct
types with no common interface is bad.
If we're talking about breaking backward-compatibility, I would probably
design separate methods find() and findMany() as Ádám suggested at the top
of this thread. find() would take a scalar for single-column primary key,
or an array for a multi-column primary key, but regardless would return at
most one single Zend_Db_Table_Row object. Null would indicate no match
(just like fetchRow() does currently).
findMany() would always return a Zend_Db_Table_Rowset object. If your
search matches no rows in the database, the Rowset would have a count() of
zero. The argument of findMany() must be an array. Each element of this
array could be a scalar for single-column primary keys, or else a nested
array for multi-column primary keys. The argument must be structured in
this way so it's unambiguous whether you mean an array of single-column
keys, or a single key of multiple columns. I suppose you could also allow a
single scalar for convenience, but if that's what you're searching for, why
not use find()?
Regarding the existence of Zend_Db_Table_Rowset as a class versus a simple
array, the default behavior provided by Zend_Db_Table_Rowset is little more
than what is required to be iterable and countable. This allows the default
usage to be like a simple array.
But you can't extend a simple array. You can extend a Rowset class. This
allows you to add custom functionality to groups of rows in a result set.
One example might be to calculate aggregates (see example in the manual).
Another example: $rowset->delete() could call delete() on each Row object in
that rowset. Or even something more complex, like a Rowset class to
represent tree-structured data.
There are several things I would have designed differently in Zend_Db, in
hindsight. But Zend had hired me to release ZF 1.0, and they made it clear
that their highest priority was the schedule. There wasn't time to do
careful design and community debate over every feature.
Regards,
Bill Karwin
--
View this message in context: http://www.nabble.com/find%28%29-returns-rowset-tp13527277p19114931.html
Sent from the Zend DB mailing list archive at Nabble.com.
没有评论:
发表评论