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 _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list