Some stuff
This commit is contained in:
parent
e01f12721c
commit
0b9efff559
3 changed files with 6 additions and 3 deletions
BIN
build/report.pdf
BIN
build/report.pdf
Binary file not shown.
|
@ -567,7 +567,7 @@ This section contains the definitions of the proposals used to evaluate the tool
|
||||||
The "Pipeline" proposal is one of the proposals presented in Section \ref{sec:proposals}. This proposal is applicable to call expressions, which are used all across JavaScript. This proposal is trying to solve readability when performing deeply nested function calls.
|
The "Pipeline" proposal is one of the proposals presented in Section \ref{sec:proposals}. This proposal is applicable to call expressions, which are used all across JavaScript. This proposal is trying to solve readability when performing deeply nested function calls.
|
||||||
|
|
||||||
|
|
||||||
\begin{lstlisting}[language={JavaScript}, caption={Example of "Pipeline" proposal definition in \DSL}, label={def:pipeline}][H]
|
\begin{lstlisting}[language={JavaScript}, caption={Example of "Pipeline" proposal definition in \DSL}, label={def:pipeline}]
|
||||||
proposal Pipeline {
|
proposal Pipeline {
|
||||||
|
|
||||||
case SingleArgument {
|
case SingleArgument {
|
||||||
|
|
|
@ -167,7 +167,7 @@ To allow the use of Babel~\cite{Babel}, the wildcards present in the \texttt{app
|
||||||
|
|
||||||
To extract the wildcards from the template, we look at each character in the template. If a start token of a wildcard is discovered, which is denoted by \texttt{<<}, everything after that until the closing token, which is denoted by \texttt{>>}, is then treated as an internal DSL variable and will be stored by the tool. A variable \texttt{flag} is used (line 5,10 \ref{lst:extractWildcard}), when the value of flag is false, we know we are currently not inside a wildcard block, this allows us to pass the character through to the variable \texttt{cleanedJS} (line 196 \ref{lst:extractWildcard}). When \texttt{flag} is true, we know we are currently inside a wildcard block and we collect every character of the wildcard block into \texttt{temp}. Once we hit the end of the wildcard block, when we have consumed the entirety of the wildcard, the contents of the \texttt{temp} variable is passed to a tokenizer, then the tokens are parsed by a recursive descent parser (line 10-21 \ref{lst:extractWildcard}).
|
To extract the wildcards from the template, we look at each character in the template. If a start token of a wildcard is discovered, which is denoted by \texttt{<<}, everything after that until the closing token, which is denoted by \texttt{>>}, is then treated as an internal DSL variable and will be stored by the tool. A variable \texttt{flag} is used (line 5,10 \ref{lst:extractWildcard}), when the value of flag is false, we know we are currently not inside a wildcard block, this allows us to pass the character through to the variable \texttt{cleanedJS} (line 196 \ref{lst:extractWildcard}). When \texttt{flag} is true, we know we are currently inside a wildcard block and we collect every character of the wildcard block into \texttt{temp}. Once we hit the end of the wildcard block, when we have consumed the entirety of the wildcard, the contents of the \texttt{temp} variable is passed to a tokenizer, then the tokens are parsed by a recursive descent parser (line 10-21 \ref{lst:extractWildcard}).
|
||||||
|
|
||||||
Once the wildcard is parsed, and we know it is safely a valid wildcard, we insert an identifier into the JavaScript template where the wildcard would reside. This allows for easier identifications of wildcards when performing matching/transformation as we can identify whether or not an Identifier in the code is the same as the identifier for a wildcard. This however, does introduce the problem of collisions between the wildcard identifiers inserted and identifiers present in the users code. To avoid this, the tool adds \texttt{\_\-\-\_} at the beginning of every identifier inserted in place of a wildcard. This allows for easier identification of if an Identifier is a wildcard, and avoids collisions where a variable in the user code has the same name as a wildcard inserted into the template. This can be seen on line 17 of Listing~\ref{lst:extractWildcard}.
|
Once the wildcard is parsed, and we know it is safely a valid wildcard, we insert the identifier into the JavaScript template where the wildcard would reside. This allows for easier identifications of wildcards when performing matching/transformation as we can identify whether or not an Identifier in the code is the same as the identifier for a wildcard. This however, does introduce the problem of collisions between the wildcard identifiers inserted and identifiers present in the users code. To avoid this, the tool adds \texttt{\_\$\$\_} at the beginning and end of every identifier inserted in place of a wildcard. This allows for easier identification of if an Identifier is a wildcard, and avoids collisions where a variable in the user code has the same name as a wildcard inserted into the template. This can be seen on line 17-19 of Listing~\ref{lst:extractWildcard}.
|
||||||
|
|
||||||
\begin{lstlisting}[language={JavaScript}, caption={Extracting wildcard from template.}, label={lst:extractWildcard}]
|
\begin{lstlisting}[language={JavaScript}, caption={Extracting wildcard from template.}, label={lst:extractWildcard}]
|
||||||
export function parseInternal(code: string): InternalParseResult {
|
export function parseInternal(code: string): InternalParseResult {
|
||||||
|
@ -186,7 +186,10 @@ export function parseInternal(code: string): InternalParseResult {
|
||||||
let wildcard = new WildcardParser(
|
let wildcard = new WildcardParser(
|
||||||
new WildcardTokenizer(temp).tokenize()
|
new WildcardTokenizer(temp).tokenize()
|
||||||
).parse();
|
).parse();
|
||||||
cleanedJS += collisionAvoider(wildcard.identifier.name);
|
wildcard.identifier.name =
|
||||||
|
"_$$_" + wildcard.identifier.name + "_$$_";
|
||||||
|
cleanedJS += wildcard.identifier.name;
|
||||||
|
|
||||||
|
|
||||||
prelude.push(wildcard);
|
prelude.push(wildcard);
|
||||||
i += 1;
|
i += 1;
|
||||||
|
|
Loading…
Reference in a new issue