erazor initial macro support

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

erazor initial macro support

Cauê W.
Hey Guys!

I've just made a very quick first try at implementing erazor files with macros. It's here https://github.com/waneck/erazor .

I've added a new erazor.macro.Template class, which you should extend and add the following metadata to the extended class:
  • @:template(" inlined erazor template @someVar ")
  • @:includeTemplate("path/to/erazor/template")

There are some incompatibilities with vanilla erazor that were made in order for it to happen:
  • You will get compile-time errors if types aren't well specified: I think it's more a feature than a bug, but you might run into some trouble when using the for() iterator. It wouldn't be hard to find a way to overcome it, by having a helper function that would convert a dynamic type into an Iterator<Dynamic>. But for now it's been left out.
  • Hash input isn't supported. Because of the effort for strict typing, I don't think it's good to have Hash<> input, but I can be wrong, and it wouldn't be too hard to add it.
If you'd like to see an example, check the test suite at https://github.com/waneck/erazor/blob/master/test/erazor/TestMacro.hx
Position of errors is still very crude. But in order for it to be better, I'd have to change some of the core's source code, which I tried not to mess with for now. : )

Franco (and other users of erazor), please give me directions on stuff you'd like to have it changed!

Cheers!
Cauê

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: erazor initial macro support

clemos
Hi Cauê

This looks totally awesome, I'll definitely give it a try as soon as I can.
I agree with you about Hash input. Typedefs/anonymous structures seem
much more powerful to strict-type template data.

Cheers,
Clément

On Wed, Oct 26, 2011 at 8:27 PM, Cauê Waneck <[hidden email]> wrote:

> Hey Guys!
> I've just made a very quick first try at implementing erazor files with
> macros. It's here https://github.com/waneck/erazor .
> I've added a new erazor.macro.Template class, which you should extend and
> add the following metadata to the extended class:
>
> @:template(" inlined erazor template @someVar ")
> @:includeTemplate("path/to/erazor/template")
>
> There are some incompatibilities with vanilla erazor that were made in order
> for it to happen:
>
> You will get compile-time errors if types aren't well specified: I think
> it's more a feature than a bug, but you might run into some trouble when
> using the for() iterator. It wouldn't be hard to find a way to overcome it,
> by having a helper function that would convert a dynamic type into an
> Iterator<Dynamic>. But for now it's been left out.
> Hash input isn't supported. Because of the effort for strict typing, I don't
> think it's good to have Hash<> input, but I can be wrong, and it wouldn't be
> too hard to add it.
>
> If you'd like to see an example, check the test suite
> at https://github.com/waneck/erazor/blob/master/test/erazor/TestMacro.hx
> Position of errors is still very crude. But in order for it to be better,
> I'd have to change some of the core's source code, which I tried not to mess
> with for now. : )
> Franco (and other users of erazor), please give me directions on stuff you'd
> like to have it changed!
> Cheers!
> Cauê
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: erazor initial macro support

Cauê W.
Hey Clément!

Thanks for the input!

There are some other oddities I forgot to mention:
  • when you call macroTemplate.execute() without any parameters, null will be passed in. In erazor, null was later converted to an empty context, so variables could still be created (e.g. MacroTest4). With macros, it's not so easy to make an empty context, since the type of the variable could be a strongly typed type, like a class, and even by forcing a new dynamic object with a cast, its effects wouldn't be consistent
  • I've just now committed a new version. I had forgot to add my changes to the Parser (to cope with macros EReg limitations), and also I've changed now to consider any capitalized variable as a type, and not add the context var to it. This means it's now possible from macros to call static functions/vars (like Math.PI, or Reflect.field()), and it's even possible to match on enums. I don't know how you feel about this diversion from current erazor behaviour, and I'd love to hear some thoughts about this.

2011/10/26 clemos <[hidden email]>
Hi Cauê

This looks totally awesome, I'll definitely give it a try as soon as I can.
I agree with you about Hash input. Typedefs/anonymous structures seem
much more powerful to strict-type template data.

Cheers,
Clément

