In an ideal world, whatever.pmod/USB.pmod would be a directory. That directory could contain pike classes, pods or .so files. If it were whatever.pmod/USB.so, there's no way to mix-in other modules into whatever.USB. If whatever.pmod/USB.so were moved to _USB.so, you could have whatever.pmod/USB.pmod/module.pmod that inherited _USB, and then other modules could be placed along-side that. I think in that situation pike would convert whatever.USB into a join-node, but my experience is that there can be unexpected results from that (there's a fair amount of magic there, imho).
That, combined with my sense that a library-glue module almost never expands beyond being a library-glue (which seems reasonable to me, really) leads me to my position that glue modules should always be leaf nodes in the module tree rather than branch nodes.
Of course, that's just my 2 cents.
Bill
On Jun 10, 2012, at 10:01 PM, Martin Bähr wrote:
On Sun, Jun 10, 2012 at 05:16:13PM -0400, H. William Welliver III wrote:
How about whatever.USB.Generic? That way, someone could write more specific driver modules such as whatever.USB.HID, for the libhid library, as an example. Even if it were IO.USB.Generic.Devices(), there's still plenty of precedent for a namespace that deep (Protocols.HTTP.Server.Port|Request, for example). And still way better than a lot of Java code! :)
is the problem that if USB is a cmod then it is not easy to add stuff without messing around with that code?
so you are suggesting to have the top level a pmod directory instead?
not sure i understand the problem, please elaborate.
greetings, martin.