Bugzilla – Full Text Bug Listing
| Summary: | [EOL] Allow per-resource global variables | ||
|---|---|---|---|
| Product: | [Modeling] Epsilon | Reporter: | Louis Rose <louis> |
| Component: | Core | Assignee: | Antonio Garcia-Dominguez <agarcdomi> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | dkolovos |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=347016 | ||
| Whiteboard: | interim | ||
|
Description
Louis Rose
We have decided to target the first stable release after moving to EMFT for this fix. There may be some unit tests that can be re-used in EglFrameStackMangerTests. In case we need a reminder of a possible solution, from Antonio's email: If I have understood your code correctly, you shuffle snapshots of the stack frame for global variables into a stack as you call the main template and its subtemplates. I think we could fix this issue in a more general fashion, just by changing the lookup logic a little in FrameStack. The main problem now is that all variables available in a protected stack frame must be either directly inside it or in the bottom stack frame. I suggest that we allow for several unprotected stack frames at the bottom of the stack, and start the global lookup from the topmost unprotected stack frame. We'd need to add an attribute referencing the topmost contiguous unprotected stack frame in the FrameStack, and start global lookups from there. Suppose we had this stack frame, from bottom to top: 1. unprotected stack frame with System and null 2. unprotected stack frame with out (main template) and x 3. unprotected stack frame with out (subtemplate) and y 4. protected stack frame from calling f() 5. protected stack frame from calling g() The topmost unprotected stack frame is 3. f() can access x, y, System, null and the copy of out which relates to the subtemplate. Same with g(). Note that the copy of out relating to the main template is "shadowed" here, as lookups start from 3. This way, we only keep one stack, the usual stack frame. We'd need to add a new attribute with the topmost unprotected stack frame, though. This shouldn't affect most E*L languages, as they are fine with one unprotected stack frame keeping all the global variables, but it would benefit EGL and perhaps EUnit. Right now all tests go through all data bindings, but they might not in the future. Have the recent changes to FrameStack and Frame perhaps addressed these issues? Louis and I already switched EGL to the new FrameStack implementation. EUnit doesn't use it yet, though: I'll adapt it now so we can close this bug. Done: EUnit also uses the new support for multiple global stack frames now (SVN r1908). I think we can mark this bug as fixed now :-). Thanks Antonio. I'm glad to see the back of this bug, although I did enjoy working together with you on this one! This has been fixed in the latest interim version. Fixed in 1.0 |