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
