Re: [Vala] inline C

On Sun, 2008-12-14 at 00:55 +0100, Hans Vercammen wrote:
On Sun, 2008-12-14 at 00:51 +0600, Ildar Mulyukov wrote:
On 14.12.2008 00:00:31, Jamie McCracken wrote:
On Sat, 2008-12-13 at 17:46 +0000, Karl Lattimer wrote:
On Sat, 2008-12-13 at 23:44 +0600, Ildar Mulyukov wrote:
What do you think about having C inline in Vala? This looks quite  
natural for Vala. Especially while Vala is quite unperfect (having  
304 open bugs). This could ease implementing workarounds ;)
+1 it would be nicer for certain things to just use C rather than  
having to write vapi e.g. the uuid.vapi I had to write for wizbit,  
meant more code than just using C...
There would have to be some sanity wrapping though to make sure that  
the C stuff would work properly with the vala stuff...

You can currently get the same effect by using extern keyword for c  
functions in an included c file (you can pass a .c file to valac for  
this purpose)

The disadvantage to inlining is it destroys the platform independence  
- IE you would not be able to create a gcc front end for vala nor  
would you be able to have vala->c++ or vala->jvm/clr.

1. inlining asm is most unportable. But this did not prevent from  
adding it to GCC. Surely it should be documented as limiting  

Vala is not a preprocessor for gcc, although I'm sure many people look
at it this way. Embedding ASM/C could also horribly break the automatic
memory management, one of the most overlooked key features. 
Is the 'break' an obligation? The embedded code can always be written in
a way such that conforms the automatic management.

Also, I
expect my vala code to go smoothly through the gcc compiler and to abort
otherwise. Embedding might be nice in some cases, but no doubt it can
generate uncontrollable side-effects. 
Uncontrollable by whom? If the programmer is skillful enough, she can
always control the side-effects of any piece of code written by

Like Jamie said; if there is
specific need you can import the exotic stuff by using extern and
dedicated c files or use the vala api files.
I would like to add to this point: 

dedicated c files also make the project layout cleaner. 

The need for inline low-level code usually indicates either that an
extra level of abstraction is needed in the project, or that the current
boundary between low-level and high-level semantics is inappropriate.

Machines can be happy if the ccode are written carefully, but a
bilingual text is usually difficult for human beings to understand; to
me this is more convincable than any other arguments against inline C.

- Yu
2. Making different backends can be planned only when Vala will  
correctly implement 100% of it's features (delegates, properties). When  
time comes, we can limit this feature to just one backend, etc. etc.  
Anyway let's make small steps: those ones that we need; later we can  
change it ( XP approach ).

I don't really favour this approach. Personally, I rather have limited
functionality that works and is not expected to change as opposed to
having a bunch of sugars that work in most cases and are removed/limited
when proven to fail otherwise. The vala concept works fine, so I think
it would better to target 1.0-stable and fix the relevant blocking bugs


Vala-list mailing list
Vala-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]