Re: [Vala] Locking null references

["Andrés G. Aragoneses" <knocte gmail com>]

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).

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