memcache(3) 1.2.0 released...

Sean Chittenden sean at
Tue Jan 11 22:28:01 PST 2005

>  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.

>  or...
>  2) Wrap the c api into an object oriented archtecture to make it 
> easier to use/more intuitive to php users.

Yes, please!  This is how I did the Ruby API.  I'm going to add a few 
bits to the API to make it more loop friendly (in terms of the GC), but 
I'd advise using an OOP API instead of a functional API.  The C API is 
rather OOP in its style and should be easy to port to an OOP friendly 

>  The benefits I see of option #1, are that it keeps the two apis very 
> close so if the c api changes it may be easier to update, and since I 
> use the c api directly quite a bit, it means I don't have to remember 
> two different apis.

That's true...  but that's like voluntarily undergoing a lobotomy for 
the fun of it...  I'd say bite the bullet and use the OOP API.  You'll 
be happier in the long run... the Ruby API, for instance, has spoiled 

> The benefits I see on option #2, are that it may be more widely 
> adopted and used by others.  It may be easier for others to use, and 
> finally if a change occurs in the c api it is not likely to directly 
> affect the php api and I could update the module without having to 
> break php end users code.


> I'd like to get feedback from those on the list who have already 
> commented in support of a wrapper module as to which direction they 
> prefer to see it go.

Well, I'd prefer an OOP API, but to be honest, I haven't got much 
feedback on my Ruby API beyond, "cool!  What are your plans, are you 
going to do this, that, etc.?"

> It's really a toss up for me, I'd be able to use it either way.  Also, 
> I'm stuck with php 4.x for the moment for most of my work, so my first 
> desire will be to support it.  Are most others using php 5.x or 4.x?  
> I plan to support both, but I'd also like to get an idea of what 
> others need most to start with.

OOP if possible, but if you're looking for maximum exposure (and more 
work), provide both a functional API and an OOP API.  I think the PHP 
developers are borderline braindead in their API, but for historical 
reasons, I know their reasons... I just wish they had a more pervasive 
and firmer stance on providing upgrade paths and breaking with 
backwards compatibility.  PHP is going to be the next cobol.  -sc

Sean Chittenden

More information about the memcached mailing list