Ob extensions to Refactoring engine?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Ob extensions to Refactoring engine?

Fernando olivero
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
Reply | Threaded
Open this post in threaded view
|

Re: Ob extensions to Refactoring engine?

Lukas Renggli
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
Reply | Threaded
Open this post in threaded view
|

Re: Ob extensions to Refactoring engine?

Lukas Renggli
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
Reply | Threaded
Open this post in threaded view
|

Re: Ob extensions to Refactoring engine?

Fernando olivero
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
Reply | Threaded
Open this post in threaded view
|

Re: Ob extensions to Refactoring engine?

Lukas Renggli
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Ob extensions to Refactoring engine?

Stéphane Ducasse
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