Re: Proposal for new package

From: Date: Thu, 14 Feb 2008 17:02:49 +0000
Subject: Re: Proposal for new package
References: 1 2 3 4 5 6  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-49156@lists.php.net to get a copy of this message
Jeff Trudeau wrote: > Philippe, these are valid points and I appreciate the feedback. The true > reason that this is not PHP-like to the end programmer is that I wanted to > keep the API syntax more akin to Java. I could have used __get and __set in > the manner you described, however it would be confusing to newcomers of PHP > how the values are set and retrieved. OOP is not difficult to grasp "$object->property = $value". > The way I have implemented get() and > set() allows elements to be indexed by numerical index or element key, > regardless of whether or not the set is associative or not. Hence my suggestion for ArrayObject instead, which I think would fit perfectly here to provide access to memcached entries. > I guess my goal was not only to introduce this functionality to PHP, but > also make it semi-transparent to those who have used Java's > Hash/LinkedHashSet. AFAIR Java doesn't have built-in associative array, but I may be wrong with new version of Java, so IMO it's not a good path to go down... -Philippe > On Thu, Feb 14, 2008 at 11:26 AM, Philippe Jausions < > Philippe.Jausions@11abacus.com> wrote: > >> Jeff Trudeau wrote: >>> To clarify, this library requires pecl_memcache in order to interface >>> with memcached. It is written in PHP (not C), and thus can't >>> communicate natively with memcached. >>> >>> I have attached the source and API docs, and a small test script. >>> Please let me know if you think this library would make sense as a PEAR >>> package. >>> >>> Thanks! >> Jeff, >> >> I still don't see the major advantage of the class over straight >> memcache usage, would care explaining a bit more. >> >> I did a cursory review of the code you attached (btw: next time please >> put it online to save everybody time) and it looks like basically a >> wrapper that doesn't provide much more than calling save() whenever >> needed (which might be convenient though.) >> >> On the code itself, CacheFactory class is not needed, put the >> getInstance() in CacheSet class instead, and make the >> CacheSet::__construct() protected or private. Use __get() and __set() >> for CacheSet accessor methods instead of get() and set(). I don't know >> the HashSet Java API but I have a gut feeling you might have copied it >> too closely and not taken advantage of PHP-specificities. For instance >> why not implementing SPL ArrayObject, __clone() __set(), __get()? >> >> And, don't use global variables, unless following the strict PEAR >> standards for naming (but I understand that it is not a PEAR proposal at >> this stage.) >> >> I didn't see any exception either, especially in the factory / >> construstor. Might be useful to throw some there in connection / >> settings issues. >> >> If you implement (some of) the suggestions above, you'd be a much better >> shape to propose it to PEAR, but that's just my opinion :-) >> >> -Philippe

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