Re: Proposal for new package
| From: | Philippe Jausions | 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