KSL: Reflection's orthogonality improvement

[Maurizio Cimadamore]

Hi,
Note that in general it is not possible to implement reflection checks 
statically, simply because the compile time and the runtime views of the 
world might be different: so, if all access checking was done at 
compile-time, (and the code would be replaced with the member name), you 
could have cases where at runtime no access error occurs - in cases 
where the member is no longer accessible (i.e. because of separate 
compilation).

A different approach would be e.g. to say that we have some syntactic 
sugar to create reflective elements. In such a setting lookup, 
accessibility check would still occur dynamically - the compiler will 
only help you removing the boilerplate. But I'm not sure such a feature 
would help much in the BD-like example you posted.

Maurizio

On 12/10/15 11:58, bsrbnd wrote:
> Hi,
>
> Just an idea for the "Kitchen Sink Language".
> I hope this subject hasn't already been discussed and that I haven't missed
> anything in the quite big and complex JLS.
> It's said not to think too much if this is a good or bad idea before
> submitting it for the KSL, but I hope I've thought enough...;-)
> Any comments, ideas or suggestions are welcomed.
> No implementation draft has been done until now, but it could be explored
> if comments are encouraging...
>
> Thanks in advance,
> bsrbnd
>
> Abstract
> --------
> Reflection is designed to access a class member given its name as a String.
> For example:
> MyClass.class.getDeclaredField("field") reflects MyClass.field or
> MyClass.class.getDeclaredMethod("method") reflects MyClass.method()
> But the reciprocal is false, we can't get the "String name" of a class member
> given its identifier.
> This implies a runtime check of the "String name" and an eventual exception
> if the name doesn't match a declared member...
> For this reason, we can say that reflection isn't totally orthogonal.
>
> Reciprocity with qualified strings (to be added to JLS 6.5.6.2,15.8,..?)
> ------------------------------------------------------------------------
> To avoid occasional exceptions (but not runtime checks) and improve reflection's
> orthogonality, I suggest to add the concept of "qualified strings".
> For example:
> MyClass."field" checks at compile-time that "field" is declared on
> MyClass and respects accessibility and visibility rules in a compatible way
> defined by reflection's API. This means that all declared member's names
> (private, protected, public, static or not) but neither inherited nor synthetic
> should be accessible as they are accepted by getDeclaredField() or
> getDeclaredMethod().
> If all compile-checks pass, this expression gives back the name of the
> member as a String.
>
> Grammar update (JLS 15.8)
> -------------------------
> I suggest to add the following line in "PrimaryNoNewArray" rule of the grammar:
>
> PrimaryNoNewArray:
>   TypeName . " Identifier "
>
> A simple databases example using "qualified strings"
> ----------------------------------------------------
> In the following example, "qualified strings" ensure that valid member's names
> are used in SQL requests to be correctly used by reflection to store back
> the result of the request:
>
> class MyTable {
>   public static final String name=MyTable.class.getSimpleName().toLowerCase();
>   public Integer id;
>   public Integer value;
> }
> MyTable line = new MyTable();
>
> String request =
> "SELECT " + MyTable."value" + " FROM " + MyTable.name +
> " WHERE " + MyTable."id" + "=" + line.id
>
> String valueColumn = resultset.getMetaData().getColumnName(1);
> Field f = MyTable.class.getDeclaredField(valueColumn.toLowerCase());
> f.set(line, resultSet.getInt(valueColumn));
>
> Conclusion
> ----------
> The usefulness of "qualified strings" isn't limited to this simple
> database example.
> It extends to every context where it is necessary to get informations
> from external parties and store back results dynamically in objects
> through reflection.