Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The wiki article is really weak (does it represent an abstraction inversion itself? :), and the very concept is a bit dubious. But the fundamental gist of it seems to be that some basic element is hidden by the abstraction, forcing users of that abstraction to re-implement it.</p> <p>For instance, from the talk page, comes a much more interesting example. Suppose a CPU had a <code>tan</code> math function, but no <code>sin</code> or <code>cos</code>, and a programming language implemented <code>sin</code> and <code>cos</code> in terms of <code>tan</code>, but did not expose <code>tan</code> itself. A programmer using that language would be forced to implement <code>tan</code> in terms of <code>sin</code> and <code>cos</code>, which, themselves, are implemented in terms of <code>tan</code>, therefore characterizing abstraction inversion.</p> <p>So, back to Scala. Naturally, a programmer using functions in Scala is not incurring in abstraction inversion, because he is not being forced to re-implement a functionality available as a primitive to Scala.</p> <p>On the other hand, one might claim that Scala's implementation of functions as class instances is an instance of abstraction inversion. For that to be true, however, two things must also hold true:</p> <ol> <li>There must be a "function" primitive available to JVM.</li> <li>Such a primitive must have offered an alternative to what Scala is doing.</li> </ol> <p>What, exactly, is a function? What would a function primitive look like? In this context, "function" means data that is capable of being executed. One might say that all assembler code, is, in fact, data that is capable of being executed -- only it is not portable, and, futhermore, not bytecode, therefore failing the design principles.</p> <p>On the other hand, all methods in Java are referenced by an identifier, through which Java locates the code to be executed for a given object's class hierarchy. This identifier is not exposed, though it can be used indirectly through reflection. If it were exposed, and some functionality offered to say "call this code", then a function could arguably be constructed around that.</p> <p>So, I think a case could be made for 1 to be true. Let's proceed to the next.</p> <p>If Java <em>did</em> offer a "method" data type, would Scala functions cease to be instances of a class? No, they would not. One of the fundamental design aspects of Scala is that every element of a running program is an object. The "primitives" that Java already have are presented as if they were normal objects with methods, and if there was a "method" primitive, so would it.</p> <p>One possible consequence of method primitives would be to elevate methods to first class citizens, but functions, themselves, would hardly change.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload