5 ms·

Are you sure you know what dynamic dispatch is? Java has dynamic dispatch, and it is a statically typed language. In Java, it's often called "runtime polymorphi

Are you sure you know what dynamic dispatch is? Java has dynamic dispatch, and it is a statically typed language. In Java, it's often called "runtime polymorphism". https://www.geeksforgeeks.org/dynamic-method-dispatch-runtime-polymorphism-java/ https://www.geeksforgeeks.org/dynamic-method-dispatch-runtim... And using it doesn't give up any of Java's type safety guarantees. The arguments and return type of the method you call (which will be invoked with dynamic dispatch) are type checked.

ukj 5y ago
Are you sure you know when type-checking and when dynamic dispatching happens? Compile time is not runtime. The Java compiler is not the JVM. The compiler does type checking. The JVM does the dynamic dispatching. Neither does both.
- justinpombrio 5y ago
  All those statements are correct. The people downvoting you know that too. I don't think anyone has figured out what point you're trying to make, though. Could you spell it out in more detail? Consider addition. The compiler does type checking, and the JVM actually adds the numbers. Nonetheless, the addition is type checked, and does not represent a weakness of static type checking. How is dynamic dispatch different than this?
  - ukj 5y ago
    The point is trivial. You can’t have both static type safety AND dynamic dispatch at the same time and in the same context about the same data. Choose one. Give up the other. Make a conscious trade off. The language that you are using is making such trade offs for you - they are implicit in the language design. Best you know what they are because they are meaningful in principle and in practice.
    - justinpombrio 5y ago
      Java has both static type safety AND dynamic dispatch at the same time and in the same context about the same data.
      - ukj 5y ago
        No, it doesn’t. The input-data to the compiler can’t be handled by the JVM and vice versa. The JVM handles byte code as input. The compiler handles source code as input. That is two different functions with two different data domains. They literally have different types! Which one of the two functions is the thing you call “Java”?
        justinpombrio 5y ago
        A type system is sound when: for all expressions e: if e type checks with type t, then one of the following holds: - e evaluates to a value v of type t; or - e does not halt; or - e hits an "unavoidable error" like division by 0 or null deref (what counts as "unavoidable" varies from lang to lang) Notice anything interesting about this definition? It uses the word "evaluate"! Type soundness is not just a statement about the type checker. It relates type checking to run time (and thus to compilation too). That is, if you muck with Java's runtime or compiler, you can break type soundness, even if you don't change its type system in the slightest.
        ukj 5y ago
        Yes this is precisely what I am talking about. Different implementations of eval() a.k.a different programming languages have different semantics. Which implicit eval() implementation does the above hold? What type system do you have in mind such that the above holds for ALL expressions. Type-checking itself is not always decidable.
        BoiledCabbage 5y ago
        It's pretty clear at this point you don't understand what dynamic dispatch means. I don't think it's worthwhile for anyone else to argue with you further. C++ and Java both support dynamic dispatch although you deny it. You've taken up almost a full page of HN arguing with everyone trying to explain it to you. People have pointed you to wikipedia showing you that you're wrong. [1] ISOCPP of which Bjarne is a director [2] says that C++ supports dynamic dispatch. [3] And you continue to attempt to argue that everyone on HN, Wikipedia and the creator of the C++ language are all wrong and don't know what dynamic dispatch is. Your continued insistence is both wrong and a negative impact at this point on hn. Please stop arguing something that numerous people have taken lots of patience and charity in trying every way possible to explain to you and what is clearly factually wrong. If you're going to reply, please explain why an organization that Bjarne Stroustrup is a director of believes that C++ supports dynamic dispatch. 1. https://en.wikipedia.org/wiki/Dynamic_dispatch#C++_implementation https://en.wikipedia.org/wiki/Dynamic_dispatch#C++_implement... 2 https://isocpp.org/about https://isocpp.org/about 3. https://isocpp.org/wiki/faq/big-picture#why-use-oo https://isocpp.org/wiki/faq/big-picture#why-use-oo
