David Megginson writes: > > Norman Vine writes: > > > I think that what we are really trying to say is > > > > class SomeSystem : public FGSubsystem > > { > > ..... > > private: > > > > FGProperty* _serviceable; > > FGProperty* _rpm; > > FGProperty* _pressure; > > FGProperty* _suction; > > }; > > Not if this means what I think it means. Right now we're using the > very common Command design pattern to represent actions that can be > initiated by the user; in contrast, I think that you're talking about > a class something like > > class FGProperty > { > public: > void adjust (...); > void multiply (...); > void assign (...); > // etc. > private: > SGPropertyNode_ptr _node; > }
Actually I was thinking about writing self documenting code ie something like // virtual base class class FGProperty : public SGPropertyNode { FGProperty () = 0 ; } // type specific derived classes for each property 'type' class FGInt : public FGProperty { } class FGBool public FGProperty; class FGDouble public FGProperty; class FGString public FGProperty; etc.. then class SomeSystem : public FGSubsystem { ..... private: FGBool* _serviceable; FGDouble* _rpm; FGDouble* _pressure; FGDouble* _suction; }; SomeSystem::init () { _serviceable = new FGBool("/systems/something[0]/serviceable", true); _rpm = new FGDouble("/engines/engine[0]/rpm", true); _pressure = new FGDouble("/environment/pressure-inhg", true); _suction = new FGDouble("/systems/something[0]/suction-inhg", true); } This way we can have Dr Pangloss's best of both worlds ie Abstract properties and a data structure where the intent is discernable by casual inspection and standard 'C' programming tools can be used for documentation creation Cheers Norman _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel