Loading ...
Sorry, an error occurred while loading the content.

Re: [jslint] Re: Type confusion: function generated by Math.xxx

Expand Messages
  • Erik Eckhardt
    Thanks for explaining a bit of what you re trying to accomplish. Do you think there is any place in the future for a javascript that has strong typing? If the
    Message 1 of 8 , Jun 21, 2011
    • 0 Attachment
      Thanks for explaining a bit of what you're trying to accomplish.

      Do you think there is any place in the future for a javascript that has
      strong typing?

      If the language supported properties with proper getters and setters, we
      could start enforcing types in code through the creation of new objects.

      On Tue, Jun 21, 2011 at 10:19 AM, Douglas Crockford
      <douglas@...>wrote:

      > **
      >
      >
      > --- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
      > >
      > > This is a good example. Consider:
      > >
      > > function explodeNumber(num) {
      > > ___return {
      > > ______ceil : Math.ceil(num),
      > > ______floor : Math.floor(num)
      > > ___};
      > > }
      > >
      > > var x = 12.2,
      > > ___v = somefunction(), // returns a number
      > > ___exploded = explodeNumber(x);
      > > if (x.ceil === Math.ceil(v)) {
      > > ___//do something;
      > > }
      > >
      > > Is this considered type confusion because `ceil` is a property of two
      > > objects, one a number and one a function?
      > >
      > > The name is not being reused... it means something *different* in a
      > > different object.
      >
      > I will agree that trivial, contrived examples are free of this sort of
      > confusion. My concern here is with large programs. The biggest criticism of
      > JavaScript by the Java community is that the language lacks the discipline
      > that is required to allow programs to grow large, reliably. Some claim that
      > programming in the large is impossible in JavaScript. I don't believe that,
      > but I do agree with the discipline part, which is why I am doing this
      > experiment.
      >
      > If you do not want to be a part of this experiment, then please opt out.
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Luke Page
      It would be great to separate the option in to two. Type confusion at the local level is difficult to argue against and I would like to turn it on without
      Message 2 of 8 , Jun 21, 2011
      • 0 Attachment
        It would be great to separate the option in to two.

        Type confusion at the local level is difficult to argue against and I would
        like to turn it on without always having the other option on and having to
        code around confusions between external apis (like jquery and the html dom).

        As for large javascript programs, I think closure tools along with its type
        safety through annotation and derivation is an excellent example of
        engineering made easier through increased type safety.
        On 21 Jun 2011 18:19, "Douglas Crockford" <douglas@...> wrote:
        > --- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
        >>
        >> This is a good example. Consider:
        >>
        >> function explodeNumber(num) {
        >> ___return {
        >> ______ceil : Math.ceil(num),
        >> ______floor : Math.floor(num)
        >> ___};
        >> }
        >>
        >> var x = 12.2,
        >> ___v = somefunction(), // returns a number
        >> ___exploded = explodeNumber(x);
        >> if (x.ceil === Math.ceil(v)) {
        >> ___//do something;
        >> }
        >>
        >> Is this considered type confusion because `ceil` is a property of two
        >> objects, one a number and one a function?
        >>
        >> The name is not being reused... it means something *different* in a
        >> different object.
        >
        >
        > I will agree that trivial, contrived examples are free of this sort of
        confusion. My concern here is with large programs. The biggest criticism of
        JavaScript by the Java community is that the language lacks the discipline
        that is required to allow programs to grow large, reliably. Some claim that
        programming in the large is impossible in JavaScript. I don't believe that,
        but I do agree with the discipline part, which is why I am doing this
        experiment.
        >
        > If you do not want to be a part of this experiment, then please opt out.
        >


        [Non-text portions of this message have been removed]
      • Joshua Bell
        ... +1 Type confusion at the local level is difficult to argue against and I would ... Agreed. Local var type confusion indicates likely bugs or tricky code
        Message 3 of 8 , Jun 22, 2011
        • 0 Attachment
          On Tue, Jun 21, 2011 at 3:56 PM, Luke Page <luke.a.page@...> wrote:

          > It would be great to separate the option in to two.
          >

          +1

          Type confusion at the local level is difficult to argue against and I would
          > like to turn it on without always having the other option on and having to
          > code around confusions between external apis (like jquery and the html
          > dom).
          >

          Agreed.

          Local var type confusion indicates likely bugs or "tricky code" that can and
          should be immediately reworked. IMHO, nearly all projects would benefit from
          this testing.

          Global property type confusion indicates a lack of consistency in naming
          within or across a larger code-base, which would likely require more
          extensive changes and/or coordination among multiple third-party libraries
          or even standards bodies. Some scoped projects will benefit from this
          inspection, but many will not be able to take immediate action. Losing the
          local var type checks for these projects would be unfortunate.

          In the future validating argument types in function calls would be nice,
          both for ECMAScript built-ins and optionally the browser DOM. One particular
          example would be String.prototype.split when called with a regex (known-bad
          in IE). (And once there is talk of function signatures, the tool could also
          check for usage of e.g. ES5 functions if compatibility with old browsers is
          desired and a polyfill isn't used.)


          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.