Bug 439513 - Template Grammar Requirements
Summary: Template Grammar Requirements
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Recommenders.incubator (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows NT
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Stefan Prisca CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-14 05:01 EDT by Stefan Prisca CLA
Modified: 2019-07-24 14:36 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Prisca CLA 2014-07-14 05:01:39 EDT
I created a list of all possible combinations of template keywords/variables/etc.
If I missed any, feel free to add them in the comments.

I think we should select from the list what we allow in each rule, and then make the necessary changes in the grammar.



(1) Possible template identifiers:

-> Simple Variables? (+ see section on Simple Variables)
	e.g. array, collection, etc
	 ${array:localVar('java.lang.Object[]')}
	 ${collection:localVar(java.util.Collection)}
-> Full variable keywords?
	e.g. newName, newType
	${newName:localVar('java.lang.Object[]')}
	 ${newType:localVar(java.util.Collection)}
-> Java keywords?
	e.g. for, while, class, abstract?
	${class:newName(enclosing_type)}
-> Other Java Identifiers that are not template keywords (random IDs)
	e.g.: someId
		${someId:newType(String)}



(2) Possible Template Types:

-> Qualified Names?(+see the section on qualified names)
	e.g. java.io.File in < ${id:field(java.io.File)} >
-> Primitive Types?
	e.g. int, double in < ${id:field(int, double)} >
-> Special Types ?
	e.g. collection, array, iterable in < ${id:field(collection, array, iterable)} > 
-> Single Quoted Strings?
	e.g. 'java.lang.Object[]'  in < ${container:var('java.lang.Object[]')} >



(3) Possible Template Simple Variables:
-> All variables specified in the eclipse specification at http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Fconcepts%2Fconcept-template-variables.htm
-> Template Identifiers that are not simple variables (see the above section)?



(4) Possible Link Variable Proposals:
->  Qualified Names?(+see the section on qualified names)
	e.g. java.lang.Object in < ${l:link(java.lang.Object)} >
-> Numeric Literals? (both integer and float)
	e.g. 10, 0.2e-12 in < ${l:link(10, 0.2e-12)} >
-> Boolean Literals? 
	e.g. true, false in < ${l:link(true, false)} >
-> Null Literal?
	e.g. null in < ${l:link(null)} >
-> Single Quoted String?
	e.g. 'java.lang.Object[]'  in < ${l:link('java.lang.Object[]')} >



(5) Possible Qualified Names:
-> Random Identifiers (IDs)?
	e.g. java.lang.Object
-> Template Identifiers? (+ see section on template identifiers above)
	e.g. newName.collection
-> Simple Variables? (+ see section on simple variables)
	e.g. collection.array
-> Primitive types? (NOT ALLOWED IN JAVA)
	e.g. int.double
-> Java Keywords? (NOT ALLOWED IN JAVA)
	e.g. class.abstract
Comment 1 Stefan Prisca CLA 2014-07-14 05:12:05 EDT
As a first comment, IMHO Java Keywords should not be allowed as Template Identifiers.
Template Identifiers should also be valid Java Identifiers.

I also created a Google Doc for this[1]. It will allow us to better track the decisions with inline comments and other text editing features.

[1]: https://docs.google.com/document/d/1rxVwSpRg_4tmEtyZ_ZCL0WEa6Kl83UooQCm0xdLLrZE/edit?usp=sharing
Comment 2 Stefan Prisca CLA 2014-07-14 06:01:53 EDT
(5) Possible Qualified Names:
-> Random Identifiers (IDs)?
	e.g. java.lang.Object
-> Template Identifiers? (+ see section on template identifiers above)
	e.g. newName.collection
-> Simple Variables? (+ see section on simple variables)
	e.g. collection.array
-> Primitive types? (NOT ALLOWED IN JAVA)
	e.g. int.double
-> Java Keywords? (NOT ALLOWED IN JAVA)
	e.g. class.abstract

I misunderstood bug [1]. Qualified Names were suppose to contain Java Identifiers, not Template Identifiers. My mistake, sorry.
This simplifies things a bit:

(5) Possible Qualified Names:
-> Java Identifiers (IDs)
	e.g. java.lang.Object or org.example.collection

Now we won't have to worry about primitive types and other java keywords in qualified names.


But I am still confused if we should allow Java Keywords, Primitive Types or Simple Variables Keywords as Template Identifiers?


[1]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=439046
Comment 3 Andreas Sewe CLA 2014-07-14 06:08:01 EDT
(In reply to Stefan Prisca from comment #2)
> But I am still confused if we should allow Java Keywords, Primitive Types or
> Simple Variables Keywords as Template Identifiers?

I think both Java Keywords and Primitive Types (which are Java Keywords, after all) are allowed (but please double-check with JDT)

  ${int:var(java.lang.Integer)}

Simple variable names like "array" IMHO don't make sense as you cannot reference them again.

Maybe you could write

  ${array:newType(java.util.ArrayList)}

but you could not reference it through

  ${array}

But again, please double check. Just because something doesn't make sene does not mean that it is not allowed by the reference implementation. If it is, we should allow it, too.
Comment 4 Stefan Prisca CLA 2014-07-14 07:06:53 EDT
>But again, please double check.

I made a table with the Grammar Rules / Possible contents / Examples / Allowed by JDT / Allowed by Snipmatch Template Editor.

All that the default Eclipse Template Editor allows, our editor allows too, and all that it restricts our editor restricts too.

There is only one problem (from what I've seen): the Eclipse Template Editor gives an error for "${l:link(10, 0.2e-12)}", but allows "${l:link(10, 0.2e12)}". Our editor allows them both.

You can see this in the table from the Google Doc
<https://docs.google.com/document/d/1rxVwSpRg_4tmEtyZ_ZCL0WEa6Kl83UooQCm0xdLLrZE/edit>
Comment 5 Andreas Sewe CLA 2014-07-14 08:12:46 EDT
(In reply to Stefan Prisca from comment #4)
> >But again, please double check.
> 
> I made a table with the Grammar Rules / Possible contents / Examples /
> Allowed by JDT / Allowed by Snipmatch Template Editor.
> 
> All that the default Eclipse Template Editor allows, our editor allows too,
> and all that it restricts our editor restricts too.
> 
> There is only one problem (from what I've seen): the Eclipse Template Editor
> gives an error for "${l:link(10, 0.2e-12)}", but allows "${l:link(10,
> 0.2e12)}". Our editor allows them both.

This looks like a Bug with JDT. Does the link work when you insert a snippet, even if their editor complains about the snippet? If so, care to file a but with JDT? 

Maybe we need an additional column "allowed by JDT snippet completion". Sounds reasonable?

> You can see this in the table from the Google Doc
> <https://docs.google.com/document/d/
> 1rxVwSpRg_4tmEtyZ_ZCL0WEa6Kl83UooQCm0xdLLrZE/edit>

Great job.
Comment 6 Stefan Prisca CLA 2014-07-14 10:04:53 EDT
>Does the link work when you insert a snippet, even if their editor complains about the snippet?

I cannot save a template if it has an error in the editor.
Comment 7 Andreas Sewe CLA 2014-07-14 10:39:11 EDT
(In reply to Stefan Prisca from comment #6)
> >Does the link work when you insert a snippet, even if their editor complains about the snippet?
> 
> I cannot save a template if it has an error in the editor.

OK, then at least try that using the Snipmatch editor (which doesn't prevent incorrect stuff from being saved). Snipmatch then simply doesn't insert the snippet in question (or doesn't even show it in the search box).
Comment 8 Stefan Prisca CLA 2014-07-14 11:20:27 EDT
I've tried it using Snipmatch.
When the snippet source is "${l:link(10, 0.2e-12)}", it won't appear in the list.
But when I modify the source to "${l:link(10, 0.2e12)}" it appears.

I will file a bug to JDT about this.
Comment 9 Stefan Prisca CLA 2014-07-15 05:54:59 EDT
You can follow up on the bug submitted to JDT here:
< https://bugs.eclipse.org/bugs/show_bug.cgi?id=439593 >
Comment 10 Stefan Prisca CLA 2014-07-16 04:21:24 EDT
>Maybe we need an additional column "allowed by JDT snippet completion". Sounds reasonable?

I don't think that this would be required.
From what I've seen all templates that are allowed by the editor are allowed by the completion. If this is true, there is no point in having 2 columns for the same thing.:-)