Re: [Vala] Hi, Is Vala what I am looking for?

["Michael B. Trausch" <mbt zest trausch us>]

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
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
glib-gobject libraries.

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
both.

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
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
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?

No, but with Vala, you would use standard tools that are readily
available.  You can use gdb for debugging, gprof for function profiling,
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
leak.

        --- Mike

-- 
Blog:  http://mike.trausch.us/blog/
Misc. Software:  http://mike.trausch.us/software/