Talk:Fragile base class
Page contents not supported in other languages.
Reading through this article, it seems that anyone with the most basic understanding of object-oriented programming (that is, they have a reasonable answer to "what is an object?" and "what is a subclass?") will be able to comprehend this article.
I am not sure about the state of this article when this problem was raised in 2009, but as of today, I believe it is as understandable as possible, given its necessary subject matter.
Conversely, the article for multiplication is also very technical, at points hard to understand and using symbols and notation that someone with a basic understanding of mathematics would not be able to comprehend.
Because of these reasons, I will be removing the {{Technical}} template. If there remains a good reason to place that template on this article, it should be placed again, with a dedicated section on this talk page explaining the rationale so that specific action can be taken in order to get the article to the necessary state where that template can be once again removed.
Cheers! - BenLeggiero (talk) 21:59, 2 August 2019 (UTC)[reply]
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).
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
(although what you said about the structure heritage is correct, I don't see how that's a shortcut).
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.
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.
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.
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).
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)
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)[reply]
I think that adding an example or two in some commonly-known languages would go a long way towards two goals:
Right now, I'd say the article appears unfinished, almost a stub.76.104.206.55 (talk) 17:01, 9 October 2011 (UTC)[reply]