Re: [Vala] vala code generation too constrained?

[Jim Nelson <jim yorba org>]

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.

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?

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