--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
What's the point of this exercise exactly?
Doesn't node already have api docs?
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
class? really?
Yeah, still reserved, as it's a Java keyword or something, but then again, require is reserved as well.
I appreciate a good discussion about API as much as anyone but this is a very large change and represents a lot of time from everyone that gets involved in this discussion and there is absolutely no reason to think any of it will end up being used yet.
I asked Olly to post it to the list for some good ol' fashioned bike
shedding. As I told him, Node has a lot of API warts and I appreciate
the effort - and that thinking about how API should be is helpful -
but that the project is not in a position to consider large API
changes now without reason - so I won't spend the time to go through
the proposal and comment.
An example of using the http server: https://gist.github.com/21c4d53ec77e7862232c
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
Seems to be good for me. The syntax is clearly less confused. For
example I prefer "new http.server()" than "http.createServer(...)".
Isn't it simpler ?
New API or framework over the old one or patch, that's suits me !
2010/6/29 Marak Squires <marak....@gmail.com>:
Seems to be good for me. The syntax is clearly less confused. For
example I prefer "new http.server()" than "http.createServer(...)".
Isn't it simpler ?
--
--
new http.server() is thus not as good as new http.Server().
It's not about what's better, it's about what's already the standard.
No one ever said JavaScript was the prettiest language ever :)
How do you guys feel about multi-purposing the constructors to return
a new object even if called directly? It's pretty simple in the code.
function Server () {
if (!(this instanceof Server)) return new Server();
...
}
Then you can do stuff like:
require("http").Server().addListener("connect", cb).listen(8888)
--i
--i
You only uppercase the class, not the module. It's actually very
consistent, working today, and gels with the rest of the JavaScript
language.
Is it problematic to remember Array or Buffer or TypeError?
--i
You only uppercase the class, not the module. It's actually very
consistent, working today, and gels with the rest of the JavaScript
language.
Is it problematic to remember Array or Buffer or TypeError?
I can't believe this is even a discussion.
--
let's not have the comma first argument on this thread, there is plenty to argue about that is actually in the proposal.
//override doSomethingdoSomething: function($super, arg1, arg2) {
//call base class method$super(arg1, arg2);
}
-1 to class. It looks like you're proposing to add the "extends"
method to the Object prototype. Definitely -1 to that.
On Tue, Jun 29, 2010 at 12:46, Marco Rogers <marco....@gmail.com> wrote:
> PS - Has ry actually been declared BDFL?
Yes.
--i
I'll go further and say -1 to anything that adds methods to the base object prototypes.
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
But if you change Object, that has ripples throughout the system and it severely hampers your ability to reason about inherited/polymorphic behaviors.
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
It would be cool to follow any of the conventions set by firebug or
log4j. console.log, console.warn, console.info etc.
About naming and namespacing. The modules and their usage in node.js
look usually like this at the moment.
var events = require('events');
// we can do
new events.Emmitter();
// or
var Emmitter = events.Emmitter;
new Emmitter();
// or whatever!
This means, we currently have (and I like that) put our required
module in any variable we want to --- anyways.
This is awesome if you have a sub sub module like this:
var submodule = require("module/submodule");
This is what we have now and how we use modules. It works pretty much
like import at java:
import events.Emmiter;
// now Emmiter is available
This is convinient and helpful ;). Please keep it that way.
About capital letters for Constructor Functions. It helps reading, got
suggested by many and is de facto standard in _many_ libraries. Using
a lowercase letter brings in my opinion no real benifit. When you
actually have to read code, and see a "new whatever" statement, you
can be pretty sure, that it's wrong. a call like:
myobject.DestroyUniverse is pretty much wrong, too. On first sight. So
why remove this convention just in node?
node.object: what is this? I see many objects extending the node.object.
About the small node core. For me node is a framework to build
frameworks. It works great, evented and has a javascript interface. It
ships all the methods used to create a console or web app. And in my
opinion, it shouldn't deliver more. No bindings to databases or stuff,
this is a task for a plugins and may be put into a distro.
But I guess I wouldn't have started so easly with nodejs, when I had
to "git clone" a http plugin and stuff, before I could begin ;).
Regards,
Jan
Im in favour of keeping everything lowercase and using native js
prototypes instead of fancy class classes. Im not a fan of
sys.inherits either. If speed is node's primary goal (which it kinda
is) its important to A) Use as little objects as possible, and B) use
JS the way its designed to be.
It'd be better, in cases like this, to do an inventory of what's there
*already*, and then make the minimal changes necessary to increase
consistency and functionality.
Note that "minimum necessary" might be quite large. (Qv. the whole
"stream API" revolution that's been going on for the last few months.)
But changing a name just cuz it looks nice, that's not ideal.
(Also, Olly, you'll probably find that most people on this list pay a
lot of attention to everything that happens on it. NodeJS has a very
attentive and outspoken community ;)
--i
Yes, intentional. Private APIs are hard in JS - there is no way to
enforce it. My way has been this: not in api.markdown then not public
and maybe removed without notice.
On Tue, Jun 29, 2010 at 1:53 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:let's not have the comma first argument on this thread, there is plenty to argue about that is actually in the proposal.:)+1 (I was initially just commenting on something that had already been brought up with the casing and then had to barf on comma-first when I saw it mentioned, back on topic now...)So, here's some API related content: I actually like the inheritance model from Prototype quite a bit. I don't think we need Class.create() at all or anything like that (i.e. it's a bit convoluted to re-wire the constructor to match an "intitalize" function on the prototype, but I do think we can borrow from them for an Object.inherit() method (not messing with Object's prototype but as a mixin)...
So:namespace.Something = function() {...} //constructornamespace.Something2 = function() {...} //subclassObject.inherit(namespace.Something, namespace.Something2); //Something2 now inherits from Something//or...namespace.Something2 = Object.inherit(namespace.Something, {//override doSomethingdoSomething: function($super, arg1, arg2) {//call base class method$super(arg1, arg2);}});There's a tiny amount of well-tested and working static analysis at inherit-time to wire the magic $super keyword. I have such an implementation working in my own stuff (just adapted that model without bringing in any other Prototype stuff). Quite useful, IMHO.
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
+1 console
-1 class
+1 UpperCamelCase for class names
+1 lowerCamelCase for variables and methods
+1 minimal changes necessary to increase consistency and functionality
+1 for:
function Server () {
if (!(this instanceof Server)) return new Server();
...
}
+1 console
-1 class
+1 UpperCamelCase for class names
+1 lowerCamelCase for variables and methods
+1 minimal changes necessary to increase consistency and functionality
+1 for:
function Server () {
if (!(this instanceof Server)) return new Server();
...
}
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
I didn't read all this but I can say that the whole require with a literal string thing seems very ugly to me.
On Wed, Jun 30, 2010 at 11:31 AM, Tom <tomm...@gmail.com> wrote:I didn't read all this but I can say that the whole require with a literal string thing seems very ugly to me.
This thread sure is having some trouble staying on topic. We're not debating the constructs of the JavaScript language.
--
That's not a construct of the JavaScript language, but it is a
construct of the CommonJS module spec.
We're not going to move away from that, I hope.
--i
I don't understand why CommonJS started this way of constructing and I personally do hope node is moving away from it. :)Javascript has normal object construction, eg. new someClass() - why not use it? Seems much cleaner than require("someClass")
> 2010/6/30 Scott González <scott.g...@gmail.com>
>> This thread sure is having some trouble staying on topic. We're not
>> debating the constructs of the JavaScript language.
That's not a construct of the JavaScript language, but it is a
construct of the CommonJS module spec.
We're not going to move away from that, I hope.