Re: [RFC][DISCUSSION] Object-oriented curl API v2
Thanks Larry!
> 1. I don't think the Curl\Option namespace is necessary. They can just be in the main
> Curl namespace.
I don't feel strongly here, but I thought it would be nice to group
the enums (if we go the multiple enum route) for discoverability.
Thoughts?
> 2. Please don't name the exception "Exception". It needs some slightly more
> useful name, to avoid confusion in a file that also uses \Exception.
Fair point! I could use the previous RFC's HandleException class name,
barring your next point...
> 3. I realize Handle is the name from the procedural API, but it's not very
> self-descriptive. Without knowing Curl, it's non-obvious that it's a self-executing
> request object. Is there a better name we could find while we're at it?
I'm open to this, but I don't have a suggestion myself.
> 4. Love the use of aviz. :-)
Thanks :) I was happy to be able to use it here.
> 5. Now here's the big one: Using enums rather than a bunch of constants is a good change.
> However, I feel like it doesn't go far enough.
> ...
> As a worst case, perhaps the top-20 options or so could be converted to methods/properties, and
> the rest left to be ugly flags?
I think my hesitation here is related to Ben's sibling response: I
want to thread the needle between making small improvements to the
low-level API while translating them to object-oriented equivalents,
and making a high-level API. The latter, I think, would invite a lot
more discussion, and would be potentially hard to get right.
That said, maybe your suggestion does thread that needle; having a
method / property for the N most-used options is still relatively
low-level since it's not expressing an opinion on how they should be
used. I'm not sure.
Thread (21 messages)