Re: [Vala] Hi, Is Vala what I am looking for?
- From: "Andrés G. Aragoneses" <knocte gmail com>
- To: vala-list gnome org
- Subject: Re: [Vala] Hi, Is Vala what I am looking for?
- Date: Thu, 17 Sep 2009 12:48:49 -0400
Michael B. Trausch wrote:
On Thu, 2009-09-17 at 11:11 -0400, "Andrés G. Aragoneses" wrote:
Michael B. Trausch wrote:
On Thu, 2009-09-17 at 11:20 +0200, Orlando José Luque Moraira wrote:
Will Vala be in the future able to compile common c# projects with the
original MS library references? (using other libraries)
Welcome to the list.
It would be possible to write a similar framework library in Vala style,
but there would be little point. Any C# code would still need to be
ported to use it. Vala style is a bit different from C# style, and the
Hey, so I understand that a vala file may not be compilable by a C#
compiler, but how about the other way around? (So my question is "is
vala a superset of C#"?)
Nope. Again, there are not only syntax issues, but there is much more
than the syntax that differs between what you'd see in a C# program and
a Vala program.
For example, method names are written like_this. This is incompatible
with java (likeThis) and C# (LikeThis) conventions. Also, data types
But this is just a convention. I'm talking about *real* compiler issues.
are different and have different rules; the underlying data types are C
data types, with some extensions that are provided for by the glib and
In this case, some fake class types could be created for the C# compiler
to be understood by it.
In short, the differences are enough that you'd not be able to use a
single unified source tree, at least not without a great deal of effort.
Of course, _anything_ is possible given enough time. One potential
solution would be to code in neither, and instead generate the code for
For example, you could write a set of GNU m4 macros that would be
processed against text input to generate the same (functionally
speaking) code for Vala and for C#. I don't believe that such a job
I think this effort is not worth it, because you don't end up with a
language which looks like Vala or C#... What I'm talking about is if it
would be possible to write, on purpose, some piece of code that uses the
common set between Vala and C#, and thus, may be compilable by both. [*]
would be terribly easy, mind you, but it would be possible. The macros
would have to be able to effectively abstract away all of the
differences between the two worlds, though; for example, C# has the
concept of "unsafe" operations, while in Vala, everything just _is_.
(After all, Vala compiles to C.)
Among the reasons that it would be very difficult to do is that there is
a massive difference between what's provided by the libraries that can
be assumed to be available when writing Vala code, and the libraries
But let's assume we want to create just a very simple HelloWorld
executable, both compilable by C# and Vala, with no usage of libraries.
If this is possible, we could for example convert a simple C# library
(such as the class System.Console, with just the method "WriteLine")
into this "ValaSharp" language, and then create another executable on
top of it that still runs on both environments. I am not sure if I'm
that can be assumed to be available when writing code that targets the
CLI. But, if something like this _were_ to be done, to do it correctly
and do it well, it would have to support generation of code for more
languages than just C# or Vala: C++ and Java, and maybe a language that
runs on the Parrot VM, would be good ideas. However, that's a _lot_ of
knowledge to have to be encoded into such a system, and unless you have
lots of time, it's likely not worth it.
other major difference is that Vala is not garbage collected. It uses
"assisted memory management" as opposed to garbage collection. This
changes the way you have to think about objects in subtle ways.
Let's say we have a piece of code that can be compiled by both Vala and
C# compilers, but it leaks in Vala but not in Mono (because of the GC).
Could that piece of code be 'tweaked' in order to make it not leak in
the Vala case? If yes, we could develop a Gendarme rule that analyzes
the assembly to search for possible leaks that may occur if the source
code is compiled with the vala compiler, right?
but with Vala, you would use standard tools that are readily
available. You can use gdb for debugging, gprof for function profiling,
I know, but what I'm trying to avoid is the use of runtime tools in
favor of statical analysis tools (Gendarme).
and valgrind for memory use profiling. Since the output of Vala is
(IIRC) standard C89 code, these things all will work. Granted, you'll
have to read through listings that have the names of the variables and
objects in your software transformed to a normalized C form (e.g., the
static method AllTray.Program.main becomes all_tray_program_main). But
you can use tools that are very mature and have been used for years in
everyday native application and system programming.
Just an aside, don't fall into the trap of thinking that just because
you write code for a managed environment that you cannot have memory
leaks. Sure, you won't have memory leaks if you're careful and free
references, but garbage collectors are all about reference counting. If
you still hold a reachable reference to an object, but you're still
finished with it, you're going to leak memory (in that the garbage
collector won't release that memory back to the heap on your behalf).
So, code running in the CLI *can* leak, just as Vala (or C) code can
I know, I'm not assuming that. Let me elaborate. We could divide types
of leaks here:
a) Those that may occur even in a managed environment (as you
mentioned). For example subscribing to an event and forgetting to
unsubscribe it when we stop using the object.
b) Those that wouldn't occur in a managed environment, but could occur
in Vala because of the absense of a GC.
c) Those that would occur in C, but not in Vala.
So, as Gendarme is a static-analysis tool that has some rules to detect
leaks of type (a), I was assuming that it may be possible to detect
those of kind (b). I know that, for the sake of running the assembly in
Mono, the information that a Gendarme rule like this could give would be
useless, but it could be fine if someone wants to keep his source code
free of leaks in *any* environment, provided that his source code is
compilable by both environments (I mean, if what I ask above ^, marked
as "[*]", is answered with a "yes").
] [Thread Prev