Hi Ian,
> The main point here is that the only thing really
provided by the
> RPCBlogger base class is the factory method and some
constants. There's
> no reason to have those in the driver classes, so I
suggest that you
> split them out one way or another.
Yes, I see your point. But the RPCBlogger class also
contains prototypes
for two basic functions of any blogging system; which are
likely to be
implemented by all API's. That is why the class is present
in the first
place, it's primary objective is to provide the
"no-frills" base for all
drivers.
Separating the two classes would be fine, but that's
repetition of code.
The base classes are abstract and so we can't merge all
possible methods
into one class; since that will force drivers to implement
methods that
they don't even support.
> Is there any reason why you couldn't make this
abstract enough to work
> with both methods?
Interesting idea. Some implications though: Both methods use
different
protocols. And that would make this single package dependent
on two PEAR
packages instead of only one now: XML_RPC and XML_Atom; when
someone may
not even use the drivers require XML_Atom or vice versa.
Won't it be better if we have two separate packages, each
dependent one
only one more package that it requires?
Cheers,
--
Anant
Find Freedom, Go Open Source!
http://www.kix.in/
--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php
|