On Jan 8, 2008 3:00 AM, Christopher Smith <[EMAIL PROTECTED]> wrote: > Chuck Esterbrook wrote: > > On Jan 7, 2008 1:32 AM, Christopher Smith <[EMAIL PROTECTED]> wrote: > > > >> I'm not talking about getting rid of types. I'm talking about languages > >> where the *variables* don't have types, which is a pretty common trait > >> of dynamically typed languages. > >> > >> With a dynamically typed language, you tend not to focus on the types of > >> your variables, but rather their roles (there is a difference), and of > >> course the role can and should be adequately described by the variable > >> name. Interestingly, knowing the roles involved in an algorithm is even > >> more telling than the data types. > >> > > > > While convenient when cranking out code, I've found typeless arguments > > to be time consuming when inheriting someone else's code. If the > > method is non-trivial, I have to study the implementation carefully to > > figure out what the expectations are for the argument known as, for > > example, "entity". Furthermore, if I then start to rework the Entity > > class, I get no compile-time help about how I just broke 12 methods in > > 4 files. Instead I have to run through all the test cases to find out. > > And to the extent that the project's automated tests lack code > > coverage, I end up producing some new bugs. > > > Type systems have lots of holes in them too, which is exactly why test > cases exist. Running test cases in a dynamic language is roughly > equivalent to compiling in a non-static language, only the validation > process is more powerful and flexible.
What is "running test cases" equivalent to in a static language since the compile time checks were already done? I think types, tests and contracts all have strengths and weaknesses. Same with static vs. dynamic binding. That's why Cobra supports all of them. Let the developer decide for a particular project which way to lean. > > So one feature I'm contemplating in Cobra is allowing contracts speak > > about typeless arguments like so: > > > > def addEntity(entity) > > require > > entity responds to (get name as String) > > entity responds to (def computeResults(factors)) > > body > > ... > > > > At which point the compiler is empowered to give you some errors when > > you violate the expectations of a method you're calling. > > > Sounds like Eiffel.... or unit tests. :-) Cobra already supports Eiffel style contracts. It's the addition of "responds to" and the compile-time checking that would go with it. I don't see that as related to unit tests as the point here is to catch the errors before you even run. > Another way to go with this is just to make meta programming as easy as > humanly possible and provide nice facilities for unit testing. It's not clear to me that such an approach is tractable in the short or medium term. Boo places emphasis on metaprogramming, but when I was investigating Boo earlier I noticed that macros were primarily used to either (a) implement simple statements or to (b) *not* successfully implement more complex features like contracts. Meanwhile people still complain about lack of generics on the boo discussion list. -Chuck -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
