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

[pancake <pancake youterm com>]

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#"?)
>
>   
it is not a superset or a subset, they are similar, but not the same. in 
other way: they are different.

This is, maybe some vala code can be compiled as c# and viceversa, but 
this doesnt means that it will not fail at runtime or it will leak or be 
innecifient.

The similarity with c# is just syntactically to make people coming from 
c#/java understand
it faster than

Vala is another language, dont think on compatibilities. Vala has no 
framework,
no dynamic modules, no bytecode, no garbage collecting, so, the use of the
language should be different, because you have to take a little care 
about the
code you write.
>   
> > 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?
>   
Vala and mono are completely different approaches, finding memory
leaks is not as easy as: 'parsing assembly', there's lot of cases where
memory leaks can be detected statically, valgrind can help, oprofile
can help, and many others, but it is a task of the developer to write
decent code and not relay on the compiler to do the things magically
correct.

Vala is able to detect most common cases of memory allocation and
manage it automatically, but it is not perfect, because static analysis
is just a small part to determine if something can happen in a way or
other.

If you want to be able to detect all the leaks in a vala application you
will have to add a garbage collector which registers the use, and control
all the heap in order to determine which parts of the code are using
any object and so on. This implies duplicating all the memory resources
required to run an application. If you do this you will probably end up
with another mono/dotgnu/java/parrot. Which is not the aim of vala.

--pancake