Backend function signatures are not compatible

[adamwight]

For example, Memcache::add() takes arguments (key, data, expiry), but Base::add() and IronMQ::add() start with the $data argument. It seems like the right thing to do is change the signature in Memcache::add to start with $data.

[miccheng]

Hmm... Would have to see how we can make sure it doesn't break backward
compatibility. Memcache is a key-value store. The rest are not like that. :/
On Sat, 21 Mar 2015 at 8:11 am Adam Roses Wight notifications@github.com
wrote:

For example, Memcache::add() takes arguments (key, data, expiry), but
Base::add() and IronMQ::add() start with the $data argument. It seems like
the right thing to do is change the signature in Memcache::add to start
with $data.

—
Reply to this email directly or view it on GitHub
#37.

[adamwight]

I was thinking that different backends could implement some new interfaces depending on their design, e.g. MessageQueue vs MessageKeyValueStore, but it seems pretty common that a backend could support both styles of access. So then we're left with the function name collision, again...

I'm not sure how to deal with the backwards compatibility thing, either. Maybe deprecate add() and introduce set(k,v) and push(v)?

[miccheng]

Thanks. The interface sounds like a sensible approach. Deprecating add() is
good - perhaps forwarding it to push() by default (with an deprecation
error log) and throwing an exception if there's more than 1 arg (which
would have been a set anyways).
On Fri, 27 Mar 2015 at 6:14 am Adam Roses Wight notifications@github.com
wrote:

I was thinking that different backends could implement some new interfaces
depending on their design, e.g. MessageQueue vs MessageKeyValueStore, but
it seems pretty common that a backend could support both styles of access.

I'm not sure how to deal with the backwards compatibility thing, either.
Maybe deprecate add() and introduce set(k,v) and push(v)?

—
Reply to this email directly or view it on GitHub
#37 (comment)
.

[adamwight]

Oops, I missed your message. Here's a rough patch, I'll refine a bit tomorrow. Please mention if you see anything I should do differently!

https://github.com/adamwight/php-queue/tree/queue_vs_kv

[miccheng]

Nothing that jumps out as "danger" to me. Just sad face to see so many FIXME and TODO. :(

[adamwight]

Ping! Just letting you know PR #43 is ready for review, at your convenience. Thanks!

[miccheng]

Thanks! Sorry, had been busy this few weeks at work.

[adamwight]

@miccheng - I badly confused myself while implementing IndexedFifoQueue, but I think I finally have a correct prototype. It uses two separate indexes to provide the different access styles: https://github.com/adamwight/php-queue/pulls

BTW, what's your preferred communication medium? Do you do IRC? Sorry to necrobump this thread.

[miccheng]

Can try DM me on Twitter? I'm @CoderKungfu on Twitter.