Re: [Vala] vala code generation too constrained?

[Anatol Pomozov <anatol pomozov gmail com>]

On Tue, Jan 11, 2011 at 11:42 AM, Jim Nelson <jim 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 <pancake 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