7

In Java or Scala if I have an argument configuration: Conf, I can look for Conf class/trait/case class and see its construct so I know which arguments to pass.

Recently I started dealing with JavaScript, I see function like this:

function init(conf) {
  some body // as external developer to init I should not mess 
            // with the internals here I just use init, proper design.
 }

What I'm curious to know, how is it possible for me to know what to send exactly in conf? documentation? examples? sniff around init implementation? all look like bad alternatives for me, not well formed, depending on developer writing or not documentation providing or not examples. isn't there a more formal strict way for me to know what conf means?

I must say that on my day to day work with statically typed languages I don't need almost no documentation I just look at the types functions receive and I know what I need to pass in most cases.

  • 4
    Documentation, sample code, examining source of the function. Those are the options in Javascript. There is no strict method in Javascript to determine a function argument type because Javascript does not use types for declaring arguments. – jfriend00 Jan 25 '16 at 9:44
  • 1
    If you are open minded and are free to suggestion of using new technologies, you can also look at TypeScript. – Andy Jan 25 '16 at 9:47
  • 11
    Even in statically typed languages, knowing the names of the types often doesn't tell me how I'm supposed to get those types from or what states they're allowed to be in when I pass them to whatever function. Unless you work with far simpler APIs than I do, the need for good, comprehensive documentation is universal. – Ixrec Jan 25 '16 at 9:49
  • 4
    You don't. That's the problem. – Mason Wheeler Jan 25 '16 at 14:42
5

You don't. That's the problem. When types are not declared on a method's arguments, and there isn't a comment on the code saying what it's expecting to receive, there are only two ways to figure out what it expects you to pass. Either examine the function itself and see what it's doing with the input, or look at documentation. (Or sample code, which is really another form of documentation.)

Unfortunately, looking at the code, even if it's "a small, well written function," may not be as easy as David Arno suggests in his answer. Many small, simple functions consist of nothing more than passing on your arguments to one or more function calls, rearranging things to make them fit more conveniently. Then you end up with more and more code to dig through. Depending on what you're doing, you could have to go a dozen layers down before you reach the code that actually does something. (This is annoyingly common in database access code, for example.) And if any of the methods along the way call methods of unknown types, your job becomes even more confusing.

TLDR: In non-trivial code, if you don't have good, correct documentation, it's often very difficult to know what to pass to an untyped argument. This is one of the big reasons why you so rarely see large, complex projects written in dynamic languages.

6

This isn't a problem unique to JavaScript, or even just dynamic languages. For example, you might have the equivalent Java code:

void init(Configuration conf) {
    ...
}

and then discover that Configuration is an final class with no public constructors and you're left searching around for how to obtain an instance of that class.

Typically, looking at the code is your first course of action, assuming the source is available. The source is the only official, up-to-date, guaranteed-to-be-right documentation for what the function does. If it's a small, well written function, working out what conf needs to be should be an easy task.

If the library/framework in question has accompanying documentation, you may be able to use that to understand how to use the function.

Finally, specific to JavaScript, if you want static typing, use TypeScript, which is a free, open-source statically typed extension to JavaScript.

  • 3
    Meh. If something is a final class with no public constructors, you won't have much searching to do; the answer to how to instantiate it will obviously be on a static method within the class itself. The one you want will almost certainly have a return value of type Configuration. (And if not it will have a ref/out parameter of that type, or accept a list or other collection to put the new value in, but those are weird, uncommon cases; usually it'll be the return value.) Having declared types helps you easily narrow it down like that. – Mason Wheeler Jan 28 '16 at 13:32
  • 2
    @MasonWheeler. "the answer to how to instantiate it will obviously be on a static method within the class itself". This looks like a baseless assertion to me. An i nstance of Configuration might be accessible via a static method within that class. It certainly isn't a requirement of any language that it be so though, thus it certainly won't be obviously so. It might be a convention you follow, but it certaonly isn't universal. – David Arno Jan 29 '16 at 8:30
  • How else is it possible to instantiate it, given the restrictions you set in your example? (Assuming Java or C#, with the way you wrote the sample code.) If there are no public constructors, then nothing but a static member of the class or its descendants are in-scope to call the constructor, and if it's a final class, there are no descendants. – Mason Wheeler Jan 29 '16 at 10:07
-1

Dynamically typed or not, it's best to consult documentation and/or examples.

Even if you know what type a parameter is, it's often quicker and safer to base your code off of an example, with more detailed documentation on hand, than it is to assume you know what you're doing based on the parameter type.

Otherwise, you're just making assumptions and experimenting anyway. And if that's your preference -- well, good luck, first of all. But, if you really want to work off of assumptions (or perhaps are working with an undocumented, minified, black box library), you may as well start with the fewest assumptions possible: Give it a null and see what error(s) you get back.

-2

Trial amd error.

Actually, I doubt there's a resource without a proper documentation in it. If you really can't find what goes where, then you could type the function's name without parentheses in the chrome live console, and then, if the functiom is not a native function, then it prints out the source of the function.:

  • Do you mean "run time inspection" rather than "trial amd (sic) error"? – Jay Elston Feb 2 '16 at 19:22

protected by gnat Nov 16 '18 at 12:38

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.