In strongly typed languages, method overloading allows to have several versions of a method, with different parameters.

I think this is a great option; if anybody is against it, it might be because it can easily be overdone.

You can easily imagine that method overloading is useful in a function where you can either pass .T. vs .F., as a paramter, or 1 vs. 0. This can be quite useful.

Overdo it, and you will soon have many versions of a method that accept the parameters in different orders and combinations, until you don't know which is which.

The opinions of the author, I think, are exaggerated; overloading can be not only useful, but quite necessary. Imagine a math library that calculates the sine of an angle. It just doesn't make sense to use two different names for two methods that basically do the same thing:

x = oMath.Sine_Float(5.0)
y = oMath.Sine_Double(6.0d)

or whatever you use to specify a double value. Anyway, it is much simpler to have a single method for different argument types.

>( Warning I may have just thrown a Hand Grenade. Question is did I remove the pin? <s> )
>
>I have limited experience with .Net but one concept that caught my eye was
>the allowing of Method Overloading. That is more then one method that has
>the same name in a class but differ by the parameters passed. VFP
>'Handles' that situation by use of PCOUNT( )s and VarTypes, but I saw the
>Method Overloading in .Net as much cleaner.
>
>Why I bring it up is that I was reading a article by an developer that I
>respect Bertrand Meyer in which he states things like:
>
>"Overloading, the most masochistic device ever introduced, means that you
>can give the same name to several methods as long as they differ by at least
>one argument type. This is a rare example of a facility that has no known
>advantage, and many documented problems (it's confusing, and conflicts with
>object-oriented mechanisms such as polymorphism and redefinition) ....
>
>The support for overloading in the CLS is a design flaw. Even if it had any
>conceptual justification, overloading would still be a language concept, and
>one that concerns not the deeper semantic properties of a language, but the
>external appearance of software texts-a mere facility for the program
>writer. It has no place in a general OO model; even less in a scheme like
>the CLS, whose very purpose is to enable many languages to collaborate.
>
>Overloading languages should never have been permitted to pollute the common
>conceptual setup with a marginal mechanism that complicates everyone's job.
>Instead, overloading should have been explicitly removed from the CLS,
>putting the onus on the overloading languages to provide a demangling
>algorithm to clean up any mangled names."
>
>Do others agree with what he is saying?
>
>See: http://www.sdmagazine.com/documents/s=7207/sdm0207f/