Re: [Vala] Locking null references

[Jürg Billeter <j bitron ch>]

On Tue, 2010-03-30 at 12:33 +0200, "Andrés G. Aragoneses" wrote:
> El 30/03/10 11:58, Jürg Billeter escribió:
> > Hi Andrés,
> >
> > On Tue, 2010-03-30 at 11:47 +0200, "Andrés G. Aragoneses" wrote:
> > > El 30/03/10 11:35, Jürg Billeter escribió:
> > > > On Mon, 2010-03-29 at 18:30 -0700, Jim Nelson wrote:
> > > > > In Vala, I can lock a null reference.  Is this by design or a side-effect?
> > > >
> > > > It's by design (constrained by GObject). Unlike in C#/.NET, we don't
> > > > have a monitor available in every object. Due to this constraint, we've
> > >
> > > AFAIK, it's not that there's a Monitor available in every object. The
> > > lock statement is translated into a Monitor.Enter() call, but note that
> > > this is a static function call.
> >
> > The runtime uses a per instance field to implement Monitor.Enter, as far
> > as I know.
>
> Ok, a private field only available at run-time by the runtime.
> But couldn't vala do something similar with the recently added
> g_type_class_add_private API? This way there would be a solution for the
> lock(this) case. Beware: glib/gobject noob here.

We need a field per instance, not a field per class.

> > > > decided to use different lock statement semantics compared to C#. The
> > > > only other option would have been to not support lock statements at
> > > > all .
> > >
> > > Well, I'm wondering about a 3rd option which would be a compromise: that
> > > vala translate every lock statement with a minimal null-check first, so
> > > if the condition is not met, an exception is raised? What do you think
> > > about this approach?
> >
> > I fail to see what we would gain by doing that. The semantics would
> > still differ significantly from C#. I don't see a reason why the field
> > value should ever be relevant with Vala's lock statement semantics. For
> > example, you can also lock integer fields where the null check wouldn't
> > make any sense.
>
> How about requiring at compile time that the lock statement uses a
> reference-type too, like in C#?

Again, I don't see what we would gain by doing that. The semantics would
still differ significantly from C#.

Jürg