Community
Participate
Working Groups
We need this to run the JvmModelGenerator correctly.
Hmmm, thinking again, the final modifier cannot be extracted from parameters in binary class files, so it might lead to inconsistencies. Alternatively, we could always generate final parameters in the JvmModelGenerator. Opinions?
+1 for always using final for parameters. The validation treats them as final anyway.
I'll close this one as won't fix since I don't see a way to populate #isFinal from the reflection layer.
Could it still be worthwhile to add isFinal/setFinal in JvmFormalParameter to allow for custom implementations in languages that use Xbase? The default value could be set to true, and the parts in the validator/generator could check isFinal (so the existing languages won't break). I'm asking because in one of my DSL I had to consider parameters as non final by default, and since there's no way to store such information in the model, I had to redefine entire methods (both in the validator and JvmModelGenerator) just to deal with them. Not to mention having a custom implementation of JvmFormalParameter to store the final/nonfinal feature. In case, I can try to provide a patch.
(In reply to Lorenzo Bettini from comment #4) > I'm asking because in one of my DSL I had to consider parameters as non > final by default Could you please outline the use case for writable parameters?
(In reply to Sebastian Zarnekow from comment #5) > (In reply to Lorenzo Bettini from comment #4) > > I'm asking because in one of my DSL I had to consider parameters as non > > final by default > > Could you please outline the use case for writable parameters? Well, simply the possibility to define methods where parameters are non-final by default, as in Java, to make my DSL method definition correspond to a Java method definition. I know it's a bad habit to make parameters non final and writable, but in my DSL I have to respect the Java shape and semantics of methods' parameters :)
Hi Lorenzo, given that there is currently no way to read the 'final' flag from the class file, the argument 'non final parameters are like in Java' is not entirely convincing to us. In fact JvmFormalParameter#isFinal would answer kind of arbitrarily for all parameters that are contained in TypeResources. Therefore such an API is nothing we want to expose. Another option would be to make it easier to customize the final/writable state of a parameter. If you can come up with some API that would help you to implement your semantics, please provide a Gerrit changeset.
Hi Sebastian I could think of two possible solutions (without touching JvmFormalParameter): 1. introduce a method in the XbaseJavaValidator to easily delegate the decision whether a JvmIdentifiableElement is to be considered writable or not; this could be used for variables, fields and parameters and used in checkAssignment(XExpression expression, EStructuralFeature feature, boolean simpleAssignment). It could be easily redefined in custom implementations. Similarly, introduce an overloaded method in JvmModelGenerator override void generateParameter(JvmFormalParameter it, ITreeAppendable appendable, boolean vararg, *boolean writable*, GeneratorConfig config), the current implementation would call it with writable=false, and a custom implementation, in this case my custom implementation, would call it with writable=true. 2. introduce some kind of XbaseModelHelper (or XbaseModelExtensions?) to be used in the validator and in the model generator, with a method isWritable(JvmIdentifiableElement) I would tend to prefer the second approach, that could also be used for other customizable behaviors concerning the Xbase model. For example, in the DSL I was talking about, also variable declarations, which have the syntax of Java variable declarations, are non-final by default. (This customization was easier, but to avoid overriding many methods in the validator and the compiler, I chose to have a derived XVariableDeclaration model class that defaults isWritable to true.) Storing the final/nonfinal state in the model would still require the programmer to have a custom JvmFormalParameter, but besides that he would only need to customize the XbaseModelHelper without touching the validator and the generator. In any case, if you think such additions are not worthwhile, this is not a blocking issue, at least for me :)
I think a holistic approach would be nice, that allows to customize the 'nature' of local variables and formal parameters. E.g. it would also be interesting to allow name shadowing in some sense. So a combination of both approaches would eventually be interesting: Having a single method in the validator, code generator etc that handles this stuff but its implementation delegates to a utility (maybe called LocalVariablesAndParameters). Would you be willing to work on that? It would likely need a few iterations, though.
I'd like to see some convincing use cases for such an enhancement.
@Sebastian: yes, I'd like to work on that, and I'll try to do that in the next weeks. @Sven: I tried to give an idea of the use cases in some of my DSLs scenarios.
(In reply to Lorenzo Bettini from comment #11) > @Sebastian: yes, I'd like to work on that, and I'll try to do that in the > next weeks. > > @Sven: I tried to give an idea of the use cases in some of my DSLs scenarios. Lorenzo, thanks for your help on this. Before you put effort into the topic, we should all agree on the advantages / cost of such an abstraction. As far as I can tell, your use case was mainly a DSL where you 'had to consider parameters as non final by default' but that doesn't explain your intend. Also the idea 'to make my DSL method definition correspond to a Java method definition' cannot be fulfilled since the JVM model that is created from Java binaries will never be allow to distinguish between final and non-final params without an additional annotation. Could you elaborate more on the use case, please?
(In reply to Lorenzo Bettini from comment #11) > @Sven: I tried to give an idea of the use cases in some of my DSLs scenarios. You were mentioning that it has to be like in Java, but not why. Also I was curious about what Sebastian had in mind, when he mentioned name shadowing.
(In reply to Sven Efftinge from comment #13) > (In reply to Lorenzo Bettini from comment #11) > I was curious about what Sebastian had in mind, when he mentioned name > shadowing. Currently we only allow to shadow 'this' and 'it' in Xbase, though Java allows to shadow more names. One could think of this to be a constraint on JvmFormalParameter similar to the fact that they are final. That's why I brought this into the discussion, too.
(In reply to Sebastian Zarnekow from comment #14) > (In reply to Sven Efftinge from comment #13) > > (In reply to Lorenzo Bettini from comment #11) > > I was curious about what Sebastian had in mind, when he mentioned name > > shadowing. > > Currently we only allow to shadow 'this' and 'it' in Xbase, though Java > allows to shadow more names. Where is that? Do you have an example? > One could think of this to be a constraint on > JvmFormalParameter similar to the fact that they are final. That's why I > brought this into the discussion, too. In general I think it is bad if many usages of Xbase have slightly different semantics or syntax, as that harms reusing people's knowledge about xbase and will cause surprises when people have to work in two or more different xbase languages. The other reason I'm sceptical is that feature resolution is already very complicated not only for users but also implementation wise. That said I know that there are people who just want to have it in a certain way and that there might also be very isolated user groups, in which case a changed semantic wouldn't cause such irritations. But I think we shouldn't compromise the main code base for those situations but rather do the heavy lifting in their code bases. So maybe something in between, i.e. extracting a missing template method here and there that let you do this stuff, would be a good compromise.
(In reply to Sven Efftinge from comment #15) > (In reply to Sebastian Zarnekow from comment #14) > > Currently we only allow to shadow 'this' and 'it' in Xbase, though Java > > allows to shadow more names. > > Where is that? Do you have an example? Basically everywhere where it is allowed to shadow the name 'it', e.g. lambda parameter names, or parameters of methods in anon classes. (In reply to Sven Efftinge from comment #15) > So maybe something in between, i.e. extracting a missing template method > here and there that let you do this stuff, would be a good compromise. I think that's already mostly the case, but still you'd have to figure out all of the necessary places. I'm not convinced by the #isFinal thing or relaxation of name shadowing either. Still it would be interesting to discuss the reasons why one would want to have that.
