Hi Jürg: El 30/03/10 11:35, Jürg Billeter escribió: > Hi Jim, > > 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. > 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? > In Vala lock(foo) locks the field `foo' and not the instance where `foo` > points to. This means that the current value of the field is completely > irrelevant, and locking a field whose value happens to be null is > perfectly fine. > >> 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. > > Yes, it's unfortunate that we can't properly support lock(this) as > GObject doesn't support it and we can't just add a mutex field to > instance structs as this would result in issues when using lock(this) in > subclasses. Otherwise, I'd probably recommend using lock(this) in most > cases. > > Jürg _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