ukj 5y ago
In English there seems to be the eternal confusion between what things are and what we call them. When a router does lookups from a static table it's "static routing". When Java does lookups from a static table it's "dynamic dispatch". The same type of computation is being characterised as both "static" and "dynamic". When a router does lookups from a dynamic table it's "dynamic routing" - there is no equivalent in Java because making the dispatch table reflexive/mutable is precisely what violates type-safety!
- wabain 5y ago
  I don't think this analogy quite holds together. A router doing lookups from a table is implementing a static routing strategy from a control plane perspective; it's using statically configured values instead of using dynamic information about the network topology gleaned using a routing protocol like BGP. But an implementation of that strategy in terms of table lookups is dynamic—it's walking a data structure to retrieve values which were specified in the runtime configuration, not at compile time. The reason that "dynamic dispatch" in Java, etc. is called that is that the instance of the dispatch table to use is chosen dynamically, rather than being fixed at the callsite. It's true that Java doesn't let the shape of the dispatch table change at runtime, but that's not what dynamic vs static refers to conventionally in this context. The ability to dynamically add and remove methods from a class is something which you typically only get in dynamically typed languages but dynamic dispatch and dynamic typing are not the same thing. In particular, while a full-featured routing information base implementation will usually use some form of dynamic dispatch to customize the behavior of routes originated through different protocols, it's very uncommon for an implementation to rely on dynamic typing which adds or mutates the methods associated with different entities. That's simply a different kind of tool used for different purposes. It's something which can be helpful in object-relational mapping, for instance, because you can create methods based on a dynamic database schema. The RIB is not going to have a schema like that which changes at runtime.
  - ukj 5y ago
    >But an implementation of that strategy in terms of table lookups is dynamic—it's walking a data structure to retrieve values which were specified in the runtime configuration, not at compile time. That's precisely the point. You can specify part of the routing table at compile/configure time - the rest gets generated at runtime. The data/control plane distinction is conceptual. It doesn't hold in memory when the router is handling its own network traffic - it has a single routing table/world-view. My own routing table is shared by the data plane AND control plane. At some point you will receive an external data (routing update) which requires runtime validation, you will do reflection and update your own routing table (ring 0 address space) based on external events. >The RIB is not going to have a schema like that which changes at runtime. The schema need not change. The entries/relations between objects changing is sufficient to violate type-safety. Route add( *str1, *str2) to Number.add().

ukj 5y ago

Are you sure you know when type-checking and when dynamic dispatching happens? Compile time is not runtime. The Java compiler is not the JVM. The compiler does type checking. The JVM does the dynamic dispatching. Neither does both.

