[PEPr] Comment on Networking::AsteriskManager
| From: | Till Klampaeckel | Date: | Sat, 22 Mar 2008 18:50:57 +0000 |
| Subject: | [PEPr] Comment on Networking::AsteriskManager | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-49504@lists.php.net to get a copy of this message | ||
Till Klampaeckel (http://pear.php.net/user/till) has commented on the proposal for
Networking::AsteriskManager.
Comment:
Looking pretty good. I also like your idea about abstracting the Asterisk
API to make it easier for developers to hook their apps to it.
Speaking of returning arrays - they are so 90's! Since Christian (cweiske)
suggested it on my last proposal, I kinda fell in love (;-)) with the idea
to return objects from a class. An object of a distinct type with methods
to ask for data contained in it.
Not sure if I make sense, maybe this link illustrates what I mean:
<http://code.google.com/p/services-projecthoneypot/source/browse/trunk/Services/ProjectHoneyPot/Response/Result.php>
Last but not least - comments on your code:
* you should use visibility (e.g. __construct should be declared public)
* you should have your own exception class (Net_AsteriskManager_Exception
which extends PEAR_Exception)
* I'd put your class variables in a private array and implement __set()
and __get() so people can change them easily on runtime. (Make sure to
document with @property)
And even laster, but not leaster, I am wondering if it makes sense to
subclass the feature-set.
E.g. have all monitor related features in their own class, etc.. As you
noted different versions and plugins add features, so maybe your class
could reflect that. So if I wanted to add support for a plugin myself, I'd
subclass Net_AsteriskManager_Plugin_Foobar and that would extend an
interface etc..
Just food for thoughts!
Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=543
--
Sent by PEPr, the automatic proposal system at http://pear.php.net