Not at all.duds26 wrote:[Now who's making the parser's life difficult!?!
My suggestions were based on an assumption (without looking at the code) about how the catalog parser worked. My assumption :
was that this parser was based on a similar design pattern to a typical programming language compiler, which keeps track of the current language scope by means of a context stack.I'm sure that the parser already handles scope for it's usual duties, so in large-part this scheme would probably plug in quite nicely,
If indeed this was the case, then the catalog parser would already be aware of the current context/scope as part of it's normal function. (In Celestia catalogs, the current scope would most likely be determined by pushing or popping context elements on/off a context stack (or similar programming construct) on encountering "{" and "}" tokens.
As Andrew explains in the post above, my assumption is clearly incorrect. The Celestia catalog parser is not keeping track of {} block scope. To do so now would require a major rewrite of the parser to implement some sort of context stack, or to quote Andrew: "redesigning the system by which Celestia reads in files".
I think you have maybe misunderstood what I meant by these "scopes".Now serious, that property scope isn't going to help.
Please don't add such a PROPERTY-scope thing.
If it, and it will someday, mess up stuff. Debugging will be very difficult, hard due to how addons are made.
When addon-writers are writing, they are writing files.
Don't forget their workflow.
In this respect, what if there are two conflicting PROPERTY-scope in different files?
....
I am not suggesting these various scopes as any sort of keywords to be added to catalog files. They are merely conceptual elements of a programming paradigm, which I had assumed the parser already implemented.
My comments above have hopefully clarified this, although if you're not familiar with how programming language compilers are designed, then perhaps not.
Scope is referring to "current syntactic scope/context" and would be internally consistent within the parser (if it implemented a context stack, which it doesn't), so there would be no possibility of conflicting scope in different files.
Anyway, this is all moot now, since Andrew's last post:
Given this fact, then I tend to agree with your decision Andrew.ajtribick wrote:Bear in mind that the tokenizer operates on files and converts them to hashes, the parser operates on these hashes. The code to create an elliptical orbit does not see the outer context, all it gets is a hash containing the following key-value pairs
It's a pity the parser isn't already keeping track of language scope -- it's clearly more of a "property collector' than a language parser, however I don't think the effort and risk of making it more sophisticated is warranted for this single feature. There would have to be numerous other benefits to justify the extra work and risk.
Perhaps Chris will think of some.
.Regards
CC
