Martin Stjernholm wrote:
"Stephen R. van den Berg" srb@cuci.nl wrote:
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.
What is ever "read formally" in Pike? ;) The general sentiment is that
:-).
ObjectsAndModulesAreSillyCapsed, function_names_use_c_style_underscores, and CONSTANTS_ARE_ALLCAPS. That is the most prevalent style in the existing modules. Although - this being Pike - there are of course
Well, the rest was already in my DNA (well, except the IMHO overuse of underscores, but that's what conventions are for, of course, to adhere to even if you don't quite like them).
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.
So then USB.pmod would become USB.pike, if you'd written it as a pike
The risk is then that static functions go into one object or another, where they become unnecessarily hard to reach. One example of that is
Ok, fair enough. Didn't think of this application. I'll stick with USB.Devices() then, and drop the USB() idea.
- 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).
On the contrary, the concept of modules, and what makes them different from classes, is helpful for users to understand. They are a) singletons in the pike process, and b) got a lifespan which is just as long as the process itself. This makes them the pike correspondence to the static storage class in many other languages. That has proven to be very useful as a programming paradigm, so it should be exposed. It's rather the fact that most modules really are classes that can be considered a technical detail that users shouldn't have to worry themselves with, at least not to begin with.
Useful reasoning. Somehow this should translate into improved explanation about what a module is and what a class is in the Pike documentation (or maybe I didn't read this part of the docs carefully enough, and it's just me that missed part of these points in the past).