Re: [Vala] Locking null references

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

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