begin quoting Chuck Esterbrook as of Tue, Jan 08, 2008 at 02:27:13AM -0800:
> 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
Yup.
I want typeless when I'm writing, and typed when I'm reading...
> 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.
>
> 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
> ...
I forget, do you allow for polymorphic methods, and would this
have an effect?
e.g.,
def addEntityName( entity )
require
entity responds to ( get name as String )
body
...
def addEntityName( entity )
require
entity responds to ( get id as Integer )
body
...
If not, what's the benefit over
if ( entity responds to ( get name as String )) error()
?
> At which point the compiler is empowered to give you some errors when
> you violate the expectations of a method you're calling.
It would be interesting to be able to generate the require block
by running a tool on the code. Inspect the body, and add the necessary
requirements to the require block, suitably marked as generated.
> You can do this to some extent with interfaces, but there are
> drawbacks. Sometimes the above is much more convenient than creating a
> new interface and then visiting a dozen classes in your project to
> make them conform. Also, interfaces in complex projects can get silly
> where they start to cover just one method like HasName,
> HasComputeResults, HasFoo, HasBar, etc. And since you cannot specify
> multiple interfaces for an argument, combination interfaces might then
> be created.
If you're using a "responds to" approach, can't you just have duplicate
interfaces?
e.g.,
interface foo
void bar ( get name as String )
interface qux
void bar ( get name as String )
And something that would accept a "foo" would also accept a "qux"?
--
How about checking the value's range?
Or would that make the syntax too strange?
Stewart Stremler
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
