proposed language extension: object state

[W Karas]

Virtual functions could have multiple definitions, for different
object states.

The prototype of a virtual member function could have an optional
reserve word "for" followed by a comma-separated list of state names.

The statement:

virtual using <state>;

would put the object in the state named <state>. The statement:

virtual using 0;

would put the object back in the default state. The expression:

virtual <virt-mem-fun> using <state>

would return true if, at the point of execution of the expression, a
call to the virtual member function <virt-mem-fun> would execute the
definition of the function valid for state <state> .

I think this feature would have many uses. For example, if the read
member function was called for a closed file, this could trigger a
version of read that would throw an exception.

A feasible implementation would be to have multiple v-tables, one
appropriate for each state. State changes would involve changing the
v-pointer(s). This would get complex with in large inheritance
trees. The function to change the v-pointer would itself have to be a
hidden virtual function.

 

[mlimber]

Virtual functions could have multiple definitions, for different
object states.

The prototype of a virtual member function could have an optional
reserve word "for" followed by a comma-separated list of state names.

The statement:

virtual using <state>;

would put the object in the state named <state>.  The statement:

virtual using 0;

would put the object back in the default state.  The expression:

virtual <virt-mem-fun> using <state>

would return true if, at the point of execution of the expression, a
call to the virtual member function <virt-mem-fun> would execute the
definition of the function valid for state <state> .

I think this feature would have many uses.  For example, if the read
member function was called for a closed file, this could trigger a
version of read that would throw an exception.

A feasible implementation would be to have multiple v-tables, one
appropriate for each state.  State changes would involve changing the
v-pointer(s).  This would get complex with in large inheritance
trees.  The function to change the v-pointer would itself have to be a
hidden virtual function.

Why should this be a language extension? It seems like it can be
almost as easily implemented by using a state machine such as the one
described in the GoF's _Design Patterns_, which might look something
like:

struct State
{
virtual ~State() {}
virtual void Foo() = 0;
virtual void Bar() = 0;
};

struct State1 : State
{
virtual void Foo() { /*...*/ }
virtual void Bar() { /*...*/ }
};

struct State2 : State
{
virtual void Foo() { /*...*/ }
virtual void Bar() { /*...*/ }
};

void ChangeState( int newState, std::tr1::shared_ptr<State>& state )
{
// Could use a factory or std::map to make this pretty
if( 1 == newState )
state.reset( new State1 );
else if( 2 == newState )
state.reset( new State2 );
}

void DoSomething( std::tr1::shared_ptr<State>& state )
{
state->Foo();
}

There doesn't seem to be a compelling reason to extend the language
for this sort of functionality, which is not rare but not so common as
to demand language support, especially when existing features permit
it without much hassle.

Cheers! --M