Talk:Fragile base class

From Wikipedia, the free encyclopedia

My understanding of "the fragile base class problem" differs fundamentally from what is currently described in this article (as of 2004-10-18).

What I would call the fragile base class problem is described in [1]. It is a high-level conceptual problem with implementation inheritance, and occurs in equal measure in all OOP languages (except those which don't support implementation inheritance in the first place). It has nothing to do with binary compatibility.

There's nothing wrong with the existing article as such, except that it's describing a completely different problem; it should be renamed to have an appropriate title, perhaps binary compatibility.

I realize that the linked Be paper uses "fragile base class problem" rather than "binary compatibility problem", but that's an error in the Be paper which should be fixed, not propagated. -- BenRG 21:17, 18 Oct 2004 (UTC)

[1] Why extends is evil (in the section headed "The fragile base-class problem" about a third of the way down the page).

I agree with this. After reading the article for the first time, then reading the external link mentioned above, I found they were discussing two separate (but possibly related) topics. A bit of Googling reveals that most pages define FBC to mean a language- and implementation-independent problem that occurs when a base class changes and unexpectedly affects its subclasses. For example, compare fragile base class problem to fragile binary interface problem. I propose that we rename the article to fragile binary interface or fragile binary interface problem, and instead put a reference to it at the top of the page indicating it's a different, but related, problem to FBC. -- Mordomo 22:32, 21 Nov 2004 (UTC)
I've drafted a replacement for the current article under User:Mordomo/FBC. Please review. The current article can be renamed as necessary. -- Mordomo 10:41, 26 Nov 2004 (UTC)

Maury, I think a lot of what you've written is technically very incorrect.

The problem is nothing to do with the layout and size of fields

Umm, this is all that FBC is about. Let me quote the Be paper...
  • The size of objects (i.e. structs or classes)
  • The offsets to "visible" (public or protected) data
  • The existence and size of the vtable
  • The offsets to the virtual functions in the vtable
When your app is compiled and linked, it records all these statistics. If any of these things changes in the library, the compiled app will no longer run. This is the "Fragile Base Class" problem.
FBC most certainly is because of the layout and size of the fields. That's the whole idea! You, as the library programmer, do something as trivial as add a new method without changing the implementation and the system stops working because the vtable --over which you have no control-- is modified.

(although what you said about the structure heritage is correct, I don't see how that's a shortcut).

It's a shortcut because it was a simple way to modify existing compilers to generate "object like" things by designers that were not entirely aware of the ramifications, or didn't care. FBC was anticipated, and avoided, by many OO languages. In general it seems you can class them mophologically. If the language in question allows for runtime modification of base classes, it almost certainly doesn't have FBC.

Also, dynamic linking would be a cause of this, not a solution, as when you use static linking the library is locked in and won't be modified.

Looking over this section, I see that I was being rather undetailed, and I'll re-write this section.
In fact the problem all depends on the quality of the dylink. BeOS had FBC because (as I read it) the size and layout was written down at compile time. NeXT's dylink did not have this problem, method lookup used a single appwide lookaside table instead of static vtables in the libraries themselves, and the linker included a versioning system to avoid the other problems. Self and other classless languages build their entire world at runtime, and thus don't exhibit this problem at all.

If you use dynamic linking the library could be modified without the program knowing, so what it thinks of the offsets for fields would be wrong. Dynamic linking never involves modifying literal constants in the executable program (the offsets) as you say.

That depends on how the language and linker works. Self and other "copy and modify" language create tables at runtime every time, as do most other "dedicated OO" languages. For this reason the offsets will indeed be modified properly. NeXT avoided the problem in a twofold fashion, the methods did not use a static vtable but were copied down at load time, and it also included a versioning system to help avoid problems with static accessors (Obj-C is modified C).
BeOS says "When your app is compiled and linked, it records all these statistics. If any of these things changes in the library, the compiled app will no longer run. This is the "Fragile Base Class" problem." Things can't change in the library if it's linked statically - this is why most people link statically. I understand what you mean about the offsets now, but this only applies using dynamic libraries surely. It doesn't apply within a library or program - only between two seperate modules. CGS 14:03, 14 Sep 2003 (UTC)

The problem is to do with the implementation of the classes - for example, if a class uses an object[], and then gets modified to use an ArrayList, any subclasses that still think it's using object[] will be screwed - that's the fragile base class problem.

This is not FBC, this is improper implementation hiding. This will happen in any language. Note that FBC will occur even if you do NOT change from object[] to ArrayList, all you have to do is add a new "public String name" above the object[] and kapow (sometimes). This is why FBC is so annoying, it's not likely you're really changing anything.
Read the Be paper, even just the topmost portion. They locked down ivars, vtable, you name it by inserting dummies. Note that in their discussion of how to avoid problems with vtable access, they essentially do what ObjC does every time. Yet they consider it ugly.
I personally find it absolutely astounding that Java has the same problems, it's not like people didn't know it existed (although there's no runtime extension mechanism either!).

Unless you can back what you said up, I'm going to revert. Look at some of the linked pages, they talk about the problem in languages such as Java, where field offsets are completely irrelevant. What do you think? CGS 12:06, 14 Sep 2003 (UTC).

Well I think the Be paper will back me up here. I also think it's great that people are actually reading edits!
I think I understand what you mean now - but I can't see how this would be a problem if people used version numbers with their libraries (when you change the structures you change the version number and DLL name) or used static linking. CGS 14:03, 14 Sep 2003 (UTC).
In these cases the problem should not exist. Yet while the problem was well known, the three most common languages, VB, C++ and Java do not provide versioning or lookaside, two almost-trivial solutions to the problem.

As far as I can tell, this is basically a problem that was introduced with C++ and the assumption that a library's interface was a set of binary offsets rather than a set of symbols -- in other words, that the linker is a simple C linker rather than something more high-level. It's basically a tension between the C way of doing things close to the hardware, and the object-oriented principle of separating interface and implementation. To say that "language L has FBC" is to say "in language L, compiled descendant class libraries have to care about their base classes' implementation (binary offsets of public and private members) as well as their interface (names of public members)."

Needless to say, languages that put you a little further from the hardware are less likely to have this problem. Common Lisp -- the first standardized compiled language with an object system -- doesn't have it. Bytecode-compiled languages don't need to have it -- Java does, but Python doesn't. --FOo 14:44, 14 Sep 2003 (UTC)

We shouldn't really say language at all. C++ when compiled for .NET has no problem with FBC, for example. FBC is the fault of the compiler / linker, and is nothing at all to do with the language. CGS 14:48, 14 Sep 2003 (UTC).

Sorry, folks, but Java does not suffer from the FBC problem as formulated in the main article (offsets/linking fragility). In fact, the Java Language Specification (JLS) goes out of its way to discuss precisely what changes to a class are permissable to avoid breaking binary compatibility. Adding public methods or members (at any location) is at the top of the list of permissable changes that have no effect on consumers of a class, including derived classes. This isn't to say that Java doesn't suffer from the FBC problem in other ways (as Hollub outlines in the linked article), but the current article text is extremely inaccurate.

The comment about Java not having Fragile Base Class comment needs to be taken into attention. To back this up, i found the portion:

http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html

Basically only potentially semantic changes in a class interface lead to incompatibility - which in turn would not segfault like in common C++ implementations, but give a linkage error at loadtime.

Besides, the article forces an understanding of the problem as described in one particluar paper and may be subject to misconceptions of these certain engineers from BeOS crew. If there is nothing else to back this representation of the problem, i suggest the article be removed or perhaps be replaced by the one from Mordomo.

My understanding of FBC is that, aside from binary compatibilty problems (solved by re-compiling everything - or perhaps by a better linker), different difficult problems arise. One example of FBC from the understanding i get from different books, could be adding an overload of a method to a base class, which may cause an amiguity with multiple overlad selection possibilities later in the software. While the program would still compile and run "properly", it can cause a semantically different behaviour from the one the programmer was expecting, for example partial loss of data due to automatically inserted casts.

The document http://www.cas.mcmaster.ca/~emil/publications/fragile/ecoop98.pdf provides a description and better examples, and i believe it has more credibility the BeOS paper. It describes the problem being as language-independant problem of changing *implementation* of the base class, without changing the interface. As you would see from examples, this would happen in any language, independant on being static(C++) dynamic (smalltalk, self) or semi-static (Java).

--IlyaMinkov 11:52, 25 Jan 2005 (UTC)

Emil's paper needs to be added to the list of references: it is the key paper that is cited and defines the fragile base class problem. --Schoelle 09:53, 13 November 2006 (UTC)