Fuzzy Distinction Between Interface And Implementation

The distinction between interface and implementation is not as clear cut as some people imply. For example, is HTML an interface or an implementation? It is not low-level because it does not tell each and every pixel of every letter where to go. HTML is an abstraction. However, it is not the only way to represent presentation of content. But that alone does not turn it into an implementation. If we make an API to "hide" HTML, then we have created our own little protocol, which may be no better or worse than HTML. At best our special API is application- or task-specific. But I am not sure that makes it more "high-level", just more specific to our local needs. Similarly, some consider a database to be an interface, while others consider it an implementation to be wrapped or "abstracted away". There is no clear cut way to tell which is which, and the answer probably depends on one's personal preferences, organizational viewpoint (such as rank or position), or philosophical viewpoint.

The distinction is far more clear cut than you imply. HTML is a message format, and is neither interface nor implementation. A unit that produces HTML as an output doesn't know whether that HTML is going to be used for display vs. saved to file vs. whatever. And so that limit of the unit's control is a very "clear cut" interface. Similarly, units don't control the inputs they will receive, and so the limits of that control - the input interface - is often similarly 'clear cut'. Implementation is all about control to produce outputs from inputs. The level of abstraction of the input or output language (low-level vs. high-level) is irrelevant.

Please clarify this. Nothing else necessarily "knowns" whats going to happen to its output, so that is not a distinguishing feature. Please clarify the "control" and "knows" statement.

A module that receives inputs gets to make some decisions on how to handle them. That ability to make decisions is 'control'. A module also 'knows' what it is happening to them, in the sense that it can be predicted, just by looking at the module and the inputs and the service contracts of any other modules it calls during processing, what the consequences will be. Don't put too much an anthropomorphic spin on "knows"; it is meant in the most limited of senses. By example: a typical pure function has a very clean set of interfaces (the inputs and the return value) and has 'control' over what happens between the two. As such, each 'function' is modular, and any other function implementation could be moved into its place so long as it meets the same interface in addition to whatever implicit pre and post requirements the function fulfilled (since most languages don't make those requirements explicit).

Modern programming design, ever since the 'subroutine' was invented, is largely about making things more and more modular.

The topic is not about "modules". I don't understand why are you talking about modules.

Incorrect. Modules are ultimately about providing black-box implementations to accomplish required tasks through shared interfaces, and so modules are very much on topic in a discussion of interface and implementation.

And, "knowing by looking at" sounds like criteria tied to the nature of the observer, not what is being observed in order to determine whether its an interface or an implementation. If this is going to slip into another "intent" definition battle, I'm bailing out here.

This was covered above when I stated that "knows" is "meant in the most limited of senses". As in the information theoretic sense of what can deductively be known given access to the source code and a full syntax and semantics description for the language it is written in. If you're going to continue ignoring such clarifications when they're offered, you are welcome to "bail out".

Is this not the kind of issues we got caught up with in topics such as WhatIsIntent and DefinitionsThatRelyOnIntent? --top

Yes. It is not.

[insults deleted]

Hint for the future: if you're going to delete insults, be very careful to be neutral about it and clean up the cause for the insults as well as the insults themselves. It is dangerous territory to tread. I am feeling quite insulted at the moment.

Note that I did *not* do the deletion. (Somewhere there is a dumping ground topic intended for removed insults in case one wants to review and check.) --top

I know you didn't do it. I know your IP addresses. And you aren't the type to delete anyway... that's not your thing.

Okay. In the future to reduce ambiguity, I'd suggest wording such as: "To whomever deleted the insults, be very careful to..."

It's the same fuzzy distinction between our mental models of the universe, and the way it actually operates. The difference is that each human creates their own interface.

It is not just a per-human issue, but a per-use issue also. Whether a piece of code uses HTML or its own little API that wraps HTML may depend on specific requirements for that piece. For example, one might find an IMG tag kind of bloated, so they wrap it with a single function such as "img(imgUrl, caption)". But if one needs more features of the IMG tag, then it may just be easier to use an IMG tag directly, otherwise we just end up reinventing HTML.

"Fuzzy distinction" is an oxymoron, of course. Interfaces and implementations are not concepts that require to be distinguished, as it happens, since they occupy entirely separate conceptual spaces, like shapes and colours. The distinction between "square" and "purple" is also not as clear cut as some people imply.

Yes, much like the distinction between "orange" and "orange"

The distinction between interface and implementation is clear cut. Interfaces describe what things can be done. Implementations describe how to do them. HTML is neither an interface not an implementation. It's a markup language.

I disagree. DataAndCodeAreTheSameThing or interchangeable for the most part. For example each HTML tag could be converted into a function call:

  // As HTML
  <img src="fido.gif" border=0 alt="my dog">

  // As a function call
  img("fido.gif", border=0, alt="my dog")
  // or more generic:
  html("img", src="fido.gif", border=0, alt="my dog")

Languages like LISP blur the distinction even more, as one can easily save up a stack of such "functions" for later execution/evaluation. There is no clear-cut way to say if that is a "what" or "how" or both.

I still don't understand. All of the above examples are implementation. They describe how something is being done, not what can be done. -- EH

An "img" function is a "what". Note that we can call it "image" if we want. Would that change anything? It only describes what we want, not how to get it.

No, the "img" function's signature is a what. The code above shows a call to img(), describing the how of whatever contains that code. -- EH

There seems to be a miscommunication here. The function is a protocol, and so is the HTML. HTML might be a specific language (protocol), but so is the function.

A protocol? What do you mean? I can agree that the function's signature is part of a protocol. The line of code that calls that function is not a protocol by any definition of that word I can find. -- EH

Well, HTML tags have "signatures" also. If one made a programmer Help-page for the IMG function, it would not look that much different than one for the IMG tag.

Of course the interface/implementation razor goes dull when a GUI is used. Is JavaScript embedded in HTML an implementation, but used as an interface, or is the resulting HTML the interface?

[It sounds like you think 'interface' means 'user interface', but when people are talking about the difference between 'interface and implementation', they aren't talking about 'user interfaces', they are talking about programming APIs. HTML and JavaScript have nothing to do with the issues.]

The parts that describe what can be done are interface. The parts that describe how to do those things are implementation. Razor sharpened.

I didn't mean to imply an API interface and a user interface were indistinguishable. My point was that you'd have two interfaces - one to the javascript, and one to the HTML. But by embedding javascript into HTML, the interface to the HTML object would contain and use the implementation of the javascript code. The HTML implementation can be hidden behind an interface, but at some point you'd still need to know about, reference, and possibly analyze the javascript code. At that point the distinction between HTML interface object and the javascript implementation become fuzzy. That can be qualified by saying the javascript implementation is part of the HTML interface, but I still say that makes the razor less sharp.

I'm sorry, but I can't make heads or tails of what you are trying to say. You use the word interface in a way I've never encountered. Could you clarify, maybe with a sample of what you're trying to say?

You keep using that word. I do not think it means what you say it means.

pseudocodeish example of old school attempt at html handling

/* let's say you had to load foo.html that might include javascript code */
        /* if so, scan the script for "popup", and see if it executes instruction "popup" */

InternetExploiter::load(char *fn)
{
html->load(fn);
if (html->hasJavascript())
{
javascript = html->getJavascript();
char *szCode = javascript->getRawText();
if (strstr(szCode,"popup"))
EVIL(FOUND_POPUP);

javascript.flagExecution("popup");
javascript.exec();
if (javascript.flagged("popup");
EVIL(FOUND_EXEC_POPUP);
}
}

ok, so the question is, where does the razor cut here? Let me put this in theoretical context/real world constraints - I'm writing a hax0r browser, using a 3rd party object - html, that I can't change the interface or implementation of, but I can get the javascript. I'm trying to extend the functionality of the browser by scanning for popups. I realize this is a lame example, but it's not far from the ridiculousness of the real world. -- LayneThomas

It all looks like implementation to me, but I still have no idea what this example has to do with the distinction between interface and implementation. -- EricHodges

My point was that the abstraction of interface and implementation breaks down sometimes. Perhaps the ambiguousness of this thread shows the difficulty in using the razor. -- ?

[Just looks like implementation to me too, I don't think you use the word interface correctly, I see no confusion anywhere but in the way you seem use the word. Though I'm sure you know the difference, I just don't see your point at all.]

So where, in the above example, does the distinction between interface and implementation break down? What part of it is (or might be) interface? -- EH

I think that *is* the fuzziness. Interface has multiple definitions, (abstracted)interface to an API(facade), (non-abstracted)interface to an API(MFC like), user interface, hardware interface, interface through a network connection, etc. Sometimes, those definitions cross boundaries and combine with other definitions, creating confusion. Why? Because interface is just a "word interface" to a concept. Obviously, what we as programmers consider an interface is different from a user. Unfortunately, when it comes to things like embedded javascript, we lose the luxury of the programmer/user separation because the javascript implementation (the actual javascript code, not it's handler logic) can be "interfaced" with on multiple levels (C code that handles it, javascript code that is it, user events that manipulate it). If we try to nail down the definition of interface too tightly(as in interface = an abstract facade to an implementation), then the word just gets more cumbersome to use, and has to be qualified. I don't think "interface" should be used except as a very general term, unless it is combined with a qualifying word (facade interface, applications interface, user, hardware, etc). In the code example, I'm having a hard time deciding what that qualifying word is. -- LayneThomas

Using the word interface depends heavily on context, so what, most words do. I still don't buy your point, I see no confusion, sorry.

''That's the problem - the context. There are at least four different levels of context in the example(the c code, the html interface, the javascript interface, and the javascript implementation - which is part of the html interface). It's all one piece of code, but it muddies the use of the word interface. You can't say "interface means x"(for a given context), because there isn't just one context going on there. Perhaps the problem is people have (slightly)varying definitions of interface, even for one specific context(we seem to), and that would definitely cause problems.

Erm, I just realized I ignored my "own" law - LaynesLaw''

LOL, now that I understood! Actually, I understand what you're saying now. If using multiple different definitions of interface in the same context, I'd just use the full description.... 'user interface', 'programmer interface', you need some adjectives to separate the meaning when dealing with different levels of abstraction.

Indeed! I bet QualifyInterfaceWithAdjectives?(context:dealing with different levels of abstraction) is a legitimate pattern.

So, is it safe to say we agree that what is an "interface" is relative to the context or viewpoint? --top

Context dependence does not mean relative unless you're playing HumptyDumpty with the word.

Context dependence at least means that interface-ness is relative to context. It's no longer absolute, but requires context qualifiers.
- Context qualifiers may be absolute. This issue is similar to distances: "I am standing within ten meters of a television tuned to Fox Channel 5" has an absolute truth value that depends on who is saying it, and when and where he is standing. This dependence does not make the statement relative as the word is used by TopMind in other pages, where it typically is used to imply that the truth depends on the viewpoint of the observer. Using such equivocation to defend his 'EverythingIsRelative' is fallacious and shouldn't be considered accepted.
- So you at least agree that context qualifiers are almost always needed in order to be accurate? One cannot say absolutely that "this is an interface." or "this is an implementation".
- At minimum one needs a language context for both whatever one is observing and for the statements "this is an interface" or "this is an implementation". Usually this context is assumed.

[insults deleted]

To my mind, Interface and Implementation do have a clear-cut distinction. Unfortunately, it's a really confusing one.

Basically, the interface is what you can expect; it's what you, as somebody using the thing, need to know to make it work. An interface is used by the outside world. I'm being deliberately vague here, because my concept of an "interface" is a very wide subject.

An implementation is something which lives up to the expectation presented by the interface. There can be any number greater than or equal to 0 of implementations. For example, the interface "This function can return any whole number, but will always return that number" has infinite implementations, as there are infinite whole numbers. On the other extreme, the interface "This function takes another function and an input to apply to that function, and returns true if the function will ever return" has 0 implementations, because creating an implementation would require solving the halting problem.

Unfortunately, my definition of "interface" includes things that would be impossible, or at least very hard, to check at compile-time, or specify in computer-language.

For example, the interface specified by "Instance of IDisposable" implies only two things to the compiler: 1. This object was created by a class which, somewhere in its inheritance hierarchy, implemented IDisposable. 1. This object, when treated as an IDisposable, has "Dispose" with zero parameters. However, the human mind infers two more rules: 1. This object is a wrapper for unmanaged resources, such as files, which we cannot rely on the GC to clean up for us. 1. This object will be useless after Dispose() is called. ...when, in fact, you could make an object which does something entirely different when Dispose is called, and/or doesn't even need deterministic collection.

Similarly, you couldn't write a sum(Array<Int>) method which returned the multiple of all the elements, because it would no longer implement the conceptual interface of sum(Array<Int>), which is, well, "return the sum of all elements in the Array of Integers."

Unfortunately, this makes the implementation quite tightly coupled to the interface. If you overload a method to do something different than it did before, it may still satisfy its interface that the compiler can check, but it won't satisfy the interface that the programmer expects. For example, when you call Array.removeAll(), you expect all the elements to be gone. However, the Array subclass Filtered'Array might overload removeAll() to remove only the elements within the filter. Of course, if another method relies on Array.removeAll() to clear arrays so it can repopulate them, this would cause UnexpectedBehavior?. Array.removeAll() has the conceptual interface of "remove all, and I mean all, elements from the array." Unfortunately, many programmers see any and all internal method behavior as part of the implementation, not the interface, and thus believe that it is sometimes necessary to know the implementation to reason about the behavior of an object. I just chose to define Interface and Implementation from the other way around.

In C/C++, what is typically considered "implementation", even by people without my admittedly weird view, is often used as "interface". For example, some programmers--admittedly, probably only the bad ones--use byte-offsets into structs to view internal members, encapsulation be damned. These byte-offsets, if relied upon enough, become part of the struct's interface. This also means that if they are changed (by refactoring, new output platform, compiler upgrade, quirks mode turned off, etc.), the code breaks.

Of course, people quickly realized that this was a BadThing. Java, for all its faults, did solve this problem: it disallowed all pointer arithmetic, so the interface to any object was just the names. The compiler and the JIT could optimize all they wanted to, and code would never break.

To go back to the much-earlier "browser analogy", you could do other things with the browser. For example, instead of a mapping which makes the user unaware that there is a different implementation behind the fake internet explorer, you could make the browser act entirely strange, while still maintaining the interface "It has to look exactly like Internet Explorer; no buttons should be out of place. You type stuff in the bar, and you get webpages."

For example, you could have "stub-ie", which always redirects you to "404-page not found" or "blank.html" (which reads ThisPageIntentionallyLeftBlank).

You could have "wierd-ie" which flips the "back" and "forward" buttons, requires you to enter the URL in ROT13, and makes pressing "enter" while in the URL bar close the window.

These all appear to implement the IE interface at a glance, just as having a method called Dispose() looks like enough to implement the IDisposable interface at a glance. However, because they don't match your expectations, they can't be used as drop-in replacements for IE; they don't match your conceptual interface.

I don't know where I'm going with this, so I'll probably edit in more later.

--AnonymousDonor.

Disclaimer: I am not implying that anyone here uses InternetExplorer, so don't be insulted and flame me.

OctoberZeroEight

CategoryInterface, CategoryInfoPackaging, CategorySubjectivityAndRelativism