Re: [Vala] Vala Digest, Vol 1, Issue 3

[Jürg Billeter <j bitron ch>]

Hi Cayle,

On Sam, 2006-08-26 at 02:05 -0500, Cayle Graumann wrote:
> Interesting project so far...   Like Everaldo earlier, I am interested
> in using vala to program the Nokia 770.   It would be nice to have a
> little more documentation, but I realize this project is in a very
> early stage.    I am an experienced java programmer, and since you
> said this language was close to C#, I have been catching up on my C#
> and my GObject reading.  Could you briefly list some of the syntactic
> differences between Vala and C#?  I know that C# doesn't have signals
> and callbacks are very different.  Earlier you explained about the
> 'construct' keyword, which was exceedingly helpful.

Rough and incomplete list of syntactic changes from C# 2.0 to Vala:

- No nested namespaces or nested types (might change)
- No checked/unchecked/unsafe/using blocks
- No yield statements
- No labels, no goto
- No method overloading
- No operator overloading (might change)
- Support default arguments (C++ syntax)
- Constructors may not have parameters
- Named construction methods[1]
- Support methods and fields in namespaces (always static)
- Support lambda expressions (C# 3.0 syntax)
- No partial classes
- No protected members (might change)
- `ref' and `weak' keywords to indicate strong / weak references
- Structs may not implement interfaces
- Structs do not inherit from Object
- Support construction properties[1]
- Replace events by signals where the method signature is specified as
part of the signal declaration
- No event add/remove accessors
- Replace delegates by callbacks (syntax not definitive, syntax for
object-oriented callbacks not yet specified)
- No indexer methods (might change)
- No conversion methods (might change)
- No params array parameter (might change)
- Support non-abstract methods in interfaces

> I have discovered a couple differences so far:  the keyword '
> protected' ( it looks like only 'public' and 'private' are) is not
> supported, and nested namespaces are not supported.   Also if you

We'll probably reintroduce protected members. There is no way in GObject
to somehow protect access to protected fields and methods except by
using a comment in the header file but the Vala compiler could of course
report errors when trying to illegitimately access protected members.

>  specify a long constant like 32768L or 32768l, it will not compile as
> it thinks that is a variable or a label and not a long constant and

The compiler doesn't support that yet but it is planned for inclusion.

>  complain about it.  Are all the GLib portable data types going to be
> supported?  Looking at the GLib interface, I see that the 64 bit
> integer types are supported, but the 32 bit types are not.  I ask
> because I have a whole lot of java int math to convert  ( Java's int's
> are standardized at 32 bits).  

I'm planning to add (u)int16/32 types to get exact-width data types. I
don't know which glib-supported platforms don't use 16-bit shorts and
32-bit ints but there might be some. I assume that linux only supports
ILP32 and LP64 or are there other data models on some linux platforms?

Regards,

Jürg

[1] http://www.paldo.org/pipermail/vala/2006-August/000026.html