Re: Re: Final RFC for Net_SMPP/Net_SMPP_Client

On Tuesday 19 July 2005 04:02 pm, Philippe Jausions wrote: > Ian Eure wrote: > > On Tuesday 19 July 2005 03:06 pm, Pierre-Alain Joye wrote: > >>On Tue, 19 Jul 2005 14:58:09 -0700 > >> > >>>So you advocate making a project harder to use because it's > >>>internal structure (which should never be used directly) doesn't > >>>match the PEAR conventions? That seems like a pretty bad > >>>trade-off to me. > >> > >>In what is it harder? > > > > It's harder because you need to read the SMPP specification, then read > > additional documentation about how Net_SMPP works relative to that > > document. If Net_SMPP follows the spec closely, you only have to learn a > > few functions, instead of relearning part of the actual spec. > > As simple line in the doc, such as "All operation names follow the > studlyCaps notation. As such, Net_SMPP_Command_SubmitSm represents the > 'submit_sm' command." > Certainly, but there's a definite logistic disconnect you have to maintain to code this way. I'd also have to hack the code to know that e.g. the 'submit_sm' command, when parsed, needs a different class. What I'm looking for here is a good reason why I should break adherence to the SMPP specification in favor of the PEAR CS. So far, the only argument I've gotten is "because you have to follow PEAR CS," while ignoring many significant cases where it's a bad idea, or they are ignored with no good reason. There are definitely other approaches, but I feel that there are significant disadvantages to them. The options as I see them are: 1. As is, SMPP command classes contain underscores. I prefer this, since it's the most straightforward. 2. Change class names & update code to use camelCase. Would require users to use non-SMPP command names in their code, as well as changing how classes are created internally. 3. #2, but with a translation array; command_name -> include_path. Seems like more work and wasted memory to adhere to a standard that makes no sense in this scenario. I'd like to see some well-reasoned arguments as to why #2 or #3 are better than #1. > As far as PHP_Compat is concerned, the file name matches the function > declared inside of it, which MUST be the same as PHP declare them for > obvious reasons. > Poppycock. PHP_Compat could easily have it's files named fileGetContents.php or isA.php, and map the actual function name to include name. But it doesn't.

Attachment: [application/pgp-signature]