Interesting.  I found and use jslint.com instead of
javascriptlint.com  I also read the book, Javascript: The Good Parts.
It's pretty awesome, and a thin book.

Nothing on there I could find about typing functions, what made a big
impact with me was the use of === instead of ==, and why that is
important.

http://javascript.crockford.com/code.html

We're in the process now of updating all of our javascript to pass
jslint at work, and are going to be adding it to the build process as
well.  Many of the developers are java developers, and only dabble in
javascript.  jslint is an amazing tool to help enforce coding
standards between people who work in the UI but are not UI experts :)

On Jan 29, 1:30 pm, Diego Perini <diego.per...@gmail.com> wrote:
> Richard,
>
> On 29 Gen, 17:29, Richard Quadling <rquadl...@googlemail.com> wrote:
>
>
>
> > 2009/1/29 Diego Perini <diego.per...@gmail.com>:
>
> > > Richard,
>
> > > On 29 Gen, 13:43, Richard Quadling <rquadl...@googlemail.com> wrote:
> > >> 2009/1/28 Diego Perini <diego.per...@gmail.com>:
>
> > >> > The other good thing you are doing with JSLint is enforce the type of
> > >> > each function, I mean the return type. I have been told several time
> > >> > that not being a strict typed language it doesn't matter blah..blah
> > >> > blah.
>
> > >> Why would you cripple the language by enforcing return types?
>
> > > Hey it is Douglas Crockford JSLint saying that, not me, I am just
> > > happily supporting the idea...
>
> > > Are you saying that C and Java are crippled languages because they
> > > enforce return types ?
>
> > Absolutely not. But the nature of Javascript IS to have an
> > non-strictly typed language. I use PHP as my day to day and that is
> > non strictly typed.
>
> > I suppose it is partially strictly typed in so much as you have
> > scalars (strings, boolean, numbers), arrays and objects.
>
> > > Just wanted to point out that doing what Crockford suggests will help
> > > write more robust javascript, though that doesn't mean you may be able
> > > to achieve the same goal using functions returning mixed types. Not
> > > everybody is able to write and work well in a polymorphic environment.
>
> > Ah, part of the dumb it down brigade. I'm reminded of UK news story
> > recently which said that due to the poor quality of education, kids
> > sitting their end of year English exams were unable to write an essay.
>
> Not part of any brigade, and I really feel for UK if it is like you
> said.
>
>
>
> > So rather than spending anything on increasing the ability of kids to
> > write, they dumb down the exam to a multiple choice test instead. Bums
> > on seats, stack 'em high sell it cheap. etc. etc. (Gee I sound like an
> > old man. Guess what though, I am!).
>
> > >> Many times it is useful to return a boolean False if something doesn't
> > >> work and the appropriate type when it does.
>
> > > You can do the same with any type without mixing:
>
> > > - object, return null instead of an existing object (null is still an
> > > object)
> > > - string, return empty string instead of not empty string
> > > - number, return negative number instead of a positive
> > > - boolean, return boolean false instead of boolean true
>
> > That's OK as far as it goes, but how do you differentiate between "no
> > value" and an error? Something returning null means that there is no
>
> For the "no value" case I think only event handlers and void functions
> apply, in that case the function will "return undefined" or just
> "return" in javascript. I don't see any use of a function returning
> nothing when it was meant to returns something, you can surely embed
> that in your program logic but I don't see a clear path in doing so.
>
> For the "error" how can you return an error from a function ?
>
> You mean "throw" an error...or you trap an error, yes Javascript
> provide various method to handle errors, not as solid as other
> languages but workable and you have try/catch blocks and "onerror"
> events.
>
> > data. It implies that the call was OK, just that there isn't anything
> > suitable to respond with. An error on the other hand is something
> > quite different.
>
> These cases will have to be tested before with feature testing, there
> is no need to invoke a non existing functionality to realize it will
> error in one of the program functions.
>
> > Mixed return types are REALLY useful.
>
> Probably useful as a shortcut for the lazy writer, not for the reader
> nor for the users of that specific code.
>
> If you don't test functionality beforehand it means your code rely on
> "promised" functionality, if an error happen everything is going to
> break...no degradation...no alternative, or if there are everything is
> built and handled inside each function through conditionals.
>
> Diego
>
>
>
> > > I agree about that methodology you enforce is a shortcut most of the
> > > time, but I would try to avoid that if possible.
>
> > >> So mainly return types are mixed.
>
> > > Yep...in Prototype, functions return types are mixed (but only in some
> > > special circumstance), I don't have them enumerated and I don't know
> > > which one does that and I don't see any documentation explaining which
> > > one does .... :-)
>
> > > Diego Perini
>
> > >> --
> > >> -----
> > >> Richard Quadling
> > >> Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498&r=213474731
> > >> "Standing on the shoulders of some very clever giants!"
>
> > --
> > -----
> > Richard Quadling
> > Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498&r=213474731
> > "Standing on the shoulders of some very clever giants!"
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to