** I have moved this thread to ps-developers**
The main trouble with the property bag model is that it avoids
imposing any useful abstraction. Here's a complete and consistent
interface:
class Proxy
{
int SetProperty( string id, int val );
int SetProperty( string id, double val );
int SetProperty( string id, string val );
int GetProperty( string id, int& val );
int GetProperty( string id, double& val );
int GetProperty( string id, string& val );
};
This can do *everything* the Player proxies can do. But it says
nothing about robots, and the compiler cannot help you. Debugging
code on a console-free robot because you typed "MAX_SPED" by mistake
is exactly the kind of problem that hard-coded interface specs are
designed to avoid. How do you know if your property-based code is
portable? By looking at every string in every file and checking the
manual to see that it "must be supported" by drivers?
I'll repeat myself and suggest that properties should be restricted
to driver-specific state. Anything generic should be part of the
interface spec. Portable code should use no properties at all, and
getting/setting properties should be visibly different to using
regular Player interfaces.
By the way, the simulation interface has long supported property bags
for tweaking simulation models in a very general way, so I absolutely
think it's useful in the right place. But it should be used very
sparingly!
If we were going to go down this route, we could have saved a whole
lot of time by using $(generic key-value middleware) and just
specified a set of robot-ish keys.
That's a total of 4 cents worth, so I'll hush up now.
Richard/
On 22-May-07, at 7:51 PM, Toby Collett wrote:
> This is something that is up for discussion, my personal opionion
> is that properties are fine for common functionality.
> Here is a summary of the discussion Geoff and I had about this (I
> dont recall if it was in his original post).
> A list of preferred property names should be declared in the
> interface documentation. Properties such as max speed would be
> candidates for this. This means that *if* a driver supports a
> maximum speed property this would be called max_speed (or whatever
> it is defined as in the interface as the preferred name).
>
> The benefit of this is that properties encapsulate the setting and
> getting both from the client end and from the config file and we do
> not need to create as many methods in our proxies as getting
> properties is generic.
>
> The disadvantage is that the property names are not enforced by the
> compiler, so developers can name there properties slightly
> differently causing issues (hopefully documentation of these will
> mitigate this). The other disadvantage is accessing properties in
> the client proxy is slightly more tedious (PositionProxy-
> >GetProperty("MAX_SPEED") as opposed to PositionProxy->GetMaxSpeed
> (). But we dont have to maintain as large a set of members in the
> proxies.
>
> What is the wider opinion on this?
>
> Toby
>
>
> On 5/23/07, Richard vaughan <vaughan@...> wrote:
>
> On 22-May-07, at 6:11 PM, Geoffrey Biggs wrote:
>
> > Yep, definitely, that's a prime candidate for a property.
>
> Isn't MAX_SPEED a near-universal property of a position device? Most
> position devices should be able to supply that when queried.
>
> I thought properties should be driver-specific, such as
> "VFH_NEARNESS_THRESHOLD" ( I made that one up).
>
> The fact that you suggest a dedicated proxy function gives the game
> away. Robot-portable code should almost never use properties. Or do I
> misunderstand?
>
> Richard/
>
> > Geoff
> >
> > Brian Gerkey wrote:
> >> On May 16, 2007, at 6:21 AM, Marcelo Salazar wrote:
> >>
> >>> Could be interesting to add a function to set the MAX_SPEED in the
> >>> PlayerCc::Position2dProxy, for example:
> >>>
> >>> SetMaxSpeed (double amaxXSpeed, double amaxYawSpeed);
> >>>
> >>> Is it possible request to be included in the next version?
> >>
> >> This sounds like something that should go into Geoff's new property
> >> bag framework, right?
> >>
> >> brian.
> >
> >
> > --
> > Robotics research group, University of Auckland
> > http://www.ece.auckland.ac.nz/~gbig005/
> >
> >
> ----------------------------------------------------------------------
> > ---
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Playerstage-users mailing list
> > Playerstage-users@...
> > https://lists.sourceforge.net/lists/listinfo/playerstage-users
>
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Playerstage-users mailing list
> Playerstage-users@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>
>
>
> --
> This email is intended for the addressee only and may contain
> privileged and/or confidential information
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Playerstage-users mailing list
> Playerstage-users@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-users
|