[PEPr] Comment on Networking::AsteriskManager

From: 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

« previous php.pear.dev (#49504) next »