memcache(3) 1.2.0 released...
sean at chittenden.org
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.
> 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
More information about the memcached