Hi LoliProcessor,
I don’t know if the processing implement the inference like go, python or other languages…
For resolve you question you have to declare list inside the symbols
import java.util.ArrayList;
import java.util.List;
List list = new ArrayList<List>();
Now that you have an answer (it is the partial Java 7/8 preprocessor’s fault)…
Just to confirm – is it that you like the syntactic sugar of not having to repeat the type, or is there something specific you are trying to do that you cannot do with one of the compilable options?
import java.util.List;
List<PVector> list = new ArrayList<PVector>();
// ...or
List list = new ArrayList<PVector>();
// or
List<PVector> list = new ArrayList();
// or
List list = new ArrayList();
Well, is there a documentation about the preprocessor of Processing (ha!) ?
Or is the source code available somewhere?
To answer your question, yes, I do like my sugar syntactical.
I asked the question solely to resolve why Type inference doesn’t seem to work in the Processing editor.
What the preprocessor reads and writes is (largely) documented in the reference – if not, there is some documentation of the compiling process and then it is straight to the preprocessor source, which is in Antlr. So, if the syntax from Java that you are using appears in the Processing reference or examples, then that is Processing. If it doesn’t, then you can always try and see! Processing is mostly documented declaratively, for learners, like a language – “I can do this” – not differentially, “this is an enumeration of the ways I’m different from Java 7 / 8.” For that, there is mainly experience and forum lore (and the source).
If you don’t WANT to write in Processing – an intentionally simplified syntax that primarily targets beginners and artists – then you can still write Java in .java files that are part of a .pde sketch folder. Or, even better, use an Eclipse project instead of PDE and work with the full Processing API, but not the PDE format or compiler – just write it all in 100% Java, with no pde. It seems like that might be what you want…?
Then I guess the Folder of your processing sketch (where the data folder is inside as well) acts as the default package of your module.
But good to know that you can mix .java and .pde files.
For more on how that works in PDE (vs eclipse) also read the two “Advanced” note boxes in the documentation I linked above. You can also subclass PApplet within PDE and do all-java there, but your classes are no longer automatically inner classes, so some of the PDE “just works” magic is gone – passing around PApplet is required. At that point it starts making sense to set up the Processing Eclipse Template instead.
The PDE concatenates all “.pde” files and transpiles them as 1 valid “.java” file wrapped up as 1 PApplet subclass.
But the PDE doesn’t add the keyword package to this unified “.java” file. So it’s kinda “packageless”.
However, we can use the keyword package in our own “.java” files, if we really feel like it:
But even if we do use package in our “.java” files, using import inside our “.pde” files, in order to access those “.java” sketch files, is still optional.
That is, even though I’ve included package gotoloop.countdown; inside “Countdown.java”, that import gotoloop.countdown.Countdown; statement inside “CountdownClass.pde” isn’t really needed at all.
Are you sure about your statement about the import statement not being required.
Using a packaged class without import gives error:
Cannot find a class or type named “class_name”
The decision to change language syntax, as opposed to just structural syntax, is probably the worst decision Processing made. It’s what makes adopting Java 7/8 features like this more difficult, and ends up with Java syntax actually being the simpler one. Maybe with Java 11 (and additional type inference like var) it would be good to either remove the bulk of the preprocessor, or provide an alternative mode?
For comparison, PraxisLIVE uses Java basic syntax, but the same basic structural wrapping (import, class body, etc.) as Processing using preprocessing code from Janino that has most of the same benefits with less code, and handles Java language updates without problem.
Ru sure that’s valid Java syntax? I’ve made the attempt code below in order to check that out:
import java.util.List;
import java.util.ArrayList;
public class Test {
public final List<? extends Double> list = new ArrayList<>();
public final Double d = Math.random();
public Test() {
//list.add(d); // uncomment this for "capture" bug!
}
@Override public String toString() {
return "" + d;
}
@SafeVarargs public static final void main(final String... args) {
System.out.println(new Test());
}
}
And here’s the error log if we uncomment list.add(d); inside Test’s constructor:
/tmp/java_3Bq5e5/Test.java:9: error: no suitable method found for add(Double)
list.add(d); // uncomment this for bug!
^
method Collection.add(CAP#1) is not applicable
(argument mismatch; Double cannot be converted to CAP#1)
method List.add(CAP#1) is not applicable
(argument mismatch; Double cannot be converted to CAP#1)
where CAP#1 is a fresh type-variable:
