CODEWITHSUNDEEP
node.js
Claude Tan
Claude Tan

Reputation: 399

How is the argument type defined?

We can use net.createServer([options][,connectionListener]) to create a server. Usually the callback function connectionListener has an argument client, which as I observe is a socket instance in the context(in the function body, the client invokes the method on(), so I judge that it is a socket instance).

var net = require('net')
var server = net.createServer(function(client){
   client.on('data',function(data){
      console.log('Client sent' + data.toString());
   }); 
   client.on('end',function(){
      console.log('Client disconnect');
   });
});

But unlike JAVA or C#, there is no type in front of the argument when define this callback function, how does the program know what the argument type is?

The same puzzle when use http.createServer() to create a server.

Upvotes: 0

Views: 229

Answers (2)

Tim Consolazio
Tim Consolazio

Reputation: 4888

I think this is the age old debate of the value of static types. I'm assuming that you already know that JavaScript "isn't a statically typed language." But I suspect what you might really be asking is, "why would anybody want to write this kind of code."

There are two mindsets that I see waging the war:

  • Any language without static types is incomplete. You can not write robust, stable code without them. If you don't know the incoming type, you are compromised.

(I call this thinking "one mailbox for each kind of letter". You do not need to inspect the letter, only one kind fits into this box. If you have a lot of different kinds of letters, you'll have lots of different kinds of mailboxes).

  • Static types are an academic overstatement. They compromise flexibility and become a kind of programming crutch. It doesn't matter what the type is, I just need to see if it has the data I want.

(I call this thinking, "one mailbox for most kinds of letters". The type of letter doesn't matter, you inspect it to see what you're getting, and decide whether to keep it or throw it away. You'll have very few mailboxes, maybe even only one, depending).

In my 25 years of coding, I've obtained a Java language certification, the Microsoft Developer certification, the Adobe ActionScript developer certification, and a few others I don't even remember. I've professionally taught JavaScript, C#, and ActionScript. So I'm well versed in languages that robustly implement type systems, and ones that don't.

My observations; rigid adherence to a type system can indeed lead developers to create ponderously over-engineered code. The focus is form over function. This makes it harder to engineer, more difficult to alter over time, but easier to reverse engineer.

But at the same time, total abandonment of types can indeed lead developers to create code that is precariously under-engineered. The focus is function over form. This makes it easier to engineer, easier to change over time, but harder to reverse engineer.

To go back to my mailbox thing, sometimes it makes a lot of sense to have one general use mailbox. Sometimes, it makes more sense to have a very specific kind of mailbox.

I believe that if one mindset was infinitely superior in all regards to the other, then that mindset would have won a long time ago. We'd all either be coding in Java, or JavaScript (more or less), because one would always build better software in all contexts than the other.

I think there's plenty of evidence that this isn't the case. Java (the typical champion of static typing) is adding features from loosely typed "functional" languages (and even evolving into things like Scala), and languages like JavaScript are incorporating features from statically typed "OOP" languages, like ES6 classes (and even evolving into supersets like TypeScript).

Looking at your original code: could these functions and event handlers benefit from static types?

Maybe. "Server" implies something that might be wise to rigidly type. You don't want any surprises. Here, one mailbox for one kind of letter. It would make it harder to switch out client implementations, but maybe that's a good thing (or not, depending). Maybe it makes sense to have multiple different kinds of createServer ( clientTypeA ), createServer ( clientTypeB ) API calls and such (e.g. Java overloading).

On the other hand, look at the event handler. Does "data" make sense to rigidly type, or is is more practical to just have it be "*", and have the code inspect it for what it needs? Here, the one mailbox for many kinds of letters makes more PRACTICAL sense.

Hope that gives some insight into this. I have this conversation ALL the time. I'm fortunate to have fairly even exposure to both sides of the programming fence, as it were, but many developers (particular Java comp sci grads) out-of-hand dismiss anything at all that smacks of functional programming (even to saying that things like anon functions are "incorrect"), or on the other side of the fence, out-of-hand dismiss anything that smacks of "rigidity" in any way.

IMHO, both are wrong, and both are right. As usual. You don't always need the rigidity of a contract to work with somebody else effectively or know what they're doing, in fact it can just get in the way. But depending on the context, it can be very smart to have one.

Upvotes: 1

rsp
rsp

Reputation: 111434

Types in JavaScript are resolved dynamically at run time, not statically at compile time as for some other languages.

So the answer to the question how does the program know what is the argument type is: the type is whatever was passed at run time.

But the answer to the question how does the programmer know what is the argument type is: the type is whatever is explained in the documentation.

The documentation of the API is a contract between the API developer and the API consumer.

Upvotes: 1

Related Questions