<p>What was the motivation for having the <code>reintroduce</code> keyword in Delphi?</p>

<p>If you have a child class that contains a function with the same name as a virtual function in the parent class and it is not declared with the override modifier then it is a compile error. Adding the reintroduce modifier in such situations fixes the error, but I have never grasped the reasoning for the compile error.</p>

[{'answer_id': 53842, 'author': 'Ralph M. Rickenbach', 'author_id': 4549416, 'author_profile': 'https://Stackoverflow.com/users/4549416', 'pm_score': 2, 'selected': False, 'text': '<p>When the ancestor class also has a method with the same name, and it is not necessarily declared virtual, you would see a compiler warning (as you would hide this method). </p>\n\n<p>In other words: You tell the compiler that you know that you hide the ancestor function and replace it with this new function and do so deliberately.</p>\n\n<p>And why would you do this? If the method is virtual in the parent class, the only reason is to prevent polymorphism. Other then that just override and do not call inherited. But if the parent method is not declared virtual (and you cannot change that, because you do not own the code for example), you can inherit from that class and let people inherit from your class without seeing a compiler warning.</p>\n'}, {'answer_id': 58167, 'author': 'Jim McKeeth', 'author_id': 255, 'author_profile': 'https://Stackoverflow.com/users/255', 'pm_score': 6, 'selected': False, 'text': "<p>If you declare a method in a descendant class that has the same name as a method in an ancestor class then you are hiding that ancestor method — meaning if you have an instance of that descendant class (that is referenced as that class) then you will not get the behavior of the ancestor. When the ancestor's method is virtual or dynamic, the compiler will give you a warning.</p>\n\n<p>Now you have one of two choices to suppress that warning message:</p>\n\n<ol>\n<li>Adding the keyword <strong>reintroduce</strong> just tells the compiler you know you are hiding that method and it suppresses the warning.  You can still use the <strong>inherited</strong> keyword within your implementation of that descended method to call the ancestor method.</li>\n<li>If the ancestor's method was <strong>virtual</strong> or <strong>dynamic</strong> then you can use <strong>override</strong>.  It has the added behavior that if this descendant object is accessed through an expression of the ancestor type, then the call to that method will still be to the descendant method (which then may optionally call the ancestor through <strong>inherited</strong>).</li>\n</ol>\n\n<p>So difference between <strong>override</strong> and <strong>reintroduce</strong> is in polymorphism.  With <strong>reintroduce</strong>, if you cast the descendant object as the parent type, then call that method you will get the ancestor method, but if you access it the descendant type then you will get the behavior of the descendant.  With <strong>override</strong> you always get the descendant. If the ancestor method was neither <strong>virtual</strong> nor <strong>dynamic</strong>, then <strong>reintroduce</strong> does not apply because that behavior is implicit. (Actually you could use a class helper, but we won't go there now.)</p>\n\n<p>In spite of what Malach said, you <em>can still call <strong>inherited</em></strong> in a reintroduced method, even if the parent was neither <strong>virtual</strong> nor <strong>dynamic</strong>.</p>\n\n<p>Essentially reintroduce is just like <strong>override</strong>, but it works with non-<strong>dynamic</strong> and non-<strong>virtual</strong> methods, and it <em>does not replace</em> the behavior if the object instance is accessed via an expression of the ancestor type.</p>\n\n<p><strong><em>Further Explanation:</em></strong></p>\n\n<p><strong>Reintroduce</strong> is a way of communicating intent to the compiler that you did not make an error.  We override a method in an ancestor with the <strong>override</strong> keyword, but it requires that the ancestor method be <strong>virtual</strong> or <strong>dynamic</strong>, and that you want the behavior to change when the object is accessed as the ancestor class.  Now enter <strong>reintroduce</strong>.  It lets you tell the compiler that you did not accidentally create a method with the same name as a virtual or dynamic ancestor method (which would be annoying if the compiler didn't warn you about).  </p>\n"}, {'answer_id': 63376, 'author': 'Craig Stuntz', 'author_id': 7714, 'author_profile': 'https://Stackoverflow.com/users/7714', 'pm_score': 2, 'selected': False, 'text': "<p>The RTL uses reintroduce to hide inherited constructors.  For example, TComponent has a constructor which takes one argument.  But, TObject has a parameterless  constructor.  The RTL would like you to use only TComponent's one-argument constructor, and not the parameterless constructor inherited from TObject when instantiating a new TComponent. So it uses reintroduce to hide the inherited constructor.  In this way, reintroduce is a little bit like declaring a parameterless constructor as private in C#.</p>\n"}, {'answer_id': 68154, 'author': 'Francesca', 'author_id': 9842, 'author_profile': 'https://Stackoverflow.com/users/9842', 'pm_score': 2, 'selected': False, 'text': '<p>Reintroduce tells the compiler you want to call the code defined in this method as an entry point for this class and its descendants, regardless of other methods with the same name in the ancestors’ chain.  </p>\n\n<p>Creating a <code>TDescendant.MyMethod</code> would create a potential confusion for the TDescendants in adding another method with the same name, which the compiler warns you about.<br>\nReintroduce disambiguates that and tells the compiler you know which one to use.<br>\n<code>ADescendant.MyMethod</code> calls the TDescendant one, <code>(ADescendant as TAncestor).MyMethod</code> calls the TAncestor one. Always! No confusion…. Compiler happy!  </p>\n\n<p>This is true whether you want the descendant method to be virtual or not: in both cases you want to break the natural linkage of the virtual chain.\nAnd it does not prevent you from calling the inherited code from within the new method.  </p>\n\n<ol>\n<li>TDescendant.MyMethod is virtual: ...but you cannot or don’t want to use the linkage.  \n\n<ul>\n<li>You cannot because the method signature is different. You have no other choice as overriding is impossible in this case with return type or parameters not exactly the same.  </li>\n<li>You want to restart an inheritance tree from this class.  </li>\n</ul></li>\n<li>TDescendant.MyMethod is not virtual: You turn MyMethod into a static one at the TDescendant level and prevent further overriding. All classes inheriting from TDescendant will use the TDescendant implementation.  </li>\n</ol>\n'}, {'answer_id': 85965, 'author': 'apenwarr', 'author_id': 42219, 'author_profile': 'https://Stackoverflow.com/users/42219', 'pm_score': 3, 'selected': False, 'text': '<p>There are lots of answers here about why a compiler that lets you hide a member function <em>silently</em> is a bad idea.  But no modern compiler <em>silently</em> hides member functions.  Even in C++, where it\'s allowed to do so, there\'s always a warning about it, and that ought to be enough.</p>\n\n<p>So why require "reintroduce"?  The main reason is that this is the sort of bug that can actually appear by accident, when you\'re not looking at compiler warnings anymore.  For example, let\'s say you\'re inheriting from TComponent, and the Delphi designers add a new virtual function to TComponent.  The bad news is your derived component, which you wrote five years ago and distributed to others, already has a function with that name.</p>\n\n<p>If the compiler just accepted that situation, some end user might recompile your component, ignore the warning.  Strange things would happen, and <em>you</em> would get blamed.  This requires them to explicitly accept that the function is not the same function.</p>\n'}, {'answer_id': 142459, 'author': 'Frank', 'author_id': 4474, 'author_profile': 'https://Stackoverflow.com/users/4474', 'pm_score': 2, 'selected': False, 'text': "<p>The purpose of the reintroduce modifier is to prevent against a common logical error. </p>\n\n<p>I will assume that it is common knowledge how the reintroduce keyword fixes the warning and will explain why the warning is generated and why the keyword is included in the language. Consider the delphi code below;</p>\n\n<pre><code>TParent = Class\nPublic\n    Procedure Procedure1(I : Integer); Virtual;\n    Procedure Procedure2(I : Integer);\n    Procedure Procedure3(I : Integer); Virtual;\nEnd;\n\nTChild = Class(TParent)\nPublic\n    Procedure Procedure1(I : Integer);\n    Procedure Procedure2(I : Integer);\n    Procedure Procedure3(I : Integer); Override;\n    Procedure Setup(I : Integer);\nEnd;\n\nprocedure TParent.Procedure1(I: Integer);\nbegin\n    WriteLn('TParent.Procedure1');\nend;\n\nprocedure TParent.Procedure2(I: Integer);\nbegin\n    WriteLn('TParent.Procedure2');\nend;\n\nprocedure TChild.Procedure1(I: Integer);\nbegin\n    WriteLn('TChild.Procedure1');\nend;\n\nprocedure TChild.Procedure2(I: Integer);\nbegin\n    WriteLn('TChild.Procedure2');\nend;\n\nprocedure TChild.Setup(I : Integer);\nbegin\n    WriteLn('TChild.Setup');\nend;\n\nProcedure Test;\nVar\n    Child : TChild;\n    Parent : TParent;\nBegin\n    Child := TChild.Create;\n    Child.Procedure1(1); // outputs TChild.Procedure1\n    Child.Procedure2(1); // outputs TChild.Procedure2\n\n    Parent := Child;\n    Parent.Procedure1(1); // outputs TParent.Procedure1\n    Parent.Procedure2(1); // outputs TParent.Procedure2\nEnd;\n</code></pre>\n\n<p>Given the above code both of the procedures in TParent are hidden. To say they are hidden means that the procedures can not be called through the TChild pointer. Compiling the code sample produces a single warning;</p>\n\n<p>[DCC Warning] Project9.dpr(19): W1010 Method 'Procedure1' hides virtual method of base type 'TParent'</p>\n\n<p>Why only a warning for the virtual function and not the other? Both are hidden.</p>\n\n<p>A virtue of Delphi is that library designers are able to release new versions without fear of breaking the logic of existing client code. This contrasts to Java where adding new functions to a parent class in a library is fraught with danger because classes are implicitly virtual. Lets say that TParent from above lives in a 3rd party library, and the library manufacture releases the new version below.</p>\n\n<pre><code>// version 2.0\nTParent = Class\nPublic\n    Procedure Procedure1(I : Integer); Virtual;\n    Procedure Procedure2(I : Integer);\n    Procedure Procedure3(I : Integer); Virtual;\n    Procedure Setup(I : Integer); Virtual;\nEnd;\n\nprocedure TParent.Setup(I: Integer);\nbegin\n    // important code\nend;\n</code></pre>\n\n<p>Imagine we had the following code in our client code</p>\n\n<pre><code>Procedure TestClient;\nVar\n    Child : TChild;\nBegin\n    Child := TChild.Create;\n    Child.Setup;\nEnd;\n</code></pre>\n\n<p>For the client it does not matter if the code is compiled against version 2 or 1 of the library, in both cases TChild.Setup is called as the user intends. And in the library;</p>\n\n<pre><code>// library version 2.0\nProcedure TestLibrary(Parent : TParent);\nBegin\n    Parent.Setup;\nEnd;\n</code></pre>\n\n<p>If TestLibrary is called with a TChild parameter, everything works as intended. The library designer have no knowledge of the TChild.Setup, and in Delphi this does not cause them any harm. The call above correctly resolves to TParent.Setup.</p>\n\n<p>What would happen in a equivalent situation in Java? TestClient would work correctly as intended. TestLibrary would not. In Java all functions are assumed virtual. The Parent.Setup would resolve to TChild.Setup, but remember when TChild.Setup was written they had no knowledge of the future TParent.Setup, so they are certainly not going to ever call inherited. So if the library designer intended TParent.Setup to be called it will not be, no matter what they do. And certainly this could be catasrophic.</p>\n\n<p>So the object model in Delphi requires explicit declaration of virtual functions down the chain of child classes. A side effect of this is that it is easy to forget to add the override modifier on child methods. The existence of the Reintroduce keyword is a convenience to the programmer. Delphi was designed so that the programmer is gently persuaded, by the generation of a warning, to explicitly state their intentions in such situations.</p>\n"}, {'answer_id': 401392, 'author': 'Matthias Hryniszak', 'author_id': 49970, 'author_profile': 'https://Stackoverflow.com/users/49970', 'pm_score': 2, 'selected': False, 'text': '<p>First of all, "reintroduce" breaks the inheritance chain and should <strong>not</strong> be used, and I mean <strong>never ever</strong>. In my entire time I worked with Delphi (ca 10 years) I\'ve stumbled upon a number of places that do use this keyword and it has always been a mistake in the design.</p>\n\n<p>With that in mind here\'s the simplest way it works:</p>\n\n<ol>\n<li>You have like a virtual method in a base class</li>\n<li>Now you wanna have a method that has the exact same name, but maybe a different signature. So you write your method in the derived class with the same name and it will not compile because the contract is not fulfilled.</li>\n<li>You put the <em>reintroduce</em> keyword in there and your base class does not know about your brand new implementation and you can use it <strong>only</strong> when accessing your object from a directly specified instance type. What that means is toy can\'t just assign the object to a variable of base type and call that method because it\'s not there with the broken contract.</li>\n</ol>\n\n<p>Like I said it\'s pure evil and must be avoided at all cost (well, that\'s my opinion at least). It\'s like using <strong>goto</strong> - just a terrible style :D</p>\n'}, {'answer_id': 4749516, 'author': 'Ian Boyd', 'author_id': 12597, 'author_profile': 'https://Stackoverflow.com/users/12597', 'pm_score': 2, 'selected': False, 'text': "<p><strong>tl;dr:</strong> Trying to override a non-virtual method makes no sense. Add the keyword <code>reintroduce</code> to acknowledge that you're making a mistake.</p>\n"}, {'answer_id': 4750135, 'author': 'Jeroen Wiert Pluimers', 'author_id': 29290, 'author_profile': 'https://Stackoverflow.com/users/29290', 'pm_score': 1, 'selected': False, 'text': '<p>This has been introduced to the language because of Framework versions (including the VCL).</p>\n\n<p>If you have an existing code base, and an update to a Framework (for instance because you bought a newer Delphi version) introduced a virtual method with the same name as a method in an ancestor of your code base, then <code>reintroduce</code> will allow you to get rid of the <a href="http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/cm_hidden_virtual_xml.html" rel="nofollow">W1010 warning</a>.</p>\n\n<p>This is the only place where you should use <code>reintroduce</code>.</p>\n'}, {'answer_id': 31089509, 'author': 'Rohit Gupta', 'author_id': 4779472, 'author_profile': 'https://Stackoverflow.com/users/4779472', 'pm_score': 0, 'selected': False, 'text': '<p><strong>reintroduce</strong> allows you to declare a method with the same name as the ancestor, but with different parameters. It has nothing to do with bugs or mistakes!!!</p>\n\n<p>For example, I often use it for constructors...</p>\n\n<pre><code>constructor Create (AOwner : TComponent; AParent : TComponent); reintroduce;\n</code></pre>\n\n<p>This allows me to create the internal classes in a cleaner fashion for complex controls such as toolbars or calendars. I normally have more parameters than that. Sometimes it is <strong>almost impossible</strong> or <strong>very messy</strong> to create a class without passing some parameters.</p>\n\n<p>For visual controls, Application.Processmessages can get called after Create, which can be too late to use these parameters.</p>\n\n<pre><code>constructor TClassname.Create (AOwner : TComponent; AParent : TComponent);\nbegin\n  inherited Create (AOwner);\n  Parent      := AParent;\n  ..\nend;\n</code></pre>\n'}, {'answer_id': 47268906, 'author': 'Roman Krejci', 'author_id': 8933951, 'author_profile': 'https://Stackoverflow.com/users/8933951', 'pm_score': 1, 'selected': False, 'text': '<p>First, as it was said above, you should never ever deliberately reintroduce virtual method. The only sane use of reintroduce is when the author of the ancestor (not you) added a method that goes into conflict with your descendant and renaming your descendant method is not an option. Second, you can easily call the original version of the virtual method even in classes where you reintroduced it with different parameters:</p>\n\n<pre><code>type \n  tMyFooClass = class of tMyFoo;\n\n  tMyFoo = class\n    constructor Create; virtual;\n  end;\n\n  tMyFooDescendant = class(tMyFoo)\n    constructor Create(a: Integer); reintroduce;\n  end;\n\n\nprocedure .......\nvar\n  tmp: tMyFooClass;\nbegin\n  // Create tMyFooDescendant instance one way\n  tmp := tMyFooDescendant;\n  with tmp.Create do  // please note no a: integer argument needed here\n  try\n    { do something }\n  finally\n    free;\n  end;\n\n  // Create tMyFooDescendant instance the other way\n  with tMyFooDescendant.Create(20) do  // a: integer argument IS needed here\n  try\n    { do something }\n  finally\n    free;\n  end;\n</code></pre>\n\n<p>so what should be the purpose of reintroducing virtual method other than make things harder to read? </p>\n'}]
['https://Stackoverflow.com/questions/53806', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/4474/']