Subject:
|
Re: Backwards Compatibility (Was Calling all Meta-commands)
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sun, 16 Mar 2003 03:53:47 GMT
|
Viewed:
|
1989 times
|
| |
|
|
In lugnet.cad.dev, Travis Cobbs writes:
> 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.
Right. While a lock would be well meant, it just isn't the right approach.
> 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.
Yep.
> 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).
Not selfish in the least, I don't think. If you're doing this for your own
enjoyment, why should you be expected to get a group opinion before adding
something?
> 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.
Yep.
> 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
A valid suggestion - but are the braces necessary? Perhaps just the word META.
Another suggestion Kevin kicked around with me (and I mentioned it to Steve,
I forget his rection though), was introducing a new line type specifically
for meta-commands. Thoughts on that?
(note that all my comments come from a non-programmer perspective)
> 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.
Very good point.
> 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.
One thing I'm concerned about is making it easy for people to hand-edit
files. IMO, the less text someone has to type in, the better. So, a new line
type would be efficient for that (but it could be an inconvenience in
another area, I don't know). OR -- shorter identifiers could be used with
line type 0, or at least no special characters. It's a bit more laborious to
type in
0 {FIELD} blah...
than it is to type
0 FIELD blah...
Nevertheless - I do think RIGHT NOW the focus should be on documenting what
we have, per Kevin's goals, and LATER we should worry about the future of
meta-commands. One thing at a time.
-Tim
|
|
Message has 1 Reply:
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
|
|
|
|
