Re: memcache(3) 1.2.0 released...

On Tue, 2005-01-11 at 22:28 -0800, Sean Chittenden wrote:
> >  So, I've been thinking about the wrapper more, and it seems there is 
> > a fundamental design decision I need to make right off.  Should I...
> >
> >  1) Wrap the c api as closely as possible using procedural functions 
> > and return a resource id to the php programmer they need to track like 
> > the memcache struct in the c api.  (kind of like the original php4.x 
> > and prior mysql api which very closely models the c api).
> 
> Yuk, please no.  A C API should not be propagated as a function API to 
> a language that supports OOP.  Heresy you shall have committed.

I got several other comments offlist to the same effect, so I'll go
forward with an oo design for the php api.  I suspect I will model this
off the Ruby api, but since I haven't yet reviewed the Ruby api I can't
be sure :)

The one major complaint I have with the current php oo api's (and
possibly the Ruby api) are that they simply return FALSE (nil for Ruby?)
for an unfound key, thus breaking the ability to store arbitrary binary
data as I now cannot store a FALSE, or a binary equivalent in memcache.
(I do actually store a good number of NULL's which do work, but it is
close enough to a problem to make me uncomfortable). 

Perhaps, I'll always return as an array('key'=>'value', ...,
'keyn'=>'valuen') and the way to determine a miss is simply that the key
does not exist at all, and then NULL or FALSE are valid data from the
cache.  

If I did this as a php5 module, maybe I'd just throw an exception... but
alas I need to use php4.

> 
[snip]

-- 
John A. McCaskey
Software Development Engineer
Klir Technologies, Inc.
johnm@xxxxxxxx
206.902.2027