Re: Proposal for new package

> OOP is not difficult to grasp "$object->property = $value". This sort-of violates the old-school idea of encapsulation, that all properties of an object are accessed via accessor methods. I understand that this is ultimately what is happening with __get and __set, however it's not apparent to the end programmer whatsoever. > Hence my suggestion for ArrayObject instead, which I think would fit > perfectly here to provide access to memcached entries. This is interesting and at some point I may refactor CacheSets to use an internal ArrayObject instead of the internal array datatype that it's currently using. > 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... You're right about Java and associative arrays. I viewed this as an enhancement over Java's HashSet since PHP supports both. On Thu, Feb 14, 2008 at 12:02 PM, Philippe Jausions < Philippe.Jausions@11abacus.com> wrote: > 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 >