Experiment #3
Experiment #3
Conversation
| * specified tree.</p> | ||
| */ | ||
| /*@Override*/ | ||
| visit(/*@NotNull*/ tree: ParseTree): Result { |
There was a problem hiding this comment.
❓ Could we get away with @NotNull (or @notnull) as a decorator here?
There was a problem hiding this comment.
There is experimental support for decorators. We could define a module that defines dummy decorators and leave them in-place. Is that would you are thinking about?
There was a problem hiding this comment.
💭 It'd be nice to leave them in to start with. We can always pull them out later.
There was a problem hiding this comment.
Easy to change in my script.
|
|
||
| export abstract class AbstractParseTreeVisitor<Result> implements ParseTreeVisitor<Result> { | ||
| /** | ||
| * {@inheritDoc} |
There was a problem hiding this comment.
❓ Is there any specific syntax/semantics for TypeScript documentation comments, or are they just plain text?
There was a problem hiding this comment.
To typescript itself, it's plain text, but I think there are tools for Javadoc like processing...
There was a problem hiding this comment.
There is a special-case for comments starting with /// <reference... , but it's not something you need to worry about just now.
|
|
||
| // ConvertTo-TS run at 2016-10-02T18:54:42.6538504-07:00 | ||
|
|
||
| export abstract class AbstractParseTreeVisitor<Result> implements ParseTreeVisitor<Result> { |
There was a problem hiding this comment.
❓ How would this be imported in another file, considering it's in a "tree" subfolder?
There was a problem hiding this comment.
Probably easier for me to give you and example...
There was a problem hiding this comment.
For code outside the runtime, you would use a non-relative module identifier. E.g.:
import {AbstractParseTreeVisitor} from 'antlr4/tree';
We also have the option to define a façade, by writing something like the index.ts files, that re-exports all public types in a flattened form, so that this could work:
import {AbstractParseTreeVisitor} from 'antlr4';
I think I would prefer the later, but not too strongly.
There was a problem hiding this comment.
Actually the name antlr4 above might be antlr4ts given the current module. We stake-out the ground for a given name by registering it on npmjs.org (as I understand it.).
There was a problem hiding this comment.
I think Eric has already register antlr4.
|
|
||
| // ConvertTo-TS run at 2016-10-02T18:54:42.7458518-07:00 | ||
|
|
||
| export interface ErrorNode extends TerminalNode { |
There was a problem hiding this comment.
❓ In ANTLR, this is essentially a marker interface. Is it possible to perform a type check in TypeScript so you know if an object implements a marker interface, even if it has no members?
There was a problem hiding this comment.
No!. Interfaces in typescript have no existence at runtime. For cases like this we will probably want to change an interface into an abstract class, so that we can use the instanceof operator.
| export interface ParseTree extends SyntaxTree { | ||
| // the following methods narrow the return type; they are not additional methods | ||
| /*@Override*/ | ||
| getParent(): ParseTree; |
There was a problem hiding this comment.
❓ Should this be:
readonly parent: ParseTree;There was a problem hiding this comment.
It could be... I was looking to make the minimum source change necessary, rather than impose TypeScript style on the code, at least at first...
| * in your event methods. | ||
| */ | ||
| export class ParseTreeProperty<V> { | ||
| protected annotations: Map<ParseTree, V> = new IdentityHashMap<ParseTree, V>(); |
There was a problem hiding this comment.
📝 This class is intended to work like a decorator. If I'm not mistaken, in TypeScript we can actually add new properties to an existing object. The annotations field simulates that ability when working in Java (a language that does not support setting new properties on an existing object). If I'm correct regarding the capability of TypeScript, then we can eliminate the annotations field and instead store the values on the objects themselves.
There was a problem hiding this comment.
Yea, sort of, I think. Lots of flexibility in adding properties. I need to understand the use-case for this a bit more to discuss intelligently.
There was a problem hiding this comment.
I use it for adding strongly-typed data to ParserRuleContext instances, e.g. in walkers and visitors, without actually modifying my grammar to force them to appear in generated code. It's really a helper class that's not used by anything in the runtime.
There was a problem hiding this comment.
For more background, it's conceptually derived from ObjectDecorator<T> and ObjectProperty<T> which I created while working on ANTLRWorks 2. I defined various properties which can be assigned to tree nodes during semantic analysis.
| @@ -0,0 +1,14 @@ | |||
| export * from './Tree'; | |||
There was a problem hiding this comment.
❓ So this file is for a person to do the following?
import * from "./tree";
There was a problem hiding this comment.
Almost. You can do
import { Tree } from "./tree";
In typescript you seem to have to explicitly identify each name you want to import.
|
Closing without merge... |
Merge changes from tunnelvisionlabs/antlr4ts
Don't actually merge this, but it might give you an idea what I'm thinking for the conversion process.