justinpombrio 5y ago
All those statements are correct. The people downvoting you know that too. I don't think anyone has figured out what point you're trying to make, though. Could you spell it out in more detail? Consider addition. The compiler does type checking, and the JVM actually adds the numbers. Nonetheless, the addition is type checked, and does not represent a weakness of static type checking. How is dynamic dispatch different than this?
- ukj 5y ago
  The point is trivial. You can’t have both static type safety AND dynamic dispatch at the same time and in the same context about the same data. Choose one. Give up the other. Make a conscious trade off. The language that you are using is making such trade offs for you - they are implicit in the language design. Best you know what they are because they are meaningful in principle and in practice.
  - justinpombrio 5y ago
    Java has both static type safety AND dynamic dispatch at the same time and in the same context about the same data.
    - ukj 5y ago
      No, it doesn’t. The input-data to the compiler can’t be handled by the JVM and vice versa. The JVM handles byte code as input. The compiler handles source code as input. That is two different functions with two different data domains. They literally have different types! Which one of the two functions is the thing you call “Java”?
      - justinpombrio 5y ago
        A type system is sound when: for all expressions e: if e type checks with type t, then one of the following holds: - e evaluates to a value v of type t; or - e does not halt; or - e hits an "unavoidable error" like division by 0 or null deref (what counts as "unavoidable" varies from lang to lang) Notice anything interesting about this definition? It uses the word "evaluate"! Type soundness is not just a statement about the type checker. It relates type checking to run time (and thus to compilation too). That is, if you muck with Java's runtime or compiler, you can break type soundness, even if you don't change its type system in the slightest.
        ukj 5y ago
        Yes this is precisely what I am talking about. Different implementations of eval() a.k.a different programming languages have different semantics. Which implicit eval() implementation does the above hold? What type system do you have in mind such that the above holds for ALL expressions. Type-checking itself is not always decidable.
      - BoiledCabbage 5y ago
        It's pretty clear at this point you don't understand what dynamic dispatch means. I don't think it's worthwhile for anyone else to argue with you further. C++ and Java both support dynamic dispatch although you deny it. You've taken up almost a full page of HN arguing with everyone trying to explain it to you. People have pointed you to wikipedia showing you that you're wrong. [1] ISOCPP of which Bjarne is a director [2] says that C++ supports dynamic dispatch. [3] And you continue to attempt to argue that everyone on HN, Wikipedia and the creator of the C++ language are all wrong and don't know what dynamic dispatch is. Your continued insistence is both wrong and a negative impact at this point on hn. Please stop arguing something that numerous people have taken lots of patience and charity in trying every way possible to explain to you and what is clearly factually wrong. If you're going to reply, please explain why an organization that Bjarne Stroustrup is a director of believes that C++ supports dynamic dispatch. 1. https://en.wikipedia.org/wiki/Dynamic_dispatch#C++_implementation https://en.wikipedia.org/wiki/Dynamic_dispatch#C++_implement... 2 https://isocpp.org/about https://isocpp.org/about 3. https://isocpp.org/wiki/faq/big-picture#why-use-oo https://isocpp.org/wiki/faq/big-picture#why-use-oo

ukj 5y ago

In English there seems to be the eternal confusion between what things are and what we call them. When a router does lookups from a static table it's "static routing". When Java does lookups from a static table it's "dynamic dispatch". The same type of computation is being characterised as both "static" and "dynamic". When a router does lookups from a dynamic table it's "dynamic routing" - there is no equivalent in Java because making the dispatch table reflexive/mutable is precisely what violates type-safety!

wabain 5y ago
I don't think this analogy quite holds together. A router doing lookups from a table is implementing a static routing strategy from a control plane perspective; it's using statically configured values instead of using dynamic information about the network topology gleaned using a routing protocol like BGP. But an implementation of that strategy in terms of table lookups is dynamic—it's walking a data structure to retrieve values which were specified in the runtime configuration, not at compile time. The reason that "dynamic dispatch" in Java, etc. is called that is that the instance of the dispatch table to use is chosen dynamically, rather than being fixed at the callsite. It's true that Java doesn't let the shape of the dispatch table change at runtime, but that's not what dynamic vs static refers to conventionally in this context. The ability to dynamically add and remove methods from a class is something which you typically only get in dynamically typed languages but dynamic dispatch and dynamic typing are not the same thing. In particular, while a full-featured routing information base implementation will usually use some form of dynamic dispatch to customize the behavior of routes originated through different protocols, it's very uncommon for an implementation to rely on dynamic typing which adds or mutates the methods associated with different entities. That's simply a different kind of tool used for different purposes. It's something which can be helpful in object-relational mapping, for instance, because you can create methods based on a dynamic database schema. The RIB is not going to have a schema like that which changes at runtime.
- ukj 5y ago
  >But an implementation of that strategy in terms of table lookups is dynamic—it's walking a data structure to retrieve values which were specified in the runtime configuration, not at compile time. That's precisely the point. You can specify part of the routing table at compile/configure time - the rest gets generated at runtime. The data/control plane distinction is conceptual. It doesn't hold in memory when the router is handling its own network traffic - it has a single routing table/world-view. My own routing table is shared by the data plane AND control plane. At some point you will receive an external data (routing update) which requires runtime validation, you will do reflection and update your own routing table (ring 0 address space) based on external events. >The RIB is not going to have a schema like that which changes at runtime. The schema need not change. The entries/relations between objects changing is sufficient to violate type-safety. Route add( *str1, *str2) to Number.add().