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