[Pharo-project] 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
On 10 June 2010 13:40, Fernando olivero <oliverof@lu.unisi.ch> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
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 <renggli@gmail.com> wrote:
On 10 June 2010 13:40, Fernando olivero <oliverof@lu.unisi.ch> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
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 <renggli@gmail.com> wrote:
On 10 June 2010 13:40, Fernando olivero <oliverof@lu.unisi.ch> 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 Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 <renggli@gmail.com> wrote:
On 10 June 2010 13:40, Fernando olivero <oliverof@lu.unisi.ch> 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 Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Fernando olivero -
Lukas Renggli -
Stéphane Ducasse