Rename inout/two-way signals to 'bidirectional'.

compilation_tests/invalid_signal_argument.cpp

@@ -3,21 +3,21 @@
 using namespace alia;
 
 void
-g(input<int> x)
+f_input(input<int> x)
 {
 }
 
 void
-h(inout<int> x)
+f_bidirectional(bidirectional<int> x)
 {
 }
 
 void
 f()
 {
-    auto s = value(0);
-    g(s);
+    auto read_only = value(0);
+    f_input(read_only);
 #ifdef ALIA_TEST_COMPILATION_FAILURE
-    h(s);
+    f_bidirectional(read_only);
 #endif
 }

compilation_tests/read_write_intersection.cpp

@@ -5,7 +5,8 @@ using namespace alia;
 void
 f()
 {
-    signal_direction_intersection<read_only_signal, two_way_signal>::type();
+    signal_direction_intersection<read_only_signal, bidirectional_signal>::
+        type();
 #ifdef ALIA_TEST_COMPILATION_FAILURE
     signal_direction_intersection<read_only_signal, write_only_signal>::type();
 #endif

compilation_tests/write_read_intersection.cpp

@@ -5,7 +5,8 @@ using namespace alia;
 void
 f()
 {
-    signal_direction_intersection<write_only_signal, two_way_signal>::type();
+    signal_direction_intersection<write_only_signal, bidirectional_signal>::
+        type();
 #ifdef ALIA_TEST_COMPILATION_FAILURE
     signal_direction_intersection<write_only_signal, read_only_signal>::type();
 #endif

docs/goals-and-rationales.rst

@@ -9,8 +9,8 @@ The goals of the signals component are as follows.
 * Unify the interface to C-style data structures and OOP-style classes (whose data members may be protected behind accessor functions).
 * Provide standard mechanisms for transforming a back end's view of model  state or applying constraints to its manipulations of that state.
 * Provide mechanisms for efficiently detecting changes in signal values. (e.g., It should be possible to poll a signal carrying a large body of text and detect if it has changed since the last poll without examining the entire text.)
-* The 'direction' of signals (i.e., input/output/inout) should be explicitly denoted in both the capabilities that a signal implementation provides and the requirements of a function that accepts a signal as a parameter.
-* A function that expects an input signal should be able to accept an inout signal without requiring the function to do any template shenanigans. (More specifically, a function that accepts a signal should only have to declare the required direction and the value type of the signal. If both of those are concrete, the function shouldn't need to use templates to accept that signal.)
+* The 'direction' of signals (i.e., input/output/bidirectional) should be explicitly denoted in both the capabilities that a signal implementation provides and the requirements of a function that accepts a signal as a parameter.
+* A function that expects an input signal should be able to accept a bidirectional signal without requiring the function to do any template shenanigans. (More specifically, a function that accepts a signal should only have to declare the required direction and the value type of the signal. If both of those are concrete, the function shouldn't need to use templates to accept that signal.)
 * Allow signal wrappers to be agnostic of the signal's direction. (e.g., If I want to implement a wrapper that presents a view of a signal where the value is 10x as large, I should have to define what that means for reading and writing the signal, but I shouldn't have to write three different versions in order to preserve the direction of the wrapped signal.)
 * Ensure that the passing of signal values across functions is as efficient  and lazy as possible. (i.e., Avoid unnecessary memory allocations and  computations of unused values.)
 

docs/signals.rst

@@ -16,7 +16,7 @@ In general, signal values can be read (i.e., polled) and new values can be writt
 
 ..todo:: Add an example of, say, adding two signals and point out how writing to the sum doesn't make sense.
 
-Signals carry a compile-time property that indicates the direction(s) in which values can flow: read-only, write-only or two-way. Similarly, when a function takes a signal as a parameter, the function signature will specify the requirements of the signal:
+Signals carry a compile-time property that indicates the direction(s) in which values can flow: read-only, write-only or bidirectional. Similarly, when a function takes a signal as a parameter, the function signature will specify the requirements of the signal:
 
 * **input**: The function may try to read the signal.
 * **output**: The function may try to write to the signal.

src/alia/common.hpp

@@ -50,17 +50,6 @@ as_utf8_string(string const& text)
     return utf8_string(text.c_str(), text.c_str() + text.length());
 }
 
-// Figure out which shared_ptr to use.
-#ifdef _MSC_VER
-#if (_MSC_VER >= 1600)
-#define alia__shared_ptr std::shared_ptr
-#else
-#define alia__shared_ptr std::tr1::shared_ptr
-#endif
-#else
-#define alia__shared_ptr std::shared_ptr
-#endif
-
 template<typename T>
 T
 clamp(T x, T min, T max)
@@ -223,7 +212,7 @@ struct exception : std::exception
     }
 
  private:
-    alia__shared_ptr<string> msg_;
+    std::shared_ptr<string> msg_;
 };
 
 // vector<N,T> represents an N-dimensional geometric vector with elements of
@@ -589,65 +578,6 @@ unsafe_any_cast(any& a)
 
 struct id_interface;
 
-// Accessors are the means by which UI elements access model state and values
-// computed by the application for display in the UI.
-// The goals of the accessor library are as follows.
-// - Unify the interface to C-style data structures and OOP-style classes
-//   (whose data members may be protected behind accessor functions).
-// - Provide standard mechanisms for transforming the UI's view of model state
-//   or applying constraints to its manipulations of that state.
-// - Provide mechanisms for efficiently detecting changes in displayed values.
-// - Ensure that the passing of values to the UI is as efficient and lazy as
-//   possible.
-//
-// Accessors are passed by const reference into UI functions.
-// They're typically created directly at the call site as function arguments
-// and are only valid for the life of the function call.
-// Accessor wrappers are templated and store copies of the actual wrapped
-// accessor, which allows them to be easily composed at the call site, without
-// requiring any memory allocation.
-// UI functions are untemplated and lose the actual type of the accessor.
-// One consequence of this is that a UI container cannot store its accessor
-// for its entire scope and thus only has access to it within its begin
-// function. If a container needs to set its accessor's value from within its
-// scope, it can do so by reinvoking the UI context with a set_value_event
-// that is processed by the container's begin function.
-//
-struct untyped_accessor_base
-{
-    // If this returns false, the underlying state has no value, so get()
-    // should not be called.
-    virtual bool
-    is_gettable() const = 0;
-
-    // An accessor must supply an ID which uniquely identifies its value.
-    // The ID is required to be valid if is_gettable() returns true.
-    // (It may be valid even if is_gettable() returns false, which would mean
-    // that the accessor can identify its value but doesn't know it yet.)
-    // The ID reference is only valid as long as the accessor itself is valid.
-    virtual id_interface const&
-    id() const = 0;
-
-    // If is_settable() returns false, the accessor is currently read-only and
-    // any UI controls associated with it should disallow user input.
-    virtual bool
-    is_settable() const = 0;
-};
-template<class T>
-struct accessor : untyped_accessor_base
-{
-    typedef T value_type;
-
-    // Get the value. The reference returned here is only guaranteed to be
-    // valid as long as the accessor itself is valid.
-    virtual T const&
-    get() const = 0;
-
-    // Set the value. (Only call if is_settable returns true.)
-    virtual void
-    set(T const& value) const = 0;
-};
-
 // Invoke the standard hash function for a value.
 template<class T>
 size_t

src/alia/data_graph.cpp

@@ -53,7 +53,7 @@ struct named_block_node : noncopyable
     data_block block;
 
     // the ID of the block
-    owned_id id;
+    captured_id id;
 
     // count of references to this block by data_blocks
     int reference_count;

src/alia/data_graph.hpp

@@ -1,4 +1,4 @@
-#ifndef ALIA_DATA_GRAPH_HPP
+#if : std::shared_ptrRAPH_HPP
 #define ALIA_DATA_GRAPH_HPP
 
 #include <alia/common.hpp>
@@ -614,7 +614,7 @@ get_state(Context& ctx, signal<State> const& initial_value)
 template<class Data>
 struct keyed_data
 {
-    owned_id key;
+    captured_id key;
     bool is_valid;
     Data value;
     keyed_data() : is_valid(false)
@@ -692,10 +692,10 @@ struct keyed_data_signal : signal<Data>
     {
         return data_->value;
     }
-    alia__shared_ptr<Data>
+    std::shared_ptr<Data>
     get_ptr() const
     {
-        return alia__shared_ptr<Data>(new Data(data_->value));
+        return std::shared_ptr<Data>(new Data(data_->value));
     }
     id_interface const&
     id() const
@@ -743,7 +743,7 @@ get_keyed_data(
 template<class Data>
 struct raw_keyed_data
 {
-    owned_id key;
+    captured_id key;
     Data data;
 };
 

src/alia/dispatch_table.hpp

@@ -22,7 +22,7 @@ struct dispatch_interface
     }
 };
 
-typedef alia__shared_ptr<dispatch_interface> dispatch_interface_ptr;
+typedef std::shared_ptr<dispatch_interface> dispatch_interface_ptr;
 
 typedef std::
     map<std::type_info const*, dispatch_interface_ptr, type_info_comparison>

src/alia/event_routing.hpp

@@ -28,7 +28,7 @@ namespace alia {
 
 struct routing_region;
 
-typedef alia__shared_ptr<routing_region> routing_region_ptr;
+typedef std::shared_ptr<routing_region> routing_region_ptr;
 
 struct routing_region
 {

src/alia/id.cpp

@@ -35,26 +35,26 @@ clone_into(id_interface*& storage, id_interface const* id)
 }
 
 bool
-operator==(owned_id const& a, owned_id const& b)
+operator==(captured_id const& a, captured_id const& b)
 {
     return a.is_initialized() == b.is_initialized()
            && (!a.is_initialized() || a.get() == b.get());
 }
 bool
-operator!=(owned_id const& a, owned_id const& b)
+operator!=(captured_id const& a, captured_id const& b)
 {
     return !(a == b);
 }
 bool
-operator<(owned_id const& a, owned_id const& b)
+operator<(captured_id const& a, captured_id const& b)
 {
     return b.is_initialized() && (!a.is_initialized() || a.get() < b.get());
 }
 std::ostream&
-operator<<(std::ostream& o, owned_id const& id)
+operator<<(std::ostream& o, captured_id const& id)
 {
     if (!id.is_initialized())
-        o << "<empty owned_id>";
+        o << "<empty captured_id>";
     else
         o << id.get();
     return o;