Martin Stjernholm wrote:
"Stephen R. van den Berg" srb@cuci.nl wrote:
I now have a cmod which is in a subdir src/post_modules/USB, which gives me an USB.devices(), USB.Iterator(), USB.device() and USB.transfer().
I take it that neither USB.devices nor USB.device are objects, since they start with lowercase. What are the names of the objects that represent them?
Well, actually, since I never read this formally (objects should start with uppercase), I didn't realise that this was/is the convention in Pike. They actually are objects, so I'll rename things to: USB.Devices(), USB.Iterator(), USB.Device() and USB.Transfer() instead.
Now, what if I'd like it to start with: object dev=USB(); (and then the rest with foreach() etc. same as above).
Are there any aesthetical or technical reasons not to prefer this?
Well, I have a designwise reason: It's confusing. USB is the module, but what you get there is some object inside the module. Using `() directly on the module makes it appear to be an object, but the object and the module are really two different things, and it's less confusing if they are kept separate, and that the separation remains clear.
Well, not quite. What I am doing now is something like this:
object dev=USB.Devices();
From this follows an USB.Iterator() object implicitly in foreach, then
an USB.Device() object which carries a reference to the original USB.Devices() it sprung from, and ultimately a USB.Transfer() object which carries a reference to the USB.Device() it originated from.
What I'm thinking is that I create the following hierarchy of objects:
USB() which simply is USB.Devices() moved up a notch. I.e. delete USB.Devices() and simply create just USB() which does everything the original USB.Devices() did. Then the USB.Iterator() and USB.Device() and USB.Transfer() are simply classes *inside* the USB() class, which eliminates the need to carry an explicit reference from those back to the old USB.Devices(), since they are children of the USB() class, they can reference it implicitly.
If there are no obvious objections, what would be the easiest way to implement this? Is this doable in the cmod?
It should be simple to do with an `(), even in a cmod afaik.
Erm, yes, this would be the shortcut method. Visually, it's the same effect as what I really wanted to do.
Are there any existing modules that did it this way?
There is an experiment in lib/modules/Threads.pmod which tries to unify the Thread module with the Thread.Thread objects. There you can see some effects of trying to do that, and I've also left a fairly lengthy critical comment on why it's not such a great idea.
I'm not implying that's what you're trying to do here, though - from the looks of it you may be aiming only at a simple shortcut. But even so my argument earlier remains applicable.
As to the matter of being confusing...
From a standpoint of someone looking at the language from the outside
(forgetting the implementation details for a moment), I see the following:
- Pike is an object oriented language. - There seems to be an implicit unnamed master class which contains a method called main() which is started by the operating system. - All variables, functions and classes one defines are actually variables, methods and classes which are part of this implicit unnamed master class. - Whenever a variable, function or class is not found to be part of this implicit master class, it is searched for in the libraries. - This means that USB() could be either: a. A function/method defined in the running program's implicit master class. b. A system function. c. A class defined in the/some library. - This means that USB.Devices() would simply be a class Devices() declared inside a parent class USB(). - The distinction between what is a module and what is a class should be irrelevant; someone looking at the language simply sees (nested) classes. The fact that a "module" actually is sort of an empty class which cannot be instantiated by itself seems irrelevant (one could even say confusing). They both seem to be classes, they live in the same namespace. Which (to me) would mean that the language can be explained without ever mentioning the word module, and without changing semantics.