static-typing

What is the appropriate type hint to specify that a variable should be a function (the equivalent of a delegate, Func<T> or Action in C#)? Is it also possible to specify the function argument types in a generic fashion as well (for example Func<int, int> )? I cannot find any relevant details in the documentation. According to the docs , you can use Callable, imported from typing. You can view more details in PEP 0484 . 来源： https://stackoverflow.com/questions/35315824/in-python-3-5-how-can-i-specify-a-function-as-a-type-hint

Ok, so can someone explain to me why F# allows you to overload the > and ^ operators, but doesn't allow you to use them? + (op_Addition): Works just fine. ^ (op_Concatenate): Compiler error in F#. Apparently only strings can be concatenated. > (op_GreaterThan): Runtime Error – Failure during generic comparison: the type Program+OppTest4 does not implement the System.IComparable interface. If I compile my F# code as a library and use those operators from VB, they all work. If I use those operators from C#, all but op_Concatenate work (as expected). But F# not only ignores some them, the static

In the Scala Collections framework, I think there are some behaviors that are counterintuitive when using map() . We can distinguish two kinds of transformations on (immutable) collections. Those whose implementation calls newBuilder to recreate the resulting collection, and those who go though an implicit CanBuildFrom to obtain the builder. The first category contains all transformations where the type of the contained elements does not change. They are, for example, filter , partition , drop , take , span , etc. These transformations are free to call newBuilder and to recreate the same

The Unit gets special handling by the compiler when generating byte code because it's analogous to void on the jvm. But conceptually as a type within the scala type system, it seems like it also gets special treatment in the language itself (examples below). So my question is about clarifying this and understanding what mechanisms are used and if there really is special treatment for the Unit type. Example 1: For "normal" scala types like Seq , if a method returns Seq , then you must return Seq (or a more specific type that extends Seq ) def foo1: Seq[Int] = List(1, 2, 3) def foo2: Seq[Int] =

It seems to me that the most invaluable thing about a static/strongly-typed programming language is that it helps refactoring: if/when you change any API, then the compiler will tell you what that change has broken. I can imagine writing code in a runtime/weakly-typed language ... but I can't imagine refactoring without the compiler's help, and I can't imagine writing tens of thousands of lines of code without refactoring. Is this true? I think you're conflating when types are checked with how they're checked. Runtime typing isn't necessarily weak. The main advantage of static types is exactly

Sometimes we have several classes that have some methods with the same signature, but that don't correspond to a declared Java interface. For example, both JTextField and JButton (among several others in javax.swing.* ) have a method public void addActionListener(ActionListener l) Now, suppose I wish to do something with objects that have that method; then, I'd like to have an interface (or perhaps to define it myself), e.g. public interface CanAddActionListener { public void addActionListener(ActionListener l); } so that I could write: public void myMethod(CanAddActionListener aaa,