Subject:
|
Re: Backwards Compatibility (Was Calling all Meta-commands)
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sat, 15 Mar 2003 23:56:02 GMT
|
Viewed:
|
1898 times
|
| |
|
|
In lugnet.cad.dev, Orion Pobursky writes:
> I think we need to put a lock on the creation of any new commands until we
> can properly document the existing commands. This will prevent the overlap
> of functionality.
Having read the other replies to this post, I feel that--no matter how
well-intentioned--putting a lock on new meta-commands is both wrong and
impractical.
The simple fact is that all LDraw-based development is done voluntarily. As
such, it's impossible to control what developers will do. We can ask
nicely, but that pre-supposes that all developers will see the request and
obey it.
And, even if a devoloper voluntarily accepted the lock on new meta-commands,
this could easily result in having the new functionality they wanted to use
a meta-command for never implemented at all. When you're programming
something for fun, you often never come back to ideas that you were
sidetracked from.
It may sound selfish, but when I'm working on LDView, I'm not usually
willing to wait for group opinion before adding some new feature (not that
I've added or even really needed any new meta-commands for LDView, since
it's just a viewer). First off, it takes too long, and forces me to try to
come up with some other feature to work on in the interim. And second, the
simple fact is that I add the features to LDView that I want to add. Many
LDView features are the result of user requests, but the simple fact is that
I'm not going to work on a feature I'm not interested in, no matter how many
users request it.
Having said this, I do believe that we should request that all future
meta-commands be done in such a way that it is self-evident that they are
meta-commands, and not comments.
Here is my suggestion (just a suggestion, mind you). All future
meta-commands could look like the following:
0 {META} <command> [arguments]
Where the "0 {META} " signifies a meta-command (the spaces are both
required, but can be repeated), <command> is whatever the name of your
meta-command is, and [arguments] is the optional list of arguments. Example
(re-do of MPD commands):
0 {META} MPD-FILE <filename>
0 {META} NOFILE
I changed it from FILE to MPD-FILE because FILE isn't really very
self-documenting. The NOFILE command on the other hand isn't really
MPD-specific. It's a generally useful command that just happens to have a
slightly extended definition when present in MPD files, and was originally
created as part of the MPD spec.
Note: I'm not suggesting we EVER implement the above MPD meta-commands. I
feel that the existing MPD meta-commands have been in use too long for it to
be practical to change them. Since all programs would really need to
maintain backwards-compatibility with the old ones, it would mean that files
using the new format would be compatible with less programs, and program
authors would all have to add code to support the new format.
Another note: I haven't really seen it in this thread, but there is a
fundamental difference between meta-commands that actually cause behavior,
and formalized tags for file meta-data. For example, "0 Author:" is a
formalized tag for specifying meta-data. Programs may want to parse the
data, but it's still just a tag.
We could request that future description fields be of the following format:
0 {FIELD} <field name>: <field value>
Example:
0 {FIELD} Created-by: MLCAD
Any program that wanted to could display a free-form list of all the fields
in a file without any fore-knowledge of the field names.
--Travis Cobbs
|
|
Message has 4 Replies:
Message is in Reply To:
154 Messages in This Thread:
(Inline display suppressed due to large size. Click Dots below to view.)
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
