Documentation for directors and virtual final methods

5 files changed, 19 insertions, 13 deletions

diff --git a/Doc/Manual/Go.html b/Doc/Manual/Go.html
index 4a60e45e0..047b46edf 100644
--- a/Doc/Manual/Go.html
+++ b/Doc/Manual/Go.html
@@ -785,7 +785,9 @@ In order to override virtual methods on a C++ class with Go methods the
 <tt>NewDirectorClassName</tt> constructor functions receives a
 <tt>DirectorInterface</tt> argument.  The methods in the <tt>
 DirectorInterface</tt> are a subset of the public and protected virtual methods
-of the C++ class.  If the <tt>DirectorInterface</tt> contains a method with a
+of the C++ class.
+Virtual methods that have a final specifier are unsurprisingly excluded.
+If the <tt>DirectorInterface</tt> contains a method with a
 matching signature to a virtual method of the C++ class then the virtual C++
 method will be overwritten with the Go method.  As Go doesn't support protected
 methods all overridden protected virtual C++ methods will be public in Go.
diff --git a/Doc/Manual/Java.html b/Doc/Manual/Java.html
index bf77c1562..3a04b8a79 100644
--- a/Doc/Manual/Java.html
+++ b/Doc/Manual/Java.html
@@ -3629,7 +3629,7 @@ The %feature directive can be applied globally, to specific classes, and to spec
 // generate directors for all classes that have virtual methods
 %feature("director");         
 
-// generate directors for all virtual methods in class Foo
+// generate directors for the virtual methods in class Foo
 %feature("director") Foo;      
 </pre>
 </div>
@@ -3647,7 +3647,7 @@ So for example,
 </div>
 
 <p>
-will generate directors for all virtual methods of class Foo except bar().  
+will generate directors for the virtual methods of class Foo except bar().  
 </p>
 
 <p>
@@ -3683,7 +3683,8 @@ The director classes store a pointer to their underlying Java proxy classes.
 <p>
 For simplicity let's ignore the <tt>Swig::Director</tt> class and refer to the original C++ class as the director's base class.
 By default, a director class extends all virtual methods in the inheritance chain of its base class (see the preceding section for how to modify this behavior).
-Thus all virtual method calls, whether they originate in C++ or in Java via proxy classes, eventually end up in at the implementation in the director class.
+Virtual methods that have a final specifier are unsurprisingly excluded.
+Thus the virtual method calls, whether they originate in C++ or in Java via proxy classes, eventually end up in at the implementation in the director class.
 The job of the director methods is to route these method calls to the appropriate place in the inheritance chain.
 By "appropriate place" we mean the method that would have been called if the C++ base class and its Java derived classes were seamlessly integrated.
 That seamless integration is exactly what the director classes provide, transparently skipping over all the messy JNI glue code that binds the two languages together.
diff --git a/Doc/Manual/Perl5.html b/Doc/Manual/Perl5.html
index 5ce765c26..766ccaede 100644
--- a/Doc/Manual/Perl5.html
+++ b/Doc/Manual/Perl5.html
@@ -3070,7 +3070,7 @@ globally, to specific classes, and to specific methods, like this:
 // generate directors for all classes that have virtual methods
 %feature("director");         
 
-// generate directors for all virtual methods in class Foo
+// generate directors for the virtual methods in class Foo
 %feature("director") Foo;      
 </pre>
 </div>
@@ -3088,7 +3088,7 @@ directors for specific classes or methods.  So for example,
 </div>
 
 <p>
-will generate directors for all virtual methods of class Foo except
+will generate directors for the virtual methods of class Foo except
 bar().  
 </p>
 
@@ -3153,7 +3153,8 @@ For simplicity let's ignore the <tt>Swig::Director</tt> class and refer to the
 original C++ class as the director's base class. By default, a director
 class extends all virtual methods in the inheritance chain of its base
 class (see the preceding section for how to modify this behavior).
-Thus all virtual method calls, whether they originate in C++ or in
+Virtual methods that have a final specifier are unsurprisingly excluded.
+Thus the virtual method calls, whether they originate in C++ or in
 Perl via proxy classes, eventually end up in at the implementation in
 the director class. The job of the director methods is to route these
 method calls to the appropriate place in the inheritance chain. By
diff --git a/Doc/Manual/Php.html b/Doc/Manual/Php.html
index 85732fd33..1b8b2d468 100644
--- a/Doc/Manual/Php.html
+++ b/Doc/Manual/Php.html
@@ -937,7 +937,7 @@ globally, to specific classes, and to specific methods, like this:
 // generate directors for all classes that have virtual methods
 %feature("director");         
 
-// generate directors for all virtual methods in class Foo
+// generate directors for the virtual methods in class Foo
 %feature("director") Foo;      
 </pre>
 </div>
@@ -955,7 +955,7 @@ directors for specific classes or methods.  So for example,
 </div>
 
 <p>
-will generate directors for all virtual methods of class Foo except
+will generate directors for the virtual methods of class Foo except
 bar().  
 </p>
 
@@ -1020,7 +1020,8 @@ For simplicity let's ignore the <tt>Swig::Director</tt> class and refer to the
 original C++ class as the director's base class. By default, a director
 class extends all virtual methods in the inheritance chain of its base
 class (see the preceding section for how to modify this behavior).
-Thus all virtual method calls, whether they originate in C++ or in
+Virtual methods that have a final specifier are unsurprisingly excluded.
+Thus the virtual method calls, whether they originate in C++ or in
 PHP via proxy classes, eventually end up in at the implementation in the
 director class. The job of the director methods is to route these method
 calls to the appropriate place in the inheritance chain. By "appropriate
diff --git a/Doc/Manual/Python.html b/Doc/Manual/Python.html
index 6a174fddf..2554e9da3 100644
--- a/Doc/Manual/Python.html
+++ b/Doc/Manual/Python.html
@@ -2934,7 +2934,7 @@ globally, to specific classes, and to specific methods, like this:
 // generate directors for all classes that have virtual methods
 %feature("director");
 
-// generate directors for all virtual methods in class Foo
+// generate directors for the virtual methods in class Foo
 %feature("director") Foo;
 </pre>
 </div>
@@ -2952,7 +2952,7 @@ directors for specific classes or methods.  So for example,
 </div>
 
 <p>
-will generate directors for all virtual methods of class Foo except
+will generate directors for the virtual methods of class Foo except
 bar().
 </p>
 
@@ -3018,7 +3018,8 @@ For simplicity let's ignore the <tt>Swig::Director</tt> class and refer to the
 original C++ class as the director's base class. By default, a director
 class extends all virtual methods in the inheritance chain of its base
 class (see the preceding section for how to modify this behavior).
-Thus all virtual method calls, whether they originate in C++ or in
+Virtual methods that have a final specifier are unsurprisingly excluded.
+Thus the virtual method calls, whether they originate in C++ or in
 Python via proxy classes, eventually end up in at the implementation in
 the director class. The job of the director methods is to route these
 method calls to the appropriate place in the inheritance chain. By