Re: [Vala] Wrapping Errors

2009-08-22 Thread Jan Hudec
On Thu, Aug 20, 2009 at 22:09:21 -0400, Yu Feng wrote: GError doesn't support error wrapping as Java does. Is GLib is purposely avoiding it? If not, it will become a useful feature as the number of libraries that uses GError grows, as the feature has already been proved useful in Java,

Re: [Vala] Why do regular reference types leak null?

2009-08-22 Thread Jan Hudec
Magentus magen...@... writes: I see two problems with not allowing nulls in regular variables. One is that a variable starts its life as null (or even worse, uninitialised), and could be assigned to another variable or returned No, it can't. Vala implements the same definite assignment rules

Re: [Vala] [RFC] Testing framework improvements

2009-08-22 Thread Jan Hudec
Hello, Ildar Mulyukov il...@... writes: On 07.08.2009 02:23:14, Jan Hudec wrote: You could get test method names directly from the library. Use objdump for example. NAK. I need to get the information about type relationships in the library. Without the information from the .gir file, I

Re: [Vala] Wrapping Errors with g_prefix_error?

2009-08-22 Thread Jan Hudec
On Sat, Aug 22, 2009 at 11:52:01 -0400, Yu Feng wrote: On Sat, 2009-08-22 at 09:24 +0200, Jan Hudec wrote: [...] Well, so the code further up the call stack is not going to look at the inner exception anyway except to print it to the operator, right? But for that, it's enough to embed the

Re: [Vala] Why do regular reference types leak null?

2009-08-22 Thread Yu Feng
On Sat, 2009-08-15 at 00:12 +0200, Jiří Zárevúcky wrote: On 08/14/2009 10:57 PM, Sam Danielson wrote: Why shouldn't they be null? IMO, it would just add much more trouble. Checking nulls is responsibility of the programmer. That is consistent with every other language I know, including

Re: [Vala] Wrapping Errors in the vala way

2009-08-22 Thread Yu Feng
On Sat, 2009-08-22 at 21:03 +0200, Jan Hudec wrote: On Sat, Aug 22, 2009 at 11:52:01 -0400, Yu Feng wrote: On Sat, 2009-08-22 at 09:24 +0200, Jan Hudec wrote: [...] Well, so the code further up the call stack is not going to look at the inner exception anyway except to print it to the