Issue Details (XML | Word | Printable)

Key: BOO-969
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Rodrigo B. de Oliveira
Reporter: Fagim Sadikov
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Boo

Cycle over attribute application and macro expansion until all are applied and expanded (within a fixed limit of iterations)

Created: 19/Feb/08 04:07 AM   Updated: 22/Jan/09 09:22 AM   Resolved: 26/Jun/08 04:15 PM
Return to search
Component/s: Compiler
Affects Version/s: 0.9
Fix Version/s: 0.9

Time Tracking:
Not Specified

File Attachments: 1. Text File ResolveExpressions.cs (3 kB)


Patch Submitted: Yes


 Description  « Hide

I've started to design compile support for DSL that created ActiveRecordRelated classes.
for Example module that contains:

namespace MyProject.Model
import Mediatech.AR.Compile

[Entity] class Bill:
pass
[Entity] class Operation:
pass

rel Operation > Bill as MyBill , lazy

leads to create

1. public abstract class mpmRoot<T>(ActiveRecordBase<T>):
pass
2. piblic interface IBill(IEntityDataPattern): //IEntityDataPattern not discussed here
pass
3... operation too

Bill and Operation clases gets mpmRoot and those interfaces as root....

AND:
"rel" macro leads to create MyBill property with Castle.ActiveRecord.BelongsTo in Operation class and HasMany in Bill class with Lazy and Operations name (deffault name when no "as")....

BUT TO DO IT IT WAS NESSESARY TO REWRITE ONE LINE IN BOO SOURCES:
but default implementation of ResolveExpressions pipeline doesn't allow to do it because all attributes must be binded BEFORE maxroses are expanded...
so i can to define somethig like RelAttribute but it will be not clear because it will be needs to deside to what class of pair your must bind it, it's hardly to read and hardly to manage.

So in my copy of sources i simply double BindAndApplyAttributes step in pipline , inserting second one after ExpandMacro step, recompile it and xcopy it to sharpdevelop - all works fine, no performance issuses, but i catch great ability to define ANY type of nodes from my macro. Before it, in DEFAULT implementation - you can do anything from macro except of attributes - it's not clear i think....

My Suggestion is to update ResolveExpressions step with double BindAndApplyAttributes - before (as it now) and after (as i rewrite) ExpandMacros step - nothing wrong in one hand and macroses became much stronger at another:
52: Add(new BindAndApplyAttributes());

Add(new ExpandMacros());

//SFO : from macro i've generate some stuff with attributes, so i wonna rebind it...
Add(new BindAndApplyAttributes());
///////////////////////////////////////////////////////////////////////////////////

Add(new IntroduceModuleClasses());



Fagim Sadikov added a comment - 19/Feb/08 04:16 AM

some mistakes in post:

NOT: Bill and Operation clases gets mpmRoot and those interfaces as !ROOT!....
YES: Bill and Operation clases gets mpmRoot and those interfaces as Unable to render embedded object: File (base classes, and implementation of some AR properties are provided) not found.

NOT: BUT TO DO IT IT WAS NESSESARY TO REWRITE ONE LINE IN BOO SOURCES:
!BUT! default implementation.......
YES: BUT TO DO IT IT WAS NESSESARY TO REWRITE ONE LINE IN BOO SOURCES:
!the! default implementation.......

NOT:My Suggestion is to update ResolveExpressions !STEP!
YES:My Suggestion is to update ResolveExpressions Unable to render embedded object: File (pipeline) not found.


Greg Nagel added a comment - 24/Jun/08 02:34 PM

I ran into this issue, too. What happens is Boo fully resolves attributes before macros are expanded. If you apply an attribute (even a normal one) within a macro, you get an error saying that it doesn't understand the attribute with a cryptic message.

My fix (for normal attributes) was to manually go in and set the attribute entity myself. A better way to deal with it might be as Fagim says and just applying attributes a second time.

However, if you want to support mutually recursive attributes and macros, it would be better to cycle through attribute/macro expansion until some depth limit is reached or no more attributes/macros are found. Attributes already do this on their own, but I might prefer it if both were cycled over.


Rodrigo B. de Oliveira made changes - 24/Jun/08 04:49 PM
Field Original Value New Value
Assignee Rodrigo B. de Oliveira [ bamboo ]
Rodrigo B. de Oliveira added a comment - 24/Jun/08 04:50 PM

Cycling over both makes sense.


Rodrigo B. de Oliveira made changes - 26/Jun/08 04:13 PM
Summary It's very good and safe operation to call BindAttributes step twice (second after ExpandMacroStep) Cycle over attribute application and macro expansion until all are applied and expanded (within a fixed limit of iterations)
Rodrigo B. de Oliveira added a comment - 26/Jun/08 04:15 PM

Fixed in the repository.


Rodrigo B. de Oliveira made changes - 26/Jun/08 04:15 PM
Resolution Fixed [ 1 ]
Fix Version/s 0.8.3 [ 13815 ]
Status Open [ 1 ] Closed [ 6 ]
Rodrigo B. de Oliveira made changes - 22/Jan/09 09:22 AM
Affects Version/s 0.9 [ 13816 ]
Fix Version/s 0.8.3 [ 13815 ]
Fix Version/s 0.9 [ 13816 ]