Re: [PEPr] Comment on Networking::Net_SMPP

On Sunday 24 April 2005 05:58 am, you wrote: > bertrand Gugger (http://pear.php.net/user/toggg) has commented on the > proposal for Networking::Net_SMPP. > > Comment: > > I mean I don't see the interest of your static calls which will allways > redo the same thing. > I'm sorry, but I'm still not clear what you're talking about. Could you please reference the code you're discussing? > More dangerous: the static hide the sharing of data > thru globals. > Your example of client is tricky about that: direct and via object > "static" calls to finally access the same global structure. > I'll be looking at putting most of the globals into a static class var, though I'm not sure how I'll handle the vendor extension mechanism with that setup. > The includes chains are awfull. > In what way? Each class represents a portion of the PDU - the lowest layer, which contains the header and stuff which every PDU needs, is in the PDU class. Stuff dealing with the common problems posed by the different commands go in the Command class, and the specifics of a command go in it's own class. This seems logical to me, and convention is to have one class per file, so there we go. It's certainly less confusing than, say, HTML_QuickForm's element setup. > I've the feeling it's done to be "OO correct" but that result is worse as > a "flat" script. > Worse in what way? > I would encourage you to build a real class containing the config and > abandon this false factory idea. > This class has zero configuration information, so I still have no idea what you mean by this. Please reference the specific code (file & line numbers) to explain what you're talking about. > Sorry, if my frankness hurts... it's more that I like to use such a > package ! > I'm not offended, just confused. > 2 more little things: > * your directory structure is not right, check CS > The only inconsistency I see is in the command classes. e.g Net_SMPP_Command_submit_sm is in Net/SMPP/Command/submit_sm.php, instead of Net/SMPP/Command/Submit/sm.php. This is to maintain consistency with the SMPP spec - the commands have underscores, and it seems nonsensical to create a huge directory structure under Command when it serves no real organizational purpose. I'd need e.g. Command/Bind/Transmitter.php Command/Bind/Transmitter/Resp.php and so on. This would also create a large number of files named 'Resp.php', which seems like it would be far more confusing. I suppose I could change the class names to e.g. SubmitSm, but I'd prefer to be consistent with the spec. Any other devs have feedback on this? > * don't use unpack() without giving the length of items: PHP4.2.2 is buggy > in that case. > Do you have more information about this? I couldn't find any info about it in the manual, bugs.php.net, or Google. The length of items is specified by the format string... e.g. 'N' is always 4 bytes. Are you talking about specifying the repeat, e.g. 'N1'?

Attachment: [application/pgp-signature]