Ob extensions to Refactoring engine?
Locked
Ob extensions to Refactoring engine?
 
|
Lukas do you think it would worth it to change the category of several methods, from extensions to OB to the refactoring engine itself.
For example in my case i don't need OB at all, but are forced to load just because this extensions are goodies i've need when using the refactoring engine. For example BrowserEnvironment>>allNonMetaClasses from the category *ob-refactory-accessing Maybe it's an sign that these belong to the refactoring engine package, the model, and not Ob, the view. What do you think? Fernando _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Ob extensions to Refactoring engine?
|
|
On 10 June 2010 13:40, Fernando olivero <[hidden email]> wrote:
> Lukas do you think it would worth it to change the category of several methods, from extensions to OB to the refactoring engine itself. > > For example in my case i don't need OB at all, but are forced to load just because this extensions are goodies i've need when using the refactoring engine. > > For example > > BrowserEnvironment>>allNonMetaClasses > > from the category *ob-refactory-accessing > > Maybe it's an sign that these belong to the refactoring engine package, the model, and not Ob, the view. > > What do you think? Yeah, that makes sense. We just have to write tests for them in the refactoring tests. Lukas > > Fernando > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Ob extensions to Refactoring engine?
|
|
Let me know if there is other code that needs to be moved.
Lukas Name: Refactoring-Core-lr.143 Author: lr Time: 10 June 2010, 3:34:12 pm UUID: 91014fcc-aa9f-4590-a22c-f8a1a0a5daa1 Ancestors: Refactoring-Core-lr.142 - moved some code from OB-Refactory Name: Refactoring-Tests-Core-lr.44 Author: lr Time: 10 June 2010, 3:34:37 pm UUID: 35e845c2-d58e-4b76-a1b7-bcec35761870 Ancestors: Refactoring-Tests-Core-lr.43 - moved some code from OB-Refactory Name: OB-Refactory-lr.214 Author: lr Time: 10 June 2010, 3:35:01 pm UUID: 70a76d23-ab08-450f-88c0-556b70666ed0 Ancestors: OB-Refactory-lr.213 - moved some code to Refactoring-Core On 10 June 2010 15:13, Lukas Renggli <[hidden email]> wrote: > On 10 June 2010 13:40, Fernando olivero <[hidden email]> wrote: >> Lukas do you think it would worth it to change the category of several methods, from extensions to OB to the refactoring engine itself. >> >> For example in my case i don't need OB at all, but are forced to load just because this extensions are goodies i've need when using the refactoring engine. >> >> For example >> >> BrowserEnvironment>>allNonMetaClasses >> >> from the category *ob-refactory-accessing >> >> Maybe it's an sign that these belong to the refactoring engine package, the model, and not Ob, the view. >> >> What do you think? > > Yeah, that makes sense. We just have to write tests for them in the > refactoring tests. > > Lukas > > >> >> Fernando >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Ob extensions to Refactoring engine?
|
|
Great Lukas, thank you! I would like to minimize the preconditions of Gaucho.
To continue in that front, since i'm using NewTextMorph , i would like to remove also the dependency to SHOUT. To continue in this front , is was thinking to get rid of the SHOUT parser and styler by reusing the already present RB, by subclassing the already present RBProgramNodeVisitor, such as RBFormatter, in order to implement a RBCodeStyler. Are you aware if this has been done already? If i'll implement it and publish it. Fernando pd: Will let you know when i run into other methods to i think need to be moved. On Jun 10, 2010, at 3:35 PM, Lukas Renggli wrote: > Let me know if there is other code that needs to be moved. > > Lukas > > Name: Refactoring-Core-lr.143 > Author: lr > Time: 10 June 2010, 3:34:12 pm > UUID: 91014fcc-aa9f-4590-a22c-f8a1a0a5daa1 > Ancestors: Refactoring-Core-lr.142 > > - moved some code from OB-Refactory > > Name: Refactoring-Tests-Core-lr.44 > Author: lr > Time: 10 June 2010, 3:34:37 pm > UUID: 35e845c2-d58e-4b76-a1b7-bcec35761870 > Ancestors: Refactoring-Tests-Core-lr.43 > > - moved some code from OB-Refactory > > Name: OB-Refactory-lr.214 > Author: lr > Time: 10 June 2010, 3:35:01 pm > UUID: 70a76d23-ab08-450f-88c0-556b70666ed0 > Ancestors: OB-Refactory-lr.213 > > - moved some code to Refactoring-Core > > On 10 June 2010 15:13, Lukas Renggli <[hidden email]> wrote: >> On 10 June 2010 13:40, Fernando olivero <[hidden email]> wrote: >>> Lukas do you think it would worth it to change the category of several methods, from extensions to OB to the refactoring engine itself. >>> >>> For example in my case i don't need OB at all, but are forced to load just because this extensions are goodies i've need when using the refactoring engine. >>> >>> For example >>> >>> BrowserEnvironment>>allNonMetaClasses >>> >>> from the category *ob-refactory-accessing >>> >>> Maybe it's an sign that these belong to the refactoring engine package, the model, and not Ob, the view. >>> >>> What do you think? >> >> Yeah, that makes sense. We just have to write tests for them in the >> refactoring tests. >> >> Lukas >> >> >>> >>> Fernando >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Ob extensions to Refactoring engine?
|
|
> To continue in that front, since i'm using NewTextMorph , i would like to remove also the dependency to SHOUT.
> > To continue in this front , is was thinking to get rid of the SHOUT parser and styler by reusing the already present RB, by subclassing the already present RBProgramNodeVisitor, such as RBFormatter, in order to implement a RBCodeStyler. > > Are you aware if this has been done already? If i'll implement it and publish it. Not that I know. That's certainly a good idea, however I am not sure if RB can help you to highlight. RBParser stops parsing when there is an error, something you don't want to do when highlighting. Also for highlighting you typically are not able/do not want to build an AST beforehand, so RBProgramNodeVisitor is kind of useless. AFAIK in VW the RBHighlighter is implemented as a completely new parser. In Helvetia I use a PetitParser grammar that I "subclasses" to build an AST identical to the RBParser. For syntax highlighting I take the first-class Smalltalk grammar and programmatically transform it to be less strict about errors. Furthermore I attach actions that add the formatting to the parsed text as a side-effect. This is sketched in Section 3.4 of our DYLA 2010 paper: http://bergel.eu/download/Dyla2010/dyla10_submission_4.pdf. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Ob extensions to Refactoring engine?
|
|
In reply to this post by Fernando olivero
why shout does not suit you for color highlighting?
When I see RB on VW I think that shout is really much better. Stef On Jun 10, 2010, at 4:19 PM, Fernando olivero wrote: > Great Lukas, thank you! I would like to minimize the preconditions of Gaucho. > > To continue in that front, since i'm using NewTextMorph , i would like to remove also the dependency to SHOUT. > > To continue in this front , is was thinking to get rid of the SHOUT parser and styler by reusing the already present RB, by subclassing the already present RBProgramNodeVisitor, such as RBFormatter, in order to implement a RBCodeStyler. > > Are you aware if this has been done already? If i'll implement it and publish it. > > > Fernando > > pd: Will let you know when i run into other methods to i think need to be moved. > > > > On Jun 10, 2010, at 3:35 PM, Lukas Renggli wrote: > >> Let me know if there is other code that needs to be moved. >> >> Lukas >> >> Name: Refactoring-Core-lr.143 >> Author: lr >> Time: 10 June 2010, 3:34:12 pm >> UUID: 91014fcc-aa9f-4590-a22c-f8a1a0a5daa1 >> Ancestors: Refactoring-Core-lr.142 >> >> - moved some code from OB-Refactory >> >> Name: Refactoring-Tests-Core-lr.44 >> Author: lr >> Time: 10 June 2010, 3:34:37 pm >> UUID: 35e845c2-d58e-4b76-a1b7-bcec35761870 >> Ancestors: Refactoring-Tests-Core-lr.43 >> >> - moved some code from OB-Refactory >> >> Name: OB-Refactory-lr.214 >> Author: lr >> Time: 10 June 2010, 3:35:01 pm >> UUID: 70a76d23-ab08-450f-88c0-556b70666ed0 >> Ancestors: OB-Refactory-lr.213 >> >> - moved some code to Refactoring-Core >> >> On 10 June 2010 15:13, Lukas Renggli <[hidden email]> wrote: >>> On 10 June 2010 13:40, Fernando olivero <[hidden email]> wrote: >>>> Lukas do you think it would worth it to change the category of several methods, from extensions to OB to the refactoring engine itself. >>>> >>>> For example in my case i don't need OB at all, but are forced to load just because this extensions are goodies i've need when using the refactoring engine. >>>> >>>> For example >>>> >>>> BrowserEnvironment>>allNonMetaClasses >>>> >>>> from the category *ob-refactory-accessing >>>> >>>> Maybe it's an sign that these belong to the refactoring engine package, the model, and not Ob, the view. >>>> >>>> What do you think? >>> >>> Yeah, that makes sense. We just have to write tests for them in the >>> refactoring tests. >>> >>> Lukas >>> >>> >>>> >>>> Fernando >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |