Boo

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

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 0.9
  • Fix Version/s: 0.9
  • Component/s: Compiler
  • Labels:
    None
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Description

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());

Activity

Hide
Fagim Sadikov added a comment -

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.

Show
Fagim Sadikov added a comment - 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.
Hide
Greg Nagel added a comment -

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.

Show
Greg Nagel added a comment - 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.
Hide
Rodrigo B. de Oliveira added a comment -

Cycling over both makes sense.

Show
Rodrigo B. de Oliveira added a comment - Cycling over both makes sense.
Hide
Rodrigo B. de Oliveira added a comment -

Fixed in the repository.

Show
Rodrigo B. de Oliveira added a comment - Fixed in the repository.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: