Re: [Vala] Methods/ctors overloading



Frederik escribió:
Andrés G. Aragoneses wrote:
Makes sense.
But this problem is limited in scope: public methods of public classes.
So the approach I would propose would be less intrusive than just adding
method overloading that generate overkill names:

a) Make method overloading for non-public members be supported without
restrictions.
b) For public members, method overloading is supported but would
generate a warning if not decorated with an attribute like
[ExposeName("_with_foo")] (being with foo the suffix to add to the
function when exposing the function as a library).

How does that sound?

Hi,

if you would allow method overloading for public methods without a
*mandatory* [ExposeName("")] attribute then you would have to invent a
complex name mangling scheme. Simply naming them "foo0", "foo1", "foo2",
etc. would not be enough because you must ensure that a public method is
always compiled to the same symbol even when another overloaded method
is added. C++ does this by mangling the type signature into the symbol
name [1]. For example,

 void QFontEngine::getGlyphPositions (
                             const QGlyphLayout * glyphs,
                             int nglyphs,
                             const QMatrix & matrix,
                             QTextItem::RenderFlags flags,
                             QVarLengthArray<glyph_t> &  glyphs_out,
                             QVarLengthArray<QFixedPoint> & positions)

becomes

_ZN11QFontEngine17getGlyphPositionsERK12QGlyphLayoutRK10QTransform6QFlagsIN9QTextItem10RenderFlagEER15QVarLengthArrayIjLi256EERSA_I11QFixedPointLi256EE

in the symbol table (actually some C++ compilers have a different
mangling scheme).


It depends on whether method overloading is important enough to have
different semantics for public and private methods or not.

I personally don't like method overloading because the signature
matching rules are not always obvious to humans. 'foo (1)' might call a
different method than 'foo (1.0)'. With Java's autoboxing it gets even
worse. And will 'foo (Object o)' be different from 'foo (Object? o)'?

Ok, that's a good argument against this automatic naming system, so I
would advocate for a compiler error instead of a warning in this case
(so the error advices about making the member private/internal, or
adding the ExposeName -you name it- attribute).

Andres

-- 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]