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.
>>> 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#?
Regards,
Andrés
--
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