On Wed, Oct 26, 2011 at 8:27 PM, Cauê Waneck <[hidden email]> wrote:
> Hey Guys!
> I've just made a very quick first try at implementing erazor files with
> macros. It's here https://github.com/waneck/erazor .
> I've added a new erazor.macro.Template class, which you should extend and
> add the following metadata to the extended class:
>
> @:template(" inlined erazor template @someVar ")
> @:includeTemplate("path/to/erazor/template")
>
> There are some incompatibilities with vanilla erazor that were made in order
> for it to happen:
>
> You will get compile-time errors if types aren't well specified: I think
> it's more a feature than a bug, but you might run into some trouble when
> using the for() iterator. It wouldn't be hard to find a way to overcome it,
> by having a helper function that would convert a dynamic type into an
> Iterator<Dynamic>. But for now it's been left out.
> Hash input isn't supported. Because of the effort for strict typing, I don't
> think it's good to have Hash<> input, but I can be wrong, and it wouldn't be
> too hard to add it.
>
> If you'd like to see an example, check the test suite
> at https://github.com/waneck/erazor/blob/master/test/erazor/TestMacro.hx
> Position of errors is still very crude. But in order for it to be better,
> I'd have to change some of the core's source code, which I tried not to mess
> with for now. : )
> Franco (and other users of erazor), please give me directions on stuff you'd
> like to have it changed!
> Cheers!
> Cauê
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: erazor initial macro support

Franco Ponticelli
I love this project and I have no issues adding stuff seeing where it ends.
It will be perfect to use with UFront and I hope to test it soon.
If you think it is already stable enough I can certainly merge it and release a new version of erazor on haxelib. Just give me the go.

Franco

On Wed, Oct 26, 2011 at 11:33 PM, Cauê Waneck <[hidden email]> wrote:
Hey Clément!

Thanks for the input!

There are some other oddities I forgot to mention:
  • when you call macroTemplate.execute() without any parameters, null will be passed in. In erazor, null was later converted to an empty context, so variables could still be created (e.g. MacroTest4). With macros, it's not so easy to make an empty context, since the type of the variable could be a strongly typed type, like a class, and even by forcing a new dynamic object with a cast, its effects wouldn't be consistent
  • I've just now committed a new version. I had forgot to add my changes to the Parser (to cope with macros EReg limitations), and also I've changed now to consider any capitalized variable as a type, and not add the context var to it. This means it's now possible from macros to call static functions/vars (like Math.PI, or Reflect.field()), and it's even possible to match on enums. I don't know how you feel about this diversion from current erazor behaviour, and I'd love to hear some thoughts about this.

2011/10/26 clemos <[hidden email]>
Hi Cauê

This looks totally awesome, I'll definitely give it a try as soon as I can.
I agree with you about Hash input. Typedefs/anonymous structures seem
much more powerful to strict-type template data.

Cheers,
Clément

On Wed, Oct 26, 2011 at 8:27 PM, Cauê Waneck <[hidden email]> wrote:
> Hey Guys!
> I've just made a very quick first try at implementing erazor files with
> macros. It's here https://github.com/waneck/erazor .
> I've added a new erazor.macro.Template class, which you should extend and
> add the following metadata to the extended class:
>
> @:template(" inlined erazor template @someVar ")
> @:includeTemplate("path/to/erazor/template")
>
> There are some incompatibilities with vanilla erazor that were made in order
> for it to happen:
>
> You will get compile-time errors if types aren't well specified: I think
> it's more a feature than a bug, but you might run into some trouble when
> using the for() iterator. It wouldn't be hard to find a way to overcome it,
> by having a helper function that would convert a dynamic type into an
> Iterator<Dynamic>. But for now it's been left out.
> Hash input isn't supported. Because of the effort for strict typing, I don't
> think it's good to have Hash<> input, but I can be wrong, and it wouldn't be
> too hard to add it.
>
> If you'd like to see an example, check the test suite
> at https://github.com/waneck/erazor/blob/master/test/erazor/TestMacro.hx
> Position of errors is still very crude. But in order for it to be better,
> I'd have to change some of the core's source code, which I tried not to mess
> with for now. : )
> Franco (and other users of erazor), please give me directions on stuff you'd
> like to have it changed!
> Cheers!
> Cauê
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: erazor initial macro support

Cauê W.
Hey Franco!

I'm happy to know that! I think it needs better error position reporting so it can make it to the trunk, I'll add it and then make a pull request. It would be great if you can test it with ufront, so we can have some issues sorted out. From what I've seen at ufront, there's a potential problems with capitalized variable access e.g. Url.something. Passing Url to the context wouldn't work, as the macro would consider that it's a class lookup. What would work is if Url were a real class. Then you either would have to import the Url path from inside the template, with:

var Url = package.of.Url;

or you could just import package.of.Url when you are declaring the template class.

You can see the examples of the ways to import classes at the end of https://github.com/waneck/erazor/blob/master/test/erazor/TestMacro.hx .
What do you think?

Cheers!
Cauê

2011/10/27 Franco Ponticelli <[hidden email]>
I love this project and I have no issues adding stuff seeing where it ends.
It will be perfect to use with UFront and I hope to test it soon.
If you think it is already stable enough I can certainly merge it and release a new version of erazor on haxelib. Just give me the go.

Franco


On Wed, Oct 26, 2011 at 11:33 PM, Cauê Waneck <[hidden email]> wrote:
Hey Clément!

Thanks for the input!

There are some other oddities I forgot to mention:
  • when you call macroTemplate.execute() without any parameters, null will be passed in. In erazor, null was later converted to an empty context, so variables could still be created (e.g. MacroTest4). With macros, it's not so easy to make an empty context, since the type of the variable could be a strongly typed type, like a class, and even by forcing a new dynamic object with a cast, its effects wouldn't be consistent
  • I've just now committed a new version. I had forgot to add my changes to the Parser (to cope with macros EReg limitations), and also I've changed now to consider any capitalized variable as a type, and not add the context var to it. This means it's now possible from macros to call static functions/vars (like Math.PI, or Reflect.field()), and it's even possible to match on enums. I don't know how you feel about this diversion from current erazor behaviour, and I'd love to hear some thoughts about this.

2011/10/26 clemos <[hidden email]>
Hi Cauê

This looks totally awesome, I'll definitely give it a try as soon as I can.
I agree with you about Hash input. Typedefs/anonymous structures seem
much more powerful to strict-type template data.

Cheers,
Clément

On Wed, Oct 26, 2011 at 8:27 PM, Cauê Waneck <[hidden email]> wrote:
> Hey Guys!
> I've just made a very quick first try at implementing erazor files with
> macros. It's here https://github.com/waneck/erazor .
> I've added a new erazor.macro.Template class, which you should extend and
> add the following metadata to the extended class:
>
> @:template(" inlined erazor template @someVar ")
> @:includeTemplate("path/to/erazor/template")
>
> There are some incompatibilities with vanilla erazor that were made in order
> for it to happen:
>
> You will get compile-time errors if types aren't well specified: I think
> it's more a feature than a bug, but you might run into some trouble when
> using the for() iterator. It wouldn't be hard to find a way to overcome it,
> by having a helper function that would convert a dynamic type into an
> Iterator<Dynamic>. But for now it's been left out.
> Hash input isn't supported. Because of the effort for strict typing, I don't
> think it's good to have Hash<> input, but I can be wrong, and it wouldn't be
> too hard to add it.
>
> If you'd like to see an example, check the test suite
> at https://github.com/waneck/erazor/blob/master/test/erazor/TestMacro.hx
> Position of errors is still very crude. But in order for it to be better,
> I'd have to change some of the core's source code, which I tried not to mess
> with for now. : )
> Franco (and other users of erazor), please give me directions on stuff you'd
> like to have it changed!
> Cheers!
> Cauê
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: erazor initial macro support

Franco Ponticelli
Love it ;) ... and I am not much worried about changing stuff in ufront if that is required ... I doubt there are too many projects using it so far ... lack of documentation can be a real burden. Having helpers defined as classes (upper cased) is intended because of the similarity in use but we can certainly figure something out.

Franco

On Thu, Oct 27, 2011 at 4:26 PM, Cauê Waneck <[hidden email]> wrote:
Hey Franco!

I'm happy to know that! I think it needs better error position reporting so it can make it to the trunk, I'll add it and then make a pull request. It would be great if you can test it with ufront, so we can have some issues sorted out. From what I've seen at ufront, there's a potential problems with capitalized variable access e.g. Url.something. Passing Url to the context wouldn't work, as the macro would consider that it's a class lookup. What would work is if Url were a real class. Then you either would have to import the Url path from inside the template, with:

var Url = package.of.Url;

or you could just import package.of.Url when you are declaring the template class.

You can see the examples of the ways to import classes at the end of https://github.com/waneck/erazor/blob/master/test/erazor/TestMacro.hx .
What do you think?

Cheers!
Cauê

2011/10/27 Franco Ponticelli <[hidden email]>
I love this project and I have no issues adding stuff seeing where it ends.
It will be perfect to use with UFront and I hope to test it soon.
If you think it is already stable enough I can certainly merge it and release a new version of erazor on haxelib. Just give me the go.

Franco


On Wed, Oct 26, 2011 at 11:33 PM, Cauê Waneck <[hidden email]> wrote:
Hey Clément!

Thanks for the input!

There are some other oddities I forgot to mention:
  • when you call macroTemplate.execute() without any parameters, null will be passed in. In erazor, null was later converted to an empty context, so variables could still be created (e.g. MacroTest4). With macros, it's not so easy to make an empty context, since the type of the variable could be a strongly typed type, like a class, and even by forcing a new dynamic object with a cast, its effects wouldn't be consistent
  • I've just now committed a new version. I had forgot to add my changes to the Parser (to cope with macros EReg limitations), and also I've changed now to consider any capitalized variable as a type, and not add the context var to it. This means it's now possible from macros to call static functions/vars (like Math.PI, or Reflect.field()), and it's even possible to match on enums. I don't know how you feel about this diversion from current erazor behaviour, and I'd love to hear some thoughts about this.

2011/10/26 clemos <[hidden email]>
Hi Cauê

This looks totally awesome, I'll definitely give it a try as soon as I can.
I agree with you about Hash input. Typedefs/anonymous structures seem
much more powerful to strict-type template data.

Cheers,
Clément

On Wed, Oct 26, 2011 at 8:27 PM, Cauê Waneck <[hidden email]> wrote:
> Hey Guys!
> I've just made a very quick first try at implementing erazor files with
> macros. It's here https://github.com/waneck/erazor .
> I've added a new erazor.macro.Template class, which you should extend and
> add the following metadata to the extended class:
>
> @:template(" inlined erazor template @someVar ")
> @:includeTemplate("path/to/erazor/template")
>
> There are some incompatibilities with vanilla erazor that were made in order
> for it to happen:
>
> You will get compile-time errors if types aren't well specified: I think
> it's more a feature than a bug, but you might run into some trouble when
> using the for() iterator. It wouldn't be hard to find a way to overcome it,
> by having a helper function that would convert a dynamic type into an
> Iterator<Dynamic>. But for now it's been left out.
> Hash input isn't supported. Because of the effort for strict typing, I don't
> think it's good to have Hash<> input, but I can be wrong, and it wouldn't be
> too hard to add it.
>
> If you'd like to see an example, check the test suite
> at https://github.com/waneck/erazor/blob/master/test/erazor/TestMacro.hx
> Position of errors is still very crude. But in order for it to be better,
> I'd have to change some of the core's source code, which I tried not to mess
> with for now. : )
> Franco (and other users of erazor), please give me directions on stuff you'd
> like to have it changed!
> Cheers!
> Cauê
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: erazor initial macro support

Cauê W.
Ok! Great ! : )

I'll polish the code up a little bit and make a pull request.

Cheers!
Cauê

2011/10/27 Franco Ponticelli <[hidden email]>
Love it ;) ... and I am not much worried about changing stuff in ufront if that is required ... I doubt there are too many projects using it so far ... lack of documentation can be a real burden. Having helpers defined as classes (upper cased) is intended because of the similarity in use but we can certainly figure something out.

Franco


On Thu, Oct 27, 2011 at 4:26 PM, Cauê Waneck <[hidden email]> wrote:
Hey Franco!

I'm happy to know that! I think it needs better error position reporting so it can make it to the trunk, I'll add it and then make a pull request. It would be great if you can test it with ufront, so we can have some issues sorted out. From what I've seen at ufront, there's a potential problems with capitalized variable access e.g. Url.something. Passing Url to the context wouldn't work, as the macro would consider that it's a class lookup. What would work is if Url were a real class. Then you either would have to import the Url path from inside the template, with:

var Url = package.of.Url;

or you could just import package.of.Url when you are declaring the template class.

You can see the examples of the ways to import classes at the end of https://github.com/waneck/erazor/blob/master/test/erazor/TestMacro.hx .
What do you think?

Cheers!
Cauê

2011/10/27 Franco Ponticelli <[hidden email]>
I love this project and I have no issues adding stuff seeing where it ends.
It will be perfect to use with UFront and I hope to test it soon.
If you think it is already stable enough I can certainly merge it and release a new version of erazor on haxelib. Just give me the go.

Franco


On Wed, Oct 26, 2011 at 11:33 PM, Cauê Waneck <[hidden email]> wrote:
Hey Clément!

Thanks for the input!

There are some other oddities I forgot to mention:
  • when you call macroTemplate.execute() without any parameters, null will be passed in. In erazor, null was later converted to an empty context, so variables could still be created (e.g. MacroTest4). With macros, it's not so easy to make an empty context, since the type of the variable could be a strongly typed type, like a class, and even by forcing a new dynamic object with a cast, its effects wouldn't be consistent
  • I've just now committed a new version. I had forgot to add my changes to the Parser (to cope with macros EReg limitations), and also I've changed now to consider any capitalized variable as a type, and not add the context var to it. This means it's now possible from macros to call static functions/vars (like Math.PI, or Reflect.field()), and it's even possible to match on enums. I don't know how you feel about this diversion from current erazor behaviour, and I'd love to hear some thoughts about this.

2011/10/26 clemos <[hidden email]>
Hi Cauê

This looks totally awesome, I'll definitely give it a try as soon as I can.
I agree with you about Hash input. Typedefs/anonymous structures seem
much more powerful to strict-type template data.

Cheers,
Clément

On Wed, Oct 26, 2011 at 8:27 PM, Cauê Waneck <[hidden email]> wrote:
> Hey Guys!
> I've just made a very quick first try at implementing erazor files with
> macros. It's here https://github.com/waneck/erazor .
> I've added a new erazor.macro.Template class, which you should extend and
> add the following metadata to the extended class:
>
> @:template(" inlined erazor template @someVar ")
> @:includeTemplate("path/to/erazor/template")
>
> There are some incompatibilities with vanilla erazor that were made in order
> for it to happen:
>
> You will get compile-time errors if types aren't well specified: I think
> it's more a feature than a bug, but you might run into some trouble when
> using the for() iterator. It wouldn't be hard to find a way to overcome it,
> by having a helper function that would convert a dynamic type into an
> Iterator<Dynamic>. But for now it's been left out.
> Hash input isn't supported. Because of the effort for strict typing, I don't
> think it's good to have Hash<> input, but I can be wrong, and it wouldn't be
> too hard to add it.
>
> If you'd like to see an example, check the test suite
> at https://github.com/waneck/erazor/blob/master/test/erazor/TestMacro.hx
> Position of errors is still very crude. But in order for it to be better,
> I'd have to change some of the core's source code, which I tried not to mess
> with for now. : )
> Franco (and other users of erazor), please give me directions on stuff you'd
> like to have it changed!
> Cheers!
> Cauê
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org