RFE: extend SSR to be able to import Netbeans Jackpot rules

Today I saw the announcement for NB Jackpot project and my first thought
was that it looks a lot like SSR. It would be nice if JetBrains or 3rd
party implements an importer for Jackpot rule files and some decent way
to manage a bunch of stored SSR search/replaces (perhaps giving a
facelift to the Migrate refactoring?)


http://jackpot.netbeans.org/index.html

8 comments

From my small investigation it seems Jackpot is more complex and
powerful than SSR, and most Jackpot rules could not be SSR's. But I
could be wrong.

dimitar wrote:

Today I saw the announcement for NB Jackpot project and my first thought
was that it looks a lot like SSR. It would be nice if JetBrains or 3rd
party implements an importer for Jackpot rule files and some decent way
to manage a bunch of stored SSR search/replaces (perhaps giving a
facelift to the Migrate refactoring?)


http://jackpot.netbeans.org/index.html

0

Jackpot is a good deal more expressive than SSR is currently, and I've got to say I like the syntax better. That said, creating a JackPot engine on top of the PSI should be no more than moderately difficult for a third-party plugin. Both batch execution and JackPot based inspections look pretty doable.

--Dave Griffith

0

After looking on several examples and Rules language I doubt Jackpot is
significantly more powerful given that following rule is directly
mappable to SSR:
$a.getSize().width => $a.getWidth() :: $a instanceof java.awt.Component;
and most of examples are consisted of such rules

So far (aside compact rewrite syntax) I see several different predicates
(conditions on variables) and list of transformations applied at once.

Keith Lea wrote:

From my small investigation it seems Jackpot is more complex and
powerful than SSR, and most Jackpot rules could not be SSR's. But I
could be wrong.

dimitar wrote:

>> Today I saw the announcement for NB Jackpot project and my first
>> thought was that it looks a lot like SSR. It would be nice if
>> JetBrains or 3rd party implements an importer for Jackpot rule files
>> and some decent way to manage a bunch of stored SSR search/replaces
>> (perhaps giving a facelift to the Migrate refactoring?)
>>
>>
>> http://jackpot.netbeans.org/index.html


--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

In fact SSR contains language to write one pattern with constraints in
one string, like
'a:[expr_type( java.awt.Component )].getSize().width => 'a.getWidth(),
with configuration screens we wanted just more ease and ability to check
and provide more assistance to user. But different syntax require even
more time to grasp and use effectively :-)...


Dave Griffith wrote:

Jackpot is a good deal more expressive than SSR is currently, and I've got to say I like the syntax better. That said, creating a JackPot engine on top of the PSI should be no more than moderately difficult for a third-party plugin. Both batch execution and JackPot based inspections look pretty doable.

--Dave Griffith



--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

Maxim Mossienko (JetBrains) wrote:

In fact SSR contains language to write one pattern with constraints in
one string, like
'a:[expr_type( java.awt.Component )].getSize().width => 'a.getWidth(),
with configuration screens we wanted just more ease and ability to check
and provide more assistance to user. But different syntax require even
more time to grasp and use effectively :-)...


Is this documented somewhere?

0

In tests and there is research paper on this (to be published).
Basically, 't means meta variable that could have constraints attached
with :[conditionals terms], one also can add regular expression
qualifiers like: 'statement+ or 'statement{1,2}


Keith Lea wrote:

Maxim Mossienko (JetBrains) wrote:

>> In fact SSR contains language to write one pattern with constraints in
>> one string, like
>> 'a:[expr_type( java.awt.Component )].getSize().width => 'a.getWidth(),
>> with configuration screens we wanted just more ease and ability to
>> check and provide more assistance to user. But different syntax
>> require even
>> more time to grasp and use effectively :-)...
>>


Is this documented somewhere?


--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

It seems that there is no possibility to modify classes using Jackpot
Rules language, just API migration on expression,statement level.

Maxim Mossienko (JetBrains) wrote:

After looking on several examples and Rules language I doubt Jackpot is
significantly more powerful given that following rule is directly
mappable to SSR:
$a.getSize().width => $a.getWidth() :: $a instanceof java.awt.Component;
and most of examples are consisted of such rules

So far (aside compact rewrite syntax) I see several different predicates
(conditions on variables) and list of transformations applied at once.

Keith Lea wrote:

>> From my small investigation it seems Jackpot is more complex and
>> powerful than SSR, and most Jackpot rules could not be SSR's. But I
>> could be wrong.
>>
>> dimitar wrote:
>>
>>> Today I saw the announcement for NB Jackpot project and my first
>>> thought was that it looks a lot like SSR. It would be nice if
>>> JetBrains or 3rd party implements an importer for Jackpot rule files
>>> and some decent way to manage a bunch of stored SSR search/replaces
>>> (perhaps giving a facelift to the Migrate refactoring?)
>>>
>>>
>>> http://jackpot.netbeans.org/index.html




--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

Maybe you could publish draft of the paper?

Maxim Mossienko (JetBrains) wrote:

In tests and there is research paper on this (to be published).
Basically, 't means meta variable that could have constraints attached
with :[conditionals terms], one also can add regular expression
qualifiers like: 'statement+ or 'statement{1,2}


Keith Lea wrote:

>> Maxim Mossienko (JetBrains) wrote:
>>
>>> In fact SSR contains language to write one pattern with constraints
>>> in one string, like
>>> 'a:[expr_type( java.awt.Component )].getSize().width => 'a.getWidth(),
>>> with configuration screens we wanted just more ease and ability to
>>> check and provide more assistance to user. But different syntax
>>> require even
>>> more time to grasp and use effectively :-)...
>>>
>>
>> Is this documented somewhere?

0

Please sign in to leave a comment.