Andrés G. Aragoneses wrote: > 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
I could live with it if an [ExposeName] attribute was mandatory for public methods. But in this case the developer would still have to be creative for public method naming, of course. Only the usage of these methods would be shorter (however, not necessarily clearer). By the way, named constructors are so nice that developers try to emulate them in other languages with static methods to express semantic differences: http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Named_Constructor I would probably avoid method/constructor overloading even if Vala supported it. And it might be confusing if Vala supported both constructor overloading and named constructors. But named constructors can't be dropped because they allow for different constructors with same signature which would not be possible with constructor overloading only but is used by some GObject libraries. Best regards, Frederik _______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
