El 30/03/10 10:55, "Andrés G. Aragoneses" escribió:
>
> IMHO this shouldn't be allowed, just for the sake of consistency with
> other platforms (i.e. Mono requires a non-null reference in null
> statements).
I meant lock statements.
> And even if we don't consider consistency, let's discuss about the
> technical aspects? In Mono a lock statement is translated to an API call
> (Monitor.Enter()), how does it translate in vala? If it's similar, we
> would be in a situation in which completely different parts of a running
> program (let's say, library A and library B which are used by program C)
> do concurrency blocks between each other if they end up using a null
> object in a lock statement, which doesn't make much sense, right?
>
> Andres
>
>
> El 30/03/10 03:30, Jim Nelson escribió:
>> In Vala, I can lock a null reference. Is this by design or a side-effect?
>>
>> class Xyzzy {
>> private File file = null;
>>
>> public File get_file() {
>> File f;
>> lock (file) {
>> if (file == null)
>> file = File.new_for_path("/tmp");
>>
>> f = file;
>> }
>>
>> return f;
>> }
>> }
>>
>> void main() {
>> Xyzzy x = new Xyzzy();
>> stdout.printf("%s\n", x.get_file().get_path());
>> stdout.printf("%s\n", x.get_file().get_path());
>> stdout.printf("%s\n", x.get_file().get_path());
>> }
>>
>> I think this is fine and should be the documented behavior. Because Vala
>> only allows locking member variables (and not "this"), being unable to lock
>> a nulled reference would require allocating a dummy object to lock against
>> or explicitly using a Mutex and forgoing lock(). I find both unappealing.
>>
>> In other words, I think this is okay because it's locking access to the
>> reference and not locking the object itself. This seems right to me -- but
>> I'd feel better if I knew this won't go away in the future.
>>
>> -- Jim
_______________________________________________
Vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
