From: Edward Diener (eldiener_at_[hidden])
Date: 2007-05-24 08:53:14
Johan Torp wrote:
>> Date: Wed, 23 May 2007 17:48:20 -0400
>> From: Edward Diener <eldiener_at_[hidden]>
>> Your idea is essentially a 'property' whose change in value triggers a
>> notification event. Both Java and dotnet have such functionality
>> combined with the idea of Javabean properties in the former and dotnet
>> component properties in the latter.
>
> Do you have any links describing .NET and Javas implementations? I've
> googled a bit and have been able to find some information but no
> proper reference or rationale.
For Javabeans you can look at http://java.sun.com/products/javabeans/ .
For dotnet components you can look at MSDN online at
http://msdn2.microsoft.com/en-us/library/default.aspx and search for
'property'.
>
>> I have worked on my own with the idea of a C++ 'property', but not with
>> enough personal satisfaction to put it in the sandbox or submit it to
>> Boost. Reece Dunn, I believe, has submitted his own idea of a C++
>> 'property' as an implementation to the sandbox in the past. Obviously
>> notifiers as events can be built into the idea of a C++ 'property'
>> whenever the property changes and Java goes so far as to actually build
>> into their idea of a Javabeans 'property' the idea of being able to
>> cancel the change before it happens by an event ( signal ) listener (
>> slot ).
>
>
> I had a quick glance at these and I believe that this is not what I'm
> looking for.
>
> Properties are exposed member variables, I do not believe it is a good
> idea to expose members.
Properties in Java and dotnet are not exposed member variables. Rather
they are member functions which get and/or set values. The advantage of
a property is that one can use member data access notation, ie. avalue =
someObject.someMember for getters and someObject.someMember = avalue for
setters, and one is internally calling a member function to get or set
some value. The value itself does not even have to be a data member but
can be retreived or assigned on the fly. For many C++ programmers
properties are merely syntactic sugar for calling a getSomeValue and/or
setSomeValue member function, which in essence it is, but it regularizes
the syntax in a consistent way.
> The typical usage for this class, let's call
> it observable_value, is:
>
> class logic_class
> {
> const observable_value<bool>& GetSomeState() const;
> const observable_value<money_class>& GetCredits() const;
> };
>
> Setters needn't be supplied and if they are, they can do more things
> than just setting an internal observable_value variable.
In the properties of Java and dotnet a property can be just gettable and
not settable. Since they are member functions, one can trigger events (
signals ) when they are called, just like any other member functions.
Your notion is essentially to trigger an event when a "property"
changes. I think that is valuable but I just wanted to point out to you
that it already has precedents in other implementations. Of course Java
and dotnet use their own event-driven implementations, but the Boost
signals library is as good or better than either of them.
>
>> I do not think the idea of an event whenever a 'property' changes should
>> be part of the signals library itself but it can, and should IMO, use
>> the signals library whenever the change occurs. I think the idea itself
>> of a signalled 'property' change belongs in its own separate
>> implementation, since the signals library is sufficient enough providing
>> just the notion of signals and slots ( or events and handlers as others
>> may call it ).
>
> This is probably a better idea. This simple class could, with a lot of
> work, be extended into a library which could support the standard
> collections and other user defined value types as long as all
> non-const methods are wrapped to detect state changes. I.e. we would
> need to implement a non-const wrapper iterator for STL collections.
Good luck, but do look into the idea of 'property' if you like. In the
implementations I mentioned it basically encapsulates the concept of a
value of an object which is retrievable or changeable and which may, if
the programmer so chooses, trigger an event to notify of the change in
the value.