On Tue, Jan 11, 2011 at 11:42 AM, Jim Nelson <j...@yorba.org> wrote: > I'll jump in here. > > The original poster is asking that Vala relax some of its restrictions that > are in place due to its relationship with C. The only restriction that's > been named so far (unless I missed something) is overloaded method names. > > Although I used overloaded methods a lot in my past work with Java and C++, > I don't miss them at all with Vala. They worked fine with Java. Name > mangling in C++ is, in my mind, completely broken, particularly since each > vendor uses a different mangling scheme. Not only does this impeded with > building libraries, but walking a debugger stack trace is like studying the > garbage a modem terminal program spits out when mom picks up the phone. > > Personally, I like being able to peruse valac's C code and understand what > it's doing. There are certain situations where this is invaluable, > sometimes more valuable than symbolic debugging.
Automatic name mangling is not the only way to resolve name overloading. Another way is to handle C names manually i.e. using CCode So following example https://github.com/anatol/thrift/blob/vala/lib/vala/src/Server/Server.vala instead of Server(Processor, ServerTransport); Server.with_transport(Processor, ServerTransport, TransportFactory); Server.with_transport_and_protocol(Processor, ServerTransport, TransportFactory, ProtocolFactory); # Next method should be called with_input_output_transport_and_protocol but I am too lazy to type it every time in my Vala code Server.with_all(Processor, ServerTransport, TransportFactory, TransportFactory, ProtocolFactory, ProtocolFactory); Wouldn't it be better to have name overloading, something like this # Default cname Server(Processor, ServerTransport); [CCode (cname_suffix = "_with_transport')] Server(Processor, ServerTransport, TransportFactory); [CCode (cname_suffix = "_with_transport_and_protocol')] Server(Processor, ServerTransport, TransportFactory, ProtocolFactory); [CCode (cname_suffix = "_with_input_output_transport_and_protocol')] Server(Processor, ServerTransport, TransportFactory, TransportFactory, ProtocolFactory, ProtocolFactory); > I understand the original poster's concern. If I'm building a stand-alone > application, it seems restrictive to be constrained by requirements that > only apply to libraries. > > But so far the only objection I've heard on this thread is about overloaded > methods. Can anyone name other constraints that are headaches? 1) Valac cannot compile class if its name is too short. Try to create class called 'A'. 2) Name clashing http://mail.gnome.org/archives/vala-list/2010-December/msg00129.html Can valac resolve it automatically? > > And are overloaded methods really such a got-to-have feature? Or are they a > nice-to-have you can live without? > > -- Jim > > On Tue, Jan 11, 2011 at 7:57 AM, pancake <panc...@youterm.com> wrote: > >> its 1111111 time :D >> >> On 01/11/11 11:11, Xavier Bestel wrote: >> >>> Typical English expression, AFAIK. >>> >> 1st time I heard it..but teh internets has some references. nice to know :P >> >> And what's he's talking about, is Vala's way of mangling names to be >>>>> usable in C, which can make some names that are different in Vala >>>>> conflict once translated to C. That behavior is useful when you're >>>>> coding a library (you want your lin usable from C), but not when you're >>>>> building an application. >>>>> >>>> I didn't read any "mangling" word in his mail, and I don't think this is >>>> a feature for Vala.. but ok, maybe i'm an "old timer". >>>> >>>>> So he's asking for a switch to change name mangling, so that "My.Class" >>>>> and "My_class" have different names in the generated code. I tend to >>>>> agree with him. >>>>> >>>> I think that enforcing decent name constrains is good, not only for >>>> C compatiblity.. but also to force the developer to look for readable >>>> and coherent names for its code. >>>> >>>> This "feature" will help to new users or people who don't want to know >>>> what C is, or just see Vala as a completely unlinked language to C, which >>>> is not the case. >>>> >>> Say what you want, I see it as a purely technical limitation, which does >>> more harm than good. There can be much head-scratching, trying to >>> understand why there's a bug in the program while it's just a >>> non-obvious mangling problem. >>> >>> for me it's a aestethic than technical. I never had big problems with >> name >> mangling issues, because when you understand how Vala works you use >> to type decent and legal names for classes and variables. >> >> But if this problem is such a pain for many people.. we should look for a >> solution. >> >> The 'name mangling' magic you are asking for will force all name symbol >>>> generation to append a random number or prefix everything with the >>>> file name.. this will keep C compatiblity but making readability harder. >>>> >>> That's an implementation detail. You could always use traditional name >>> mangling (so nothing changes), and start adding a suffix/prefix only in >>> case of conflict, so you keep the best of both worlds. >>> >>> Then you will not be able to compile the same program in the two modes >> which >> is IMHO wrong. (how many times did you write a library from a program's >> library? >> >> If you think in these two modes. >> >> I don't think that adding language features by breaking C compatiblity >>>> can benefit Vala.. in the mean that if some day this flag appears, i will >>>> prefer to have it only to fix name collision issues, not breaking feature >>>> list between the two modes. >>>> >>> IMHO there should be 2 modes: >>> - library mode, where conflicts are clearly and loudly shown by valac. >>> - application mode, where conflicts are silently resolved via a suffix >>> or whatever clever magic some smart people invent. >>> >> then people will come asking for support for overloading constructors and >> other >> stuff, that just breaks the basics of the language and the backwards >> compatibility. >> >> What do Jürg thinks about? >> >> --pancake >> >> _______________________________________________ >> vala-list mailing list >> vala-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/vala-list >> > > _______________________________________________ > vala-list mailing list > vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list > > _______________________________________________ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
