From dave at badgers-in-foil.co.uk Sat Aug 9 12:05:18 2008 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Sat, 9 Aug 2008 12:05:18 +0100 Subject: [metaas-dev] MetaAS: parsing/writing indenting issue and super.something issue In-Reply-To: <485FD47E.1070406@digital-freestyle.de> References: <485FD47E.1070406@digital-freestyle.de> Message-ID: <20080809110517.GB9512@badgers-in-foil.co.uk> On Mon, Jun 23, 2008 at 06:51:10PM +0200, Daniel Fischer wrote: > Hi together, > > today I stumbled across MetaAS and found it a very useful project for my > problems. Unfortunately I encountered two problems: > > 1) I use the ActionScriptParser.parse(src) call to parse an existing > ActionsScript file. Then I want to use the > ActionScriptWriter.write(dst) to write the parsed ASCompilationUnit > to a file again. Why? Pretty simple: I want to use the pretty > printing capabilities to do auto indenting on the ActionScript file. > Unfortunately ActionScriptWriter writes the AS code with the same > indentation as the original file was. Can I somehow force it to > "forget" the old indentation? If you dig inside the 'DOM like' abstraction that the published metaas interfaces provide, you will find an underlying abstract syntax tree representation, as generated by the ANTLR-powered compiler that metaas uses. This representation just represents the syntax tree using 'nodes' with a type, and usually some text content. Since metaas does not currently expose an API for control over formatting (and a major design goal of the library was actually to allow format-preserving code transformation), you will have to look at a lower-level solution like the underlying AST for the moment. > 2) The parser fails to parse super.something calls. Regardless of it is > a method call "super.something();" or a property access > "super.something = 42;". As I saw in the archives the problem is > known. Is it already fixed, maybe in SVN Head? Or is there a > workaround? It is not yet fixed, sorry. I got some parser changes somewhat working in my local workspace, but there's no DOM API to expose these expressions. There is a working parser that might allow you to implement pretty printing inside the Flex SDK. I've not looked at the SDK code yet though, so I don't know if this would be easy. ta, dave -- http://david.holroyd.me.uk/ From dave at badgers-in-foil.co.uk Sat Aug 9 13:40:43 2008 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Sat, 9 Aug 2008 13:40:43 +0100 Subject: [metaas-dev] namespaces, ASType.removeMethod(String) In-Reply-To: <5A7D202651A16E4AA67A9A600332713603C251@PHM01.jubilife.local> References: <5A7D202651A16E4AA67A9A600332713603C251@PHM01.jubilife.local> Message-ID: <20080809124043.GC9512@badgers-in-foil.co.uk> Hi, sorry for the delayed reply, On Wed, Jun 25, 2008 at 06:39:15PM -0600, Brian DeCamp wrote: > First, have you looked into using the parser from the SDK? It of course > can parse any AS3 file, but it's not clear to me how to use their > CodeGenerator emitter class, or even that it works. I'm wondering if you > have been down this road. No, but it's a good point! With the SDK being open source these days I should see what's in the new toy-box. Ah, here we go; looks like the parser is hand-crafted... http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/modules/asc/src/java/macromedia/asc/parser/Parser.java ...I'll have to give that a read though to see if it might be usable. > I'm having trouble parsing namespace references with your current ANTLR > grammar, although everything else in metaas seems to work so well I may > just avoid namespaces in my generated code for now. The SDK option seems > too complex for the amount of time I have to spend on codegen frameworks > if this is my only glitch. Namespaces where not something I realised existed when I started working on the API / parser. I've tried to retrofit some support, but there are a load of places were I assumed String parameter/return types in the API, but where AS3 syntax actually allows namspaced values like as3::foo. Oops. Were there specific syntax fragments that caused problems? > Another question I have is regarding ASType.removeMethod(String). It > seems to me that the type signature for this method is insufficient. > Consider the following code: > > public function get foo():String { > return _foo; > } > public function set foo(afoo:String):void { > _foo = afoo; > } > > If I call ASType.removeMethod("foo"), which one gets removed?? I assume > from your JavaDoc comment that modifying the array returned from > ASType.getMethods() will not serve my purpose. A very good point, I didn't spot that! I suppose we need an overridden ASType.removeMethod(String, ASMethod.AccessorRole) variation to take care of this use case, with the current removeMethod(String) variant changed to assume the NORMAL_METHOD case. Or, maybe just remove-by-value, ASType.remove(ASMethod) Hmm, that's probably what I should have done in the first place. I've made a note to look in to this, but if you fancy making the change, I'd be happy to integrate a patch with testcase :) ta, dave -- http://david.holroyd.me.uk/ From brian at blackstonebay.com Sat Aug 9 22:53:58 2008 From: brian at blackstonebay.com (Brian DeCamp) Date: Sat, 9 Aug 2008 15:53:58 -0600 Subject: [metaas-dev] namespaces, ASType.removeMethod(String) In-Reply-To: <20080809124043.GC9512@badgers-in-foil.co.uk> References: <5A7D202651A16E4AA67A9A600332713603C251@PHM01.jubilife.local> <20080809124043.GC9512@badgers-in-foil.co.uk> Message-ID: <5A7D202651A16E4AA67A9A6003327136053614@PHM01.jubilife.local> Hi Dave, I've made a number of edits that I've included in the attached patch file. It's up to you if you want to use them. I overloaded the removeMethod() method to include the AccessorType. I chose the removeMethod(String name, ASMethod.AccessorRole) over the removeMethod(ASMethod method) by-value signature so that it was clear exactly what would be removed. The remove by value would really depend upon how you define equals() for the ASMethod, which is not exactly clear to me. I've also added a number of methods that remove the whitespace in an ASType. This may be useful to the previous question you had. I also had some trouble around differences in the parse tree between a parsed file and a file that was generated from scratch using metaas. For instance, when I create a method, I can set the doc comment for that method, and it shows up as part of the linked list subordinate to the method. However, if you write out that file and parse it back in, the doc comment for the method is a sibling of the method instead of a child. This makes it difficult to remove a method along with it's doc comment (which could be in a couple places), so I had to work around that. I thought I remembered a way to use ANTLR to make it parse doc comments as part of the method tree, but you probably know more about that than I do. I never did anything about namespaces, except remove them from the code I was trying to manage. I did get some good use out of your library. Thanks for putting it out there. You're of course welcome to use anything in my patch. Someday Adobe will really integrate their parser and code generation into Flex Builder similarly to how it is handled in the Java parser/generator, but I hope you continue to maintain metaas until then. Regards, Brian -----Original Message----- From: metaas-dev-bounces at lists.badgers-in-foil.co.uk [mailto:metaas-dev-bounces at lists.badgers-in-foil.co.uk] On Behalf Of David Holroyd Sent: Saturday, August 09, 2008 6:41 AM To: metaas-dev at lists.badgers-in-foil.co.uk Subject: Re: [metaas-dev] namespaces, ASType.removeMethod(String) Hi, sorry for the delayed reply, On Wed, Jun 25, 2008 at 06:39:15PM -0600, Brian DeCamp wrote: > First, have you looked into using the parser from the SDK? It of > course can parse any AS3 file, but it's not clear to me how to use > their CodeGenerator emitter class, or even that it works. I'm > wondering if you have been down this road. No, but it's a good point! With the SDK being open source these days I should see what's in the new toy-box. Ah, here we go; looks like the parser is hand-crafted... http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/modules/asc/sr c/java/macromedia/asc/parser/Parser.java ...I'll have to give that a read though to see if it might be usable. > I'm having trouble parsing namespace references with your current > ANTLR grammar, although everything else in metaas seems to work so > well I may just avoid namespaces in my generated code for now. The SDK > option seems too complex for the amount of time I have to spend on > codegen frameworks if this is my only glitch. Namespaces where not something I realised existed when I started working on the API / parser. I've tried to retrofit some support, but there are a load of places were I assumed String parameter/return types in the API, but where AS3 syntax actually allows namspaced values like as3::foo. Oops. Were there specific syntax fragments that caused problems? > Another question I have is regarding ASType.removeMethod(String). It > seems to me that the type signature for this method is insufficient. > Consider the following code: > > public function get foo():String { > return _foo; > } > public function set foo(afoo:String):void { > _foo = afoo; > } > > If I call ASType.removeMethod("foo"), which one gets removed?? I > assume from your JavaDoc comment that modifying the array returned > from > ASType.getMethods() will not serve my purpose. A very good point, I didn't spot that! I suppose we need an overridden ASType.removeMethod(String, ASMethod.AccessorRole) variation to take care of this use case, with the current removeMethod(String) variant changed to assume the NORMAL_METHOD case. Or, maybe just remove-by-value, ASType.remove(ASMethod) Hmm, that's probably what I should have done in the first place. I've made a note to look in to this, but if you fancy making the change, I'd be happy to integrate a patch with testcase :) ta, dave -- http://david.holroyd.me.uk/ _______________________________________________ metaas-dev mailing list metaas-dev at lists.badgers-in-foil.co.uk http://lists.badgers-in-foil.co.uk/mailman/listinfo/metaas-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: metaas.patch Type: application/octet-stream Size: 22814 bytes Desc: metaas.patch Url : http://lists.badgers-in-foil.co.uk/pipermail/metaas-dev/attachments/20080809/e9155a87/attachment-0001.obj From rflament at laposte.net Thu Aug 28 10:12:51 2008 From: rflament at laposte.net (=?ISO-8859-1?Q?R=E9mi_Flament?=) Date: Thu, 28 Aug 2008 11:12:51 +0200 Subject: [metaas-dev] namespaces, ASType.removeMethod(String) In-Reply-To: <20080809124043.GC9512@badgers-in-foil.co.uk> References: <5A7D202651A16E4AA67A9A600332713603C251@PHM01.jubilife.local> <20080809124043.GC9512@badgers-in-foil.co.uk> Message-ID: <48B66C13.4090400@laposte.net> David, I use metaas-0.8 from your maven repo for my maven report (http://flex-mvn-report.sourceforge.net/) and the license seems not correct in the dependencies report : it says that metaas 0.8 is LGPL instead of Apache License : http://flex-mvn-report.sourceforge.net/dependencies.html Regards, R?mi. David Holroyd a ?crit : > Hi, sorry for the delayed reply, > > On Wed, Jun 25, 2008 at 06:39:15PM -0600, Brian DeCamp wrote: >> First, have you looked into using the parser from the SDK? It of course >> can parse any AS3 file, but it's not clear to me how to use their >> CodeGenerator emitter class, or even that it works. I'm wondering if you >> have been down this road. > > No, but it's a good point! With the SDK being open source these days I > should see what's in the new toy-box. > > Ah, here we go; looks like the parser is hand-crafted... > > http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/modules/asc/src/java/macromedia/asc/parser/Parser.java > > ...I'll have to give that a read though to see if it might be usable. > > >> I'm having trouble parsing namespace references with your current ANTLR >> grammar, although everything else in metaas seems to work so well I may >> just avoid namespaces in my generated code for now. The SDK option seems >> too complex for the amount of time I have to spend on codegen frameworks >> if this is my only glitch. > > Namespaces where not something I realised existed when I started working > on the API / parser. I've tried to retrofit some support, but there are > a load of places were I assumed String parameter/return types in the > API, but where AS3 syntax actually allows namspaced values like > as3::foo. > > Oops. > > Were there specific syntax fragments that caused problems? > > >> Another question I have is regarding ASType.removeMethod(String). It >> seems to me that the type signature for this method is insufficient. >> Consider the following code: >> >> public function get foo():String { >> return _foo; >> } >> public function set foo(afoo:String):void { >> _foo = afoo; >> } >> >> If I call ASType.removeMethod("foo"), which one gets removed?? I assume >> from your JavaDoc comment that modifying the array returned from >> ASType.getMethods() will not serve my purpose. > > A very good point, I didn't spot that! > > I suppose we need an overridden > > ASType.removeMethod(String, ASMethod.AccessorRole) > > variation to take care of this use case, with the current > removeMethod(String) variant changed to assume the NORMAL_METHOD case. > > Or, maybe just remove-by-value, > > ASType.remove(ASMethod) > > Hmm, that's probably what I should have done in the first place. > > I've made a note to look in to this, but if you fancy making the change, > I'd be happy to integrate a patch with testcase :) > > > ta, > dave > From dave at badgers-in-foil.co.uk Thu Aug 28 10:21:39 2008 From: dave at badgers-in-foil.co.uk (dave at badgers-in-foil.co.uk) Date: Thu, 28 Aug 2008 10:21:39 +0100 Subject: [metaas-dev] [SVN metaas] R?\195?\169mi pointed out that the POM still claims LGPL license, rather than Apache References: Message-ID: An HTML attachment was scrubbed... URL: http://lists.badgers-in-foil.co.uk/pipermail/metaas-dev/attachments/20080828/f4b4c6df/attachment.htm