PJE writes in a comment...
There *are* other uses for type declarations besides type checking. For example, the Naked Objects framework in Java uses method signatures to figure out what actions might apply when one object is dragged-and-dropped onto another object in a GUI.Jayson Vantuyl responds in another comment...
In response to the above comment, I would point out that there are other (better) ways to do what the Naked Objects Framework (NOF) is doing in Python.I wrote and demonstrated a Naked Objects framework in Jython at the 2003 XML DevCon. One reviewer...
14:46 - Patrick Logan - "Point & Click XML Applications" - an interesting discussion and demonstration (using Jython) of point and click application development... to me one of the most interesting points was that at the end of his presentation he pointed out that most of these concepts are extensions of things started 15+ years ago such as Lotus Notes, Agenda, Naked Objects, Tuple Spaces, etc.I didn't allocate as much time as I'd hoped, and I wasn't so happy with the result. Nevertheless, the system did not require type annotations in the Python. Rather the end user is able to define their own data types in the GUI itself (including "Any").
If I were to continue with that work, I'd consider making these "end user annoations" optional and provide inference as well as modifying the inferred type dynamically as users create more objects. (With some kind of confirmation of the user's intentions.) But I would not think language extensions to Python would be worthwhile.
Back to PJE...
Documentation, of course, is an even more immediately useful use case. A good syntax would be more precise and more brief than docstring explanations.I think there are more useful kinds of documentation to write other than type annotations. I'd like the system to infer types and tell me what it determines the current types might be for some method. Moreover, I'd like the inferencing mechanism to consider the test code and data as well as the application code.
Given those inferences I could correct my code, add new tests or test data, or have the system keep the inferences around as automatically generated documentation if so desired.
The documentation I write myself would be more useful in the form of technical memos (see the complete Episodes pattern language).
Is there a danger of over-declaration by newbies? Sure. I'd probably find it really annoying to use code with excessive declarations, if those declarations actually restricted anything. However, if they were *just annotations* (or were adaptation specifiers per PEP 246), then I could still pass their code any darn thing I pleased, and we could all continue to be happy.Yikes! What would be worse, type annotations that *are* enforced or type annotations that are *not* enforced?
2 comments:
Um, just because a given use case can be accomplished without a given tool, doesn't mean the tool is useless, or isn't useful for that use case. If that were true, we'd never use anything but machine code.
Meanwhile, I notice you haven't responded to the point that solid integration with statically typed languages often requires type annotation; e.g. jythonc's use of special patterns in docstrings.
Integration with other languages, documentation, and runtime introspection/adaptation are my use cases for type annotation. I don't see how type inference helps with either documentation or introspection, either. If it's pure "duck typing", how is the system going to infer that I want an IAtomicStream, say, versus an IRawStream, if the two have the same methods? Duck typing isn't sufficient to distinguish different *semantics* of a type/interface, only its method signature -- and that is not sufficient for documentation!
Documentation needs to present the semantics of the interface, so that if you are implementing that interface yourself, you know what semantics to implement.
Likewise, for introspection, I don't see how an implicit signature helps. Let's say I want to create an XML schema for a document format that can contain messages that get converted to method calls on some object. If each of those methods uses a different set of methods on their arguments, I'm going to end up defining new types for each method, which might be okay for the computer to process, but for a human being it's going to be a mess to understand.
Type inference, IMO, is just type checking. It doesn't seem to me to be useful for anything else -- and like you, I'm not interested in type checking! (I suppose it could be used for optimization in some cases, but only if you can statically prove a concrete type - not just an operation signature.)
Now, perhaps I could be wrong, and there is some other way to accomplish these use cases that's just as clean. If so, I'd sure like to see them. I personally don't see that any of my uses for type annotation *can* be satisfied by inference; there's just not enough information. Heck, I don't see how a *human* could do the inference in the absence of added documentation, let alone a computer. It would be little more than blind guessing.
Would you publish something from the "Point & Click XML Applications" discussion and demonstration?
Post a Comment