2009/10/26 Mike Samuel <[email protected]>: > 2009/10/26 <[email protected]>: >> On Mon, Oct 26, 2009 at 4:12 PM, Mike Samuel <[email protected]> wrote: >>> Yes, it would be easier. I do a lot of work, storing things on lists, >>> to avoid prematurely creating scopes. >>> There is no small amount of complexity involved in this. But all the >>> complexity is in ScopeAnalyzer. >> >> Hmm.... >> >>> It's also error-prone. See the bug in SyntheticNodeRuleset. >> >> Yablast! I went back and looked at that and ... wow. >> >> Okey dokey pokey.... >> >>> I decided to do that because I didn't want to change the Scope >>> contract in the same CL that I ripped out its guts. >> >> That sounds like a fine idea but, if we can decide to go the "pre >> scope analysis" way, then can we do this right away and plaster the >> current Scope contract on top of it? >> >> Then a subsequent CL (focusing on Rewriters &c.) would disentangle the >> Scope-ness of the current Scope from its use as a dumping container >> for temporary variables and other schleppy nonsense? >> >> And the same, or a yet subsequent, CL (again focusing on Rewriters >> &c.) would refactor to use the new Scope (or whatever it gets called >> in its new incarnation) contract? >> >>>> 2. What are the relative functions of the scope Analyzer, Listener and >>>> Factory? I'm sure the scheme *works* as written; I'm just not clear on >>>> why it is the most natural decomposition. >>> >>> The analyzer embodies all the rules about JavaScript code constructs. >>> >>> Factory allows clients to create their own scope implementation -- it >>> abstracts away implementation constructors. >>> >>> ScopeListener is a bridge between the analyzer and the rest of the >>> system. It abstracts away the job of collecting declaration >>> information from the scope analyzer, allows clients to figure out how >>> they want to channel oddities such as masking/redefinition to message >>> queues, and provides an outlet for usage information. >> >> Fair enough (modulo question #1 and with the caveat that I have only >> taken a brief look). >> >> But so the Analyzer is the one that really contains all the semantics >> of what sorts of things can happen. The Listener contains the list of >> all those semantics that a Scope-interested thingey might want to hear >> about. What then does the Factory do? It seems that, by fixing the >> semantics in Analyzer and Listener, the actual Scopes are simple >> information holders. >> >> So, I suspect Factory is merely an adapter that allows new code to be >> nice and clean while our old rewriters deal with the tired old Scope >> implementation. Is that true? If so, should we comment it as such? > > I don't think so. > You are right that since listeners are typically used to carry the > declarations from the analyzer to the scope implementation that they > could be folded into factory, or vice versa. > > But factories don't really compose they just create objects while > listeners do compose. I could create a multicast listener to allow > multiple listeners -- one that reports errors, one that maps nodes to > scope instances, and one that populates scopes -- all but the last > being generic. > > To really get the scope creation and listener concerns separate, we > would have to change analyzer to create its own intermediate scope > object, since right now, it relies on the scope instance in defSite. > It might be worthwhile to separate that out and then we could > introduce a scopeIntroduced(ScopeType, AncestorChain<?> scopeRoot) > message which would allow the scope creation part to compose.
So I guess the upshot is that you're absolutely right that the distinction is unnecessary, but the current implementation is lacking because ScopeAnalyzer is unnecessarily entangled with the implementation of the scope class. > > >> Ihab >> >> -- >> Ihab A.B. Awad, Palo Alto, CA >> >
