Content deleted Content added
No edit summary |
Reverted 1 edit by ShahzadCSharp (talk): Spam |
||
| (42 intermediate revisions by 32 users not shown) | |||
Line 1:
{{WikiProject banner shell|class=Start|
{{WikiProject Computing|importance=mid|software=yes|software-importance=mid}}
{{WikiProject Computer science|importance=mid}}
}}
{{merged-from|Subclass (computer science)|16 December 2010}}
{{merged-from|Superclass (computer science)|16 December 2010}}
==Discussion about inheritance==
This is the best place for this article. Despite the attempts by OO enthusiasts to hijack the concept of inheritance as their exclusive property, it can be found in use in functional programming circles as well. -- [[User:Derek Ross|Derek Ross]] 20:10 18 May 2003 (UTC)
Line 29 ⟶ 37:
:Do you know some OOP language doesn't rely on inheritance at all but instead it uses delegation. Anyway, actually you didn't answer my question. what's wrong with the title inheritance (computer science)? My point is why OOP not computer science? Remember it really doesn't matter what is OOP since people have a different view about it. You think inheritance is a fundermantal OO concept while some don't. It is ok but we cannot impose our perception. Instead, we need to be more objective and nutral. In other words, it's really doesn't matter what is the truth here but what people believe the truth is. -- [[User:TakuyaMurata|Taku]] 03:42 19 May 2003 (UTC)
::The answer to your question is written clearly above but I'll repeat it - <
:First, please calm down. I don't mean to insult you or anything at all. We can just discuss about naming peacefully. No? My question is actually different than what you think. I am merely talking about why do you object naming inheritance (computer science). what's wrong with that? Do you think inheritance is NOT a computer science topic? Do you object the name inheritance (computer science) or do you think while it can be acceptable, inheritance (object-oriented programming) is better than it? -- [[User:TakuyaMurata|Taku]] 00:12 20 May 2003 (UTC)
Line 179 ⟶ 187:
----
* Keep it here and make a seperate article for computer science inheritence in general:<br> [[Inheritance (object-oriented programming)]] -- [[User:JohnOwens|John Owens]], [[User:Mbecker|MB]], [[User:Wapcaplet|Wapcaplet]], [[User:Mintguy|Mintguy]], [[User:MyRedDice|Martin]], [[User:MartinSpamer|MartinSpamer]]
* Move it:<br> [[Inheritance (computer science)]] -- [[User:TakuyaMurata|Taku]], [[User:Stephen C. Carlson|SCCarlson]]
Line 191 ⟶ 200:
There isn't really inheritance in CSS. The ''document'' the CSS is attached to has a hierarchy of elements. Elements apply styles based on the Cascade. It's rather complicated. Say we have in HTML a P inside a DIV, then a regular P. In CSS we have rules for P and rules for DIV. The first P might inherit DIV rules -- if they apply. The second will not. It gets wven more complex when you throw the class="foo" attribute in -- [[User:Tarquin|Tarquin]] 21:39 1 Jul 2003 (UTC)
:Are you saying then that professional's don't refer to this as "Inheritence" then? In any case, I think this is a step in the right direction. [[User:Mbecker|MB]] 21:47 1 Jul 2003 (UTC)
:: HTML elements inherit from their parents in the document tree. CSS rules don't inherit from anything. They may end up being combined by the HTML elements that do the inheriting. But just by looking at the CSS file, there is no way of telling. -- [[User:Tarquin|Tarquin]] 21:54 1 Jul 2003 (UTC)
: See [http://www.w3.org/TR/REC-CSS1#inheritance W3C CSS Recommendation section "1.3 Inheritance"]. Since the CSS standard uses a word and concept inheritance, it seems safe to say that the standard terminology for CSS is inheritance. Worth noting from that section that CSS inheritance does not always follow HTML/DOM inheritance expectation - it has its own rules for it. [[User:JamesDay|JamesDay]] 12:56, 27 Oct 2003 (UTC)
==[[Wikipedia:Votes for deletion|VfD]]==
* [[class (computer science)]] - to make a room to rename [[class (object-oriented programming)]].
* [[inheritance (computer science)]] - to make a room to rename [[inheritance (object-oriented programming)]]. (these were listed by [[User:TakuyaMurata|Taku]] AKA TakuyaMurata in some edit histories.)
**I still cannot see why we want to make an exception for above two articles in naming. Most of programming and cs related articles are named [[foo (computer science)]]. It is like we have two zero articles because it is used sighly differntly in number theory and set theory. See each talkpage for details. -- [[User:TakuyaMurata|Taku]]
** Keep [[inheritance (computer science)]], it includes two different topics. Move the other one. [[User:Evil saltine|Evil saltine]] 03:49, 23 Oct 2003 (UTC)
*** Both have multiple meanings. [[User:TakuyaMurata|Taku]] deleted one other for class at 16:12 and listed them both here at 16:20. There's more on the disagreement and more examples at [[Talk:Inheritance (object-oriented programming)]] and [[Talk:Class (object-oriented programming)]]. Class could be moved to (CS) but it makes more sense to keep it with the (OOP) tag like the rest of the OOP articles.
** Rename. Apparently the chief use of inheritance is that in OOP. Wikipedia is an encyclopedia not a textbook. We should discuss as the idea not just as technique. The article should cover history, different approaches and so on. foo (computer science) makes far more sense. -- [[User:TakuyaMurata|Taku]]
**keep both and do not rename OOP to generic computer science. Class (computer science) needs to disambiguate OOP, Windows and other uses for class. Inheritance is also a concept not solely related to OOP. Cascading style sheets (CSS) on web pages are not OOP but are an example of inheritance. [[User:JamesDay|JamesDay]] 11:55, 23 Oct 2003 (UTC)
**I think you are missing my point. Because they are both not limited to OOP, I want to rename them to more generic term. The question is if we want to regard oop is part of cs or not. -- [[User:TakuyaMurata|Taku]]
***You're trying to take an article about mammals and make it the article about animals. The specific case is not the same as the general. We could call one (OOP) and the other (CS) but that would be less clear than keeping all of the OOP articles under (OOP). Based on the inaccurate claim about the design of the Windows interface in which was in class(OOP) you might usefully review the difference between structured programming and object-oriented programming. Some research into the theory called <i>abstract data types</i> (taught in universities during the mid 80s, while Windows was being written and before the ADT concept was widespread); callback functions (what the Windows API uses); and the history of the design and development of Windows would also be useful. It would explain why you didn't prevail in the discussons on the talk pages. The lack of OOP in the Windows API is why Microsoft developed MFC to provide an OOP wrapper around it. Living through the evolution of these things is probably why [[User:Mintguy]] and others were disagreeing with you then and is why I'm disagreeing with you now. Try adding the OOP concepts which you think are generic to the class and inheritance pages instead and let consensus between those in the field get those accurate and generic. [[User:JamesDay|JamesDay]] 01:15, 25 Oct 2003 (UTC)
*I '''cannot''' believe that nearly 6 months after this issue was decided by a vote in which you lost 6 to 2 (see [[Talk:Inheritance (object-oriented programming)]]) you are bringing this subject up again. Please leave the pages as they were. [[User:Mintguy|Mintguy]] 21:00, 25 Oct 2003 (UTC)~
**Please don't get emotional. Wikipedia is not a place to contest your POV with others'. [[Inheritance (computer science)]] has been looking terrible. The article exists only for the justitifaction of POV that inheritance is not CS but OOP. We are not supposed to teach people don't mess up classes or inheritance in OOP with others in CS. It is not important to show a clear definitions if there is no such. I know in your head the idea of OOP is clear-cut and of course in my head that is clear-cut too. But they differ. Why don't we just stop disputing over the definitions of OOP but simply state general ideas instead of clear-cut definitions and views that we have disagreement. You may say I am the one who is bothering you, which might be true but the truth is the long time doesn't seem to make the situation better. What I don't like is not my POV doesn't prevail. I don't care if I am right or wrong that is why I try to minimize exposing my POVs. What I do care is that the articles are in such a sorry status thank to our dispute. If you think inheritance (computer science) is a good article or would be a good article, show me evidence not one that supports your definition of OOP. -- [[User:TakuyaMurata|Taku]] 21:37, Oct 25, 2003 (UTC)
** Keep in accordance with the opinion poll on [[Talk:Inheritance (object-oriented programming))]] (and move this discussion there). [[User:MyRedDice|Martin]] 11:39, 26 Oct 2003 (UTC)
**I'm not going to argue with you. I had enough 6 months ago. I will only say this: Myself, [[User:Stan Shebs]], [[User:JamesDay]], [[User:Doradus]], [[User:Cadr]], [[User:Fubar_Obfusco]], [[User:Mbecker]] and others, have found it impossible to work on the computer science articles that you keep mangling. Please stop. [[User:Mintguy|Mintguy]] 22:02, 25 Oct 2003 (UTC)
**You can count me in this list too ([[User:GRAHAMUK]]), I have also been having a few problems with some CS topics "mangled" recently. I thought I was alone! Nice to have a support group.... [[User:GRAHAMUK|GRAHAMUK]] 00:06, 28 Oct 2003 (UTC)
**I'd rather consolidate them each into one article at the (computer science) ___location. Discuss the computer science concept of class generally (without reference to specific features of either OOP or window classes), since there's a ton of overlap, and then link to sub-articles if additional explanation is necessary. Same with inheritance: the basic idea with both OOP and others (CSS, etc.) is that attributes are inherited; only details differ. --[[User:Delirium|Delirium]] 03:47, Oct 28, 2003 (UTC)
No. No. No, to the last anon IP editor of this article. Inheritance and OOP are NOT about code reuse. If you want to resuse code you can just cut and paste it. It;'s about maintaining an understandable and updateable model of the problem. I'm reverting. [[User:Mintguy|Mintguy]] 22:17, 2 Nov 2003 (UTC)
----
I absolutely agree that Inheritance is the wrong way to go for code reuse. However there are other OOP concepts that directly support code reuse ( such as subtype polymorphism (which not the topic, in a page on Inheritance)). Sorry if my edits provoked the revert. But cut and paste is not scaleable, and if OOP is not the way to go then what? There is a point where cut and paste fails an 'understandable and updateable model'. There has got to be a way for programmers to get past the cut and paste impasse. [[User:169.207.90.93|169.207.90.93]] 23:09, 2 Nov 2003 (UTC)
* Perl programmers: see [http://wiki.slowass.net/assemble.cgi?PerlDesignPatterns]
----
:The point is the motivation for OOP and inheritance is not or should not be code-re-use. I've not edited this article for a while because of a dispute, but I just saw red with re-use being mentioned prominently in the first paragraph, so I just revertted it. But looking at it now (even before your last edit), I see that re-use is still over-emphasised. Promoting re-use as a motivation for inheritance completely misses the point of constructing sensible models. If an inheritance heirarchy is constructed for the sole purpose of code re-use it can lead to labyrinthine ineritance graphs that make it difficult to figure out which class control flow is going to pass to. [[User:Mintguy|Mintguy]] 09:03, 4 Nov 2003 (UTC)
----
:That implies that inheritance is not a 'silver bullet' for code re-use, and that some other concept be used instead, to accomplish the goal; why bother to cast things this way if inheritance just creates problems.
I don't understand what you mean by the 'goal' of code re-use. Code re-use isn't an aim, it's a method of achieving the aim (of er... who knows?). What use is code-reuse in itself? I don't know. Inheritance on the other hand is principally a method of making specialist objects from generic base classes. Once a definitive specialist class has been constructed it should be the final leaf on the inheritance tree and should not be used as a base class for some kind of mutated version which ignores most of the previously defined behaviour. In other words inheritance should be generally inclusive and adaptive upon base class behavior and not exclusive of it. OO inheritance it not like genetic inheritance where attributes are lost aswell as gained. If you were writing an OO model of animal life you would be foolish to inherit Bird from Dinosaur. [[User:Mintguy|Mintguy]]
By the way, Perl has an @ISA construct embedded in the language, which is Perl's method of implementing multiple inheritance. And you can dynamically change the hierarchy 'on the fly', in Perl. Tom Christiansen's ''perltoot'' has details, for example.
[[User:169.207.88.201|169.207.88.201]] 09:19, 4 Nov 2003 (UTC)
----
== Definiton of objects? ==
The article says "In object-oriented programming, inheritance is a way to form new classes (instances of which will be objects) using pre-defined objects or classes", but I would disagree with this definiton. Are there really programming languages where objects are defined?
In my opinion, the "objects or classes" has to be just "classes" there, because it does not make sense to talk about the definition of objects. Objects are just instances, and the definiton is with the class. At least I think so.
:The problem with this article is much deeper. There are programming languages that have inheritance without any classes at all! see [[Prototype-based programming]] [[User:J. in Jerusalem|J. in Jerusalem]] ([[User talk:J. in Jerusalem|talk]]) 10:18, 1 July 2010 (UTC)
== Why does implementation inheritance redirect here? ==
From the open closed principle page:
Meyer's definition advocates implementation inheritance. Implementation can be reused through inheritance but interface specifications need not be.
http://en.wikipedia.org/wiki/Open/closed_principle
given that implementation inheritance and interface inheritance have different uses and represent different design philosophies, it seems worthwhile to separate them out. <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/67.183.113.131|67.183.113.131]] ([[User talk:67.183.113.131|talk]]) 05:04, 17 August 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
:Thanks for the comment – “inheritance” is used in two ways, namely ''[[implementation inheritance]]'' (the subject of this article), and ''[[interface inheritance]],'' also known as ''[[subtyping]]'' (a separate article). I’ve fronted the distinction in the lede as of [https://en.wikipedia.org/w/index.php?title=Inheritance_(object-oriented_programming)&oldid=586138159 this edit] – hope this clarifies matters!
:—Nils von Barth ([[User:Nbarth|nbarth]]) ([[User talk:Nbarth|talk]]) 03:54, 15 December 2013 (UTC)
== need explanation of private and protected inheritance ==
see subject
[[Special:Contributions/68.183.23.57|68.183.23.57]] ([[User talk:68.183.23.57|talk]]) 20:07, 17 January 2013 (UTC)
: Agreed. As far as I know, private inheritance is a feature exclusive to C++, but the article presents it as some universal truth. —[[User:Galaktos|Galaktos]] ([[User talk:Galaktos|talk]]) 16:32, 16 August 2015 (UTC)
::Aren't private and protected inheritance effectively automated composition? [[User:Qwertyus|Q<small>VVERTYVS</small>]] <small>([[User talk:Qwertyus|hm?]])</small> 17:16, 16 August 2015 (UTC)
: Inheritance type may be related with [[Vendor_lock-in|Vendor lock-in]] from above ("vendor") code to successor ("customer") code. Also is convenient to watch to the table with inheritance as to unlocking action of some locked subject (code). [[User:RippleSax|RippleSax]] ([[User talk:RippleSax|talk]]) 21:23, 24 November 2015 (UTC)
== Delegation versus forwarding ==
The article states: "An alternative technique, explicit delegation,..." It presents delegation as a solution to the tension with subtyping when using inheritance for code reuse.
''Forwarding'' is a technique to work around this problem. A method of one class can forward its invocation to an instance that it holds. It is a simple call of a second method from within the originally invoked method, almost always on an instance separate from that to which the original message was sent. By convention the method selector used in the forwarded call is often the same as that for the original call.
''Delegation'' is a more intricate form of dispatching, whereby the method that finally executes does so in the context of the method doing the forwarding. Delegation almost almost requires language support and is usually implemented using techniques akin to those used for call-by-name semantics. The '''self''' language is an example of a language with delegation; I don't know of any others by name.
In a more vulgar sense, the solution alluded to in the paragraph in question is simple object encapsulation and simple method invocation on what is usually an "owned" object. The "forwarding" is in the eye of the designer.
Them term ''delegation'' is more properly used earlier in the article.
I suggest changing ''delegation'' to ''forwarding'' in this sentence.
[[User:Jcoplien|Jcoplien]] ([[User talk:Jcoplien|talk]]) 08:41, 11 May 2016 (UTC)
== Interscience ==
What are causes of variation [[User:Shawnjafi|Shawnjafi]] ([[User talk:Shawnjafi|talk]]) 21:25, 17 October 2016 (UTC)
| |||