Re: [Vala] vala code generation too constrained?



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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]