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
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk