New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What is the deal with the Sensor "constructor"? #1
Comments
Yes and yes.
Can you offer a rationale? Why lowercase |
In my vision there is a separation between a namespace object (
These are bad and I am trying to kill them ^_^. Classes for which instances exist should be constructible. (
I am all for avoiding the global name pollution, but I think that re-using the abstract base class as the namespace is strange. Normally static properties of a class are not other classes, but instead utility methods or constants or something. |
Yes, that part was clear, but why?
Haha, I think it's correct—it reads correctly to me ;)
No trolling, but why? I want to tease out the reason for the objection. Is just that it's not something you often (or ever) do?
Here are some pseudo-examples based on actual APIs in Johnny-Five: // These...
var d = new Sensor.Digital(9);
var a = new Sensor.Analog(0);
// produce an instance as it would be created by otherwise doing this:
var d = new Sensor({ pin: 9, type: "digital" });
var a = new Sensor({ pin: "A0", type: "analog" }); Or... var proximity = new IR.Proximity("i2c-ir-proximity-device");
var reflection = new IR.Reflection("i2c-ir-reflection-device");
// Same as:
var proximity = new IR({
model: "i2c-ir-proximity-device"
});
var reflection = new IR({
model: "i2c-ir-reflection-device"
});
// IR just loads in a device profile to create the instance Or... var nunchuk = new Wii.Nunchuk();
var classic = new Wii.Classic();
// Same as...
var nunchuk = new Wii({
model: "RVL-004"
});
var classic = new Wii({
model: "RVL-005"
});
// Same implementation pattern as IR: Wii loads in an appropriate device profile Note that these examples, the static property definitions aren't subclasses, and the classes that they are attached to are directly instantiable. Arguably, the |
|
I guess that is it. I have a conceptual model wherein namespace objects and classes/constructors are very different types of things, and I never would have mixed them together. Perhaps one way of thinking about it is that namespace objects are poor-man's modules. If we had modules in the browser, it would be e.g. Another thing that I just thought of: when I see I don't think your examples, where EDIT: upon re-reading I see all your examples are the same type; IR is not special. But in all of them, it seems that either: "same as..." doesn't literally mean the same result, or in one or the other case |
This is a strange point to bring into the discussion, since the browser's platform objects and APIs have never been designed this way. If this were a module, I wouldn't even bother with
Interesting. I kept with capitalized properties to make it clear that they were also constructors instances |
It looks like it is serving a few purposes:
I think these would be best separated? E.g. a namespace object, window.sensors, in which lives SensorBase + Temperature + Proximity?
The text was updated successfully, but these errors were encountered: