Custom placeholders #107

Virtlink · 2022-01-26T18:05:28Z

This PR adds the ability to change the syntax of placeholders in SDF3.

The configuration option would become:

placeholder {
  prefix = "$"
  suffix = ""
}

Virtlink · 2022-02-03T11:24:36Z

This PR is now ready for review.

Gohla

Thanks! I have some feedback on exceptions and defaults. If those are addressed this can be merged.

Gohla · 2022-02-04T12:31:39Z

lwb/metalang/sdf3/sdf3/src/main/java/mb/sdf3/task/debug/Sdf3ShowSpecParenthesizer.java

+        } catch (NoSuchElementException ex) {
+            return CommandFeedback.of(ShowFeedback.showText("Cannot show parenthesizer; SDF3 was not configured in '" + args.root + "'", getName(args.concrete, args.root)));
+        } catch (Exception ex) {
+            return CommandFeedback.ofTryExtractMessagesFrom(ex, args.root);


Catching all Exceptions is bad practice, as it also catches all RuntimeExceptions indicating bugs such as NullPointerException which should just crash the build, as well as catching InterruptedExceptions which should cancel the build, etc.

Also, I don't think any code here is throwing NoSuchElementException.

AFAICS the old code was handling the exceptions as part of results correctly, so why change it?

NoSuchElementException is thrown by Option.unwrap(). The reason I wrote it like this is because I need both the Sdf3SpecConfig and the Sdf3Config. Using the syntax as you wrote it, it would become something with deep nesting and multiple places of error handing:

return context.require(specConfigFunctionWrapper.get(), args.root).mapOrElse( specConfigOpt -> specConfigOpt.mapOrElse( specConfig -> context.require(configSupplierWrapper.get()).mapOrElse( configOpt -> configOpt.mapOrElse( config -> run(context, specConfig, config, "", args), () -> CommandFeedback.of(ShowFeedback.showText("Cannot show parenthesizer; SDF3 was not configured in '" + args.root + "'", getName(args.concrete, args.root))) ), // TODO: should we propagate configuration errors here? Every task that requires some configuration will // propagate the same configuration errors, which would lead to duplicates. e -> CommandFeedback.ofTryExtractMessagesFrom(e, args.root) ), () -> CommandFeedback.of(ShowFeedback.showText("Cannot show parenthesizer; SDF3 was not configured in '" + args.root + "'", getName(args.concrete, args.root))) ), // TODO: should we propagate configuration errors here? Every task that requires some configuration will // propagate the same configuration errors, which would lead to duplicates. e -> CommandFeedback.ofTryExtractMessagesFrom(e, args.root) );

Or do you have a better suggestion?

If throwing/catching leads to better code, that is fine, as long as you rethrow RuntimeException and InterruptedException when you catch all Exception.

Gohla · 2022-02-04T12:32:10Z

lwb/metalang/sdf3/sdf3/src/main/java/mb/sdf3/task/debug/Sdf3ShowSpecParseTable.java

+            return run(context, specConfig, config, args.strategyAffix, args, name);
+        } catch (NoSuchElementException ex) {
+            return CommandFeedback.of(ShowFeedback.showText("Cannot show parse table; SDF3 was not configured in '" + args.root + "'", name));
+        } catch (Exception ex) {


Catching all Exceptions is bad practice, as it also catches all RuntimeExceptions indicating bugs such as NullPointerException which should just crash the build, as well as catching InterruptedExceptions which should cancel the build, etc.

Also, I don't think any code here is throwing NoSuchElementException.

AFAICS the old code was handling the exceptions as part of results correctly, so why change it?

Gohla · 2022-02-04T12:33:44Z

lwb/metalang/sdf3/sdf3/src/test/java/mb/sdf3/adapter/SpecToParseTableTest.java

@@ -28,9 +30,14 @@ void testTask(boolean createCompletionTable) throws Exception {
        textFile("src/nested/a.sdf3", "module nested/a context-free syntax A.A = <key>");
        textFile("src/nested/b.sdf3", "module nested/b context-free syntax B.B = <word>");
        final Sdf3SpecToParseTable taskDef = component.getSdf3SpecToParseTable();
+        final Sdf3SpecConfig sdf3SpecConfig = specConfig(rootDirectory.getPath());
+        final Sdf3Config sdf3Config = new Sdf3Config("$", "");


Why not call createDefault here, so that tests always test the default?

Gohla · 2022-02-04T12:33:55Z

lwb/metalang/sdf3/sdf3/src/test/java/mb/sdf3/adapter/SpecToParenthesizerTest.java

@@ -17,9 +19,14 @@
    @Test void testTask() throws Exception {
        final FSResource resource = textFile("a.sdf3", "module test context-free syntax A = <A>");
        final Sdf3ParseTableToParenthesizer taskDef = component.getSdf3ParseTableToParenthesizer();
+        final Sdf3SpecConfig sdf3SpecConfig = specConfig(rootDirectory.getPath(), rootDirectory.getPath(), resource.getPath());
+        final Sdf3Config sdf3Config = new Sdf3Config("$", "");


Why not call createDefault here, so that tests always test the default?

Gohla · 2022-02-04T12:34:06Z

lwb/metalang/sdf3/sdf3/src/test/java/mb/sdf3/adapter/ToNormalFormTest.java

@@ -13,9 +15,15 @@
 class ToNormalFormTest extends TestBase {
    @Test void testTask() throws Exception {
        final TextResource resource = textResource("a.sdf3", "module nested/a context-free syntax A = <A>");
+        final Sdf3Config sdf3Config = new Sdf3Config("$", "");


Why not call createDefault here, so that tests always test the default?

Gohla · 2022-02-04T12:34:11Z

lwb/metalang/sdf3/sdf3/src/test/java/mb/sdf3/adapter/ToPrettyPrinterTest.java

@@ -13,9 +15,15 @@
 class ToPrettyPrinterTest extends TestBase {
    @Test void testTask() throws Exception {
        final TextResource resource = textResource("a.sdf3", "module nested/a context-free syntax A = <A>");
+        final Sdf3Config sdf3Config = new Sdf3Config("$", "");


Why not call createDefault here, so that tests always test the default?

Gohla · 2022-02-04T12:36:34Z

lwb/metalang/sdf3/sdf3/src/main/java/mb/sdf3/task/Sdf3AstStrategoTransformTaskDef.java

+                ast = doExec(context, input, strategoRuntime, ast);
+                return Result.ofOk(ast);
+            } catch(Exception e) {
+                return Result.ofErr(e);


Catching all Exceptions is bad practice, as it also catches all RuntimeExceptions indicating bugs such as NullPointerException which should just crash the build, as well as catching InterruptedExceptions which should cancel the build, etc.

Gohla · 2022-02-04T12:37:30Z

lwb/metalang/sdf3/sdf3/src/main/java/mb/sdf3/stratego/Sdf3SslExtPlaceholderCharsPrimitive.java

+            ));
+            return true;
+        } catch(RuntimeException e) {
+            return false; // Context not available; fail


Catching all RuntimeExceptions is bad practice, as it catches all kinds of exceptions indicating bugs such as NullPointerException. This will silently hide them, which is very bad.

This was based on your own code for Sdf3PpLanguageSpecNamePrimitive.

Then that code should be changed as well. I think it should catch AdaptException instead.

Virtlink added 4 commits January 26, 2022 19:00

Add placeholder config option

5d50f41

Extend and use Sdf3Context object

86dc296

Use Sdf3SpecConfig object

25981e9

Add SSL_EXT_placeholder_chars primitive

dd728b9

Virtlink requested a review from Gohla January 26, 2022 18:05

Virtlink added 7 commits January 28, 2022 11:20

Add Sdf3Config object

a706ce4

Use Sdf3Config object

a2e9071

Abstract Sdf3 tranformation tasks

7ad3439

Attempt to refactor Sdf3ToNormalForm

f9f1409

Reimplement Sdf3ShowNormalForm

f378300

Thread Sdf3Config

909b60a

Merge branch 'develop' into custom-placeholders

4072554

Gohla requested changes Feb 4, 2022

View reviewed changes

Virtlink force-pushed the develop branch from b478a01 to ed4101c Compare September 13, 2023 23:16

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Custom placeholders #107

Custom placeholders #107

Virtlink commented Jan 26, 2022

Virtlink commented Feb 3, 2022

Gohla left a comment

Gohla Feb 4, 2022

Virtlink Feb 4, 2022

Gohla Feb 4, 2022

Gohla Feb 4, 2022

Gohla Feb 4, 2022

Gohla Feb 4, 2022

Gohla Feb 4, 2022

Gohla Feb 4, 2022

Gohla Feb 4, 2022

Gohla Feb 4, 2022

Virtlink Feb 4, 2022

Gohla Feb 4, 2022

Custom placeholders #107

Are you sure you want to change the base?

Custom placeholders #107

Conversation

Virtlink commented Jan 26, 2022

Virtlink commented Feb 3, 2022

Gohla left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment