On 2/19/07, Melchior FRANZ <[EMAIL PROTECTED]> wrote:
OK, you are right. The customer gets them set up, not knowing about
them. And everyone else can look at the source code. For more serious
work this will probably always be necessary. Not that it can't all be
documented, but it's a lot of work, and a bit redundant too, when
everyone looks at the code, anyway. ;-)
Not sure where you are going with this line of reasoning. Perhaps we could
document all the fg_commands along side the documentation for all the
property system values and all the special properties that trigger other
functionality when you write to them.
What I would like to suggest is to remove the "show" command.
set/get are enough, and additional, redundant commands don't make
the usage any easier. Just the opposite. (Like --props and --telnet. :-)
These "redundant" commands or command line options, typically arise out of a
desire to maintain some sort of backwards compatibility. I'm not sure where
"show" came from or who uses it, but it's clear from a trivial glance at the
code that it's equivalent to "get". That's a nobrainer to remove as long as
we can [reasonably] ensure that there aren't still old scripts and
interfaces out there that use this ... and be prepaired to help people who
might come out of the woodwork who get caught using the old keyword and
suddenly have problems with their scripts or code.
The property system is a way to manage and store "data". It ties an
"ascii"
> name to a physical memory location in a very convenient way. This is
great,
> this is useful, this is critical.
And that's where I indeed disagree, and I think the author of most of
the property code (David M.) does/did, too. The property system, IMHO,
is and should not be just a data storage medium. It is FlightGear's
nervous system and messaging system.
Maybe we should ask David M. directly before putting too many words in his
mouth, but I know that in the context of XML where he is a clear expert, he
has unambigously argued that XML is for data representation only and trying
to turn it into a programming langauge is clearly abusing the original
intent and will lead to a lot of ugliness down the road. So what does he
think about the property system? Let's send him an email, but he's not an
active project participant so he might not want to be drawn into an overly
pedantic discussion.
The colored ATC screen messages are simply output by writing text to
/sim/screen/red, /sim/screen/green, etc. (see $FG_ROOT/Nasal/screen.nas).
The Festival output is done by writing text to /sim/sound/voices/atc, etc.
And if you write text to /sim/messages/pilot, it is copied to
/sim/screen/yellow (causing the yellow text) *and* to
/sim/sound/voices/pilot.
It's a clever (IMHO :-) messaging system. Waypoints are set by writing
them to /autopilot/route-manager/input. In your opinion this should all
have been done via oodles of fgcommands()? That do then not work
in the property browser, in the httpd interface, on the command line,
...? Big loss, no gain.
There is grey area here, but we have to be careful. The point that I was
trying to make (which apparently snuck through unnoticed) is that even
though your examples work well, there are more complex examples that don't
work nearly as well. Fuctionality that requires multiple arguments doesn't
work nearly as well.
Let me just skip ahead and state the my big objection here is that in order
to push forward with your paradigm, you start traveling deep into the land
of "non-obvious" yourself, which is largely the territory you set out trying
to avoid. There is a reason that "data structures" and "algorithms" have
two separate entries in the dictionary.
Going back to the examples you cite ...
It's not obvious if setting a value twice will cause the code to execute
twice or what should happen. The paradigm seems a little ill defined here.
You are overloading the concept of setting a variable to it's current value
and now you have to define what you mean by that and what really happens.
You can explicitely define what happens in every case, but you are then
propping up an ill conceived paradigm with an increasingly complex set of
external definitions that people must know in order to understand how to
correctly use your paradigm.
Handling more than one argument is also starting to enter ugly territory.
You show that you can just put a space between arguments, but what about
text fields that have space in them already? You are overloading a single
value with multiple values and now you have to define a set of rules to
specify how that is parsed out (and each function has to do it's own
parsing, so it's conceivable that each "special" property could end up with
it's own parsing rules.
You also propose the idea of setting the same property multiple times to
communcicate mulitple arguments... ouch ... I don't even think I need to
comment on that ... hopefully that was a typo! After which assignment is
the listening function really called?
I don't want to continue arguing here for the sake of contesting every point
that is made.
Certainly there is some convenience in writing to a property and having some
specific action happen. But there are limits to the sanity of this
mechanism. Having a listener function floating someplace in the code base
that triggers it's functionality when a value is written to seems like a
very disconnected and non-obvious way to assemble an application.
What we are doing here is basically registering a call back function with a
property. Clearly, as you point out, there are times when doing this is the
shortest path to a solution and the most obvious way to do things.
Callbacks are time honored functions in many API's. But to over generalize
this and abuse this approach to handle all possible function/procedure call
cases, would be a long trip, deep into the heart of non-obvious land.
One of my core design philosophies is to try to make code, logic, control
flow, and data structures as obvious as possible. You can take pot shots if
you want and point out the individual cases where I or others have failed in
that quest, but I think if you do, that will say a lot about the direction
you wish to take this discussion, and I'll probably step off the train at
that point.
I believe that clear separation between data and functionality is critical
to the understandability and straightforwardness of the code. I also
understand that in the real world you have to occasionally (often?) bleed
over the sharp lines of idealism and take some practical steps with larger
issues in mind.
So no, let's not remove the property listener/callback functionality. There
are many places where this is useful. But at the same time, let's not get
so overly zealous with that approach that we try to pound an infinite
variety of peg shapes and sizes into the same square hole.
I will agree that the ascii name to function call mapping is perhaps a bit
clunky and not as clean as it could be, but that's not a reason to throw out
the whole concept.
Regards,
Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
