memcache(3) 1.2.0 released...

[Sean Chittenden]

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

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

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

Yup.

> 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