Linked by Hadrien Grasland on Wed 15th Jun 2011 07:32 UTC, submitted by ebasconp
General Development "The recently finished C++ ISO standard, with the working name of C++0x, is due to be published this summer, following the finishing touches to the ISO spec language and standards wonks agreed upon in March."
Thread beginning with comment 477514
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: Basically, awesome
by FealDorf on Fri 17th Jun 2011 11:10 UTC in reply to "RE[7]: Basically, awesome"
FealDorf
Member since:
2008-01-07

Class C1 implements A1, A2

make change to A2; C1 still works with A1

Reply Parent Score: 1

RE[9]: Basically, awesome
by vodoomoth on Fri 17th Jun 2011 12:17 in reply to "RE[8]: Basically, awesome"
vodoomoth Member since:
2010-03-30

"And..."

Why don't you finish your sentence? What happens when some code that expects the changed A2 is given an old C1 that doesn't have the change?

And how is that an advantage to have C1 drift away from A2? I guess C1 being an implementation of A2 was motivated by a need. What happens to that need?

I think you are just struggling to justify the unjustifiable. Give us a working example of what you are advocating.

Reply Parent Score: 2

RE[10]: Basically, awesome
by FealDorf on Sat 18th Jun 2011 00:35 in reply to "RE[9]: Basically, awesome"
FealDorf Member since:
2008-01-07

Why don't you finish your sentence? What happens when some code that expects the changed A2 is given an old C1 that doesn't have the change?

Um, I didn't say "and.." at any point. My bad though, I should've elaborated.

And how is that an advantage to have C1 drift away from A2? I guess C1 being an implementation of A2 was motivated by a need. What happens to that need?

The advantage is that there's no real disadvantage in exchange for improved flexibility.
The need for classes themselves are because you want to construct objects that adhere to an interface.
Interfaces exist to facilitate modularity i.e., they exist in different modules.


The way I can see (right now, atleast), the only case where "C1 implements A2; A2 changes" is an issue is when Object of C1 is passed to a method accepting A2 (say, M1) in an invocation (I1). Then:
#1 I1 and M1 are in same module (which implies recompilation either way)
#2 I1 and M1 are in different modules (in which case, only I1 needs to be changed and not C1 and I1)

Mind you, I'm not saying "there's no case where a class MUST implement an interface" -- however that is better moved to compile-time annotations than make a language restriction.

I think you are just struggling to justify the unjustifiable. Give us a working example of what you are advocating.

I don't think a working example actually exists where interface hierarchy *is* required. However, a simple example for me would be:

class LinkedList implements List, Stack, Queue;


In reality though a LinkedList does NOT have to implement Stack or Queue. Also, even the slightest change necessitates an unneeded recompilation. On top of it; size, dependency and complexity of the class increases.

Edited 2011-06-18 00:37 UTC

Reply Parent Score: 1

RE[9]: Basically, awesome
by moondevil on Fri 17th Jun 2011 15:16 in reply to "RE[8]: Basically, awesome"
moondevil Member since:
2005-07-08

Class C1 implements A1, A2

make change to A2; C1 still works with A1



Can do the same in any language that supports interfaces concept.

Plus Go does not provide any solution for collisions, when your change to A2 conflicts with A1.

Reply Parent Score: 2

RE[10]: Basically, awesome
by FealDorf on Fri 17th Jun 2011 23:51 in reply to "RE[9]: Basically, awesome"
FealDorf Member since:
2008-01-07

From what I can remember, only Eiffel (and descendants) provides a complete solution for the problem of method-collision.

And if you do the same in other languages, it will/may cause a runtime or compiletime error. Why? Cuz unless we're also compiling code where you pass a C1 object into a method which accepts A1 object, you are less likely to face an issue. But in Go, no such strict description is required that C1 *must* implement every method of A1 or A2.

Reply Parent Score: 1