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.
