RE: [Rails-spinoffs] Extending Class.create() for casting objects

[Hill, Greg]

I’m wondering if there is some confusion here.  It didn’t seem to me he was advocating static typing in _javascript_, just automatic type-checking when you need it.  Maybe I misread it.  I’m all for dynamic typing.  I’m also all for easy, automatic type-constraining when needed (to turn silent failure into loud, obnoxious failure J).  I thought that was what he was proposing.   Greg   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Fuchs Sent: Monday, July 31, 2006 7:58 AM To: rails-spinoffs@lists.rubyonrails.org Subject: Re: [Rails-spinoffs] Extending Class.create() for casting objects   That's why you won't hear the words "components" and "configurable" too often in the Rails community.    It's often much faster to write your own customized stuff instead of trying to configure a prefab  component-- because of the speed you can develop with a dynamic language. :)   Embedding defensive techniques is good of course, and your unit tests should include throwing strange stuff at your code. Nevertheless, static typing isn't a catch-all and could even lead to a false sense of security.    The problem is that you easily get to the point that you try to "force" the language into something that it just isn't-- Microsoft tried something like that with their "Atlas" framework (Java-style OO), and IMHO miserably failed.    Anyway, this has already been discussed to death (maybe check the rails mailing list archives), and neither way of doing things is the holy grail, plus it depends heavily on personal experience and preference, how things  work in the team, maybe corporate policies, phase of the moon, etc. etc.   Best, -Thomas     Am 31.07.2006 um 15:42 schrieb Ryan Gahl: However, when creating consumable components or APIs, it's always good to embed defensive techniques into your code because you may not know which anonymous application space is trying to do what with your stuff, and yes you can tell those 3rd parties to unit test unit test, but in the end you can't control that. Design by contract is definitely a safe bet. On 7/31/06, Thomas Fuchs <[EMAIL PROTECTED]> wrote: Prototype is heavily based on ideas borrowed from Ruby (which has many similarities to _javascript_), and thus relies on the idea of DuckTyping. See http://wiki.rubygarden.org/Ruby/page/show/DuckTyping  for some info about this. To address the issue of stuff-that-could-go-wrong-more-easily (as compared to statc typing) Ruby programmers usually heavily rely on unit testing (a test to code ration of 1:1 or higher is normal). You'll find a clone of Ruby's unit test framework ( http://www.ruby- doc.org/stdlib/libdoc/test/unit/rdoc/) in the script.aculo.us distribution. Of course, neither approach is right or wrong. In my experience the time you safe by using a dynamic language compared to static typing easily allows for implementing lots of unit tests (which can do much more than just checking for types), plus your final code is less cluttered and more readable. Best, -Thomas Am 29.07.2006 um 19:06 schrieb Em Te: > I agree that the dynamic typing nature of _javascript_ is what makes > it useful and suitable for certain tasks. I also agree that not > everyone will benefit from type verification as most webpages are > simple and _javascript_ only serves as a complementary technology > (like autocomplete) where type verification may be an unnecessary > restriction. But with large-scale AJAX applications where code > complexity is inevitable and where many parts of the webpage are > generated and driven with _javascript_, it is precisely this dynamic > typing nature which makes debugging harder, and where type > verification would be beneficial. _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs   _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs   -- Thomas Fuchs wollzelle   http://www.wollzelle.com   questentier on AIM madrobby on irc.freenode.net   http://www.fluxiom.com :: online digital asset management http://script.aculo.us :: Web 2.0 _javascript_ http://mir.aculo.us :: Where no web developer has gone before

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs