Documentation for directors and virtual final methods

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.

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.

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

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

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