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/ _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list