Re: [Vala] Methods/ctors overloading

["Andrés G. Aragoneses" <knocte gmail com>]

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

--