KSL: Reflection's orthogonality improvement

[bsrbnd]

Thanks for your both answers.

Referring to the first message, I agree that compile-time and runtime
are distinct worlds.
But, in our case, the link between them is the "String name" of members.
Therefore you can see qualified strings as a kind of compile-time
reflection (the reciprocal of runtime reflection).
In this context, the reflective object of an identifier is just a
"String" representing its name.
This is why it is different from a syntactic sugar or a specific
symbology to access reflective objects through class members.

But we could go further in this approch by getting a kind of "Symbol"
instead of a "String" to reflect the identifier.
For example:
 MyClass.#myMethod
would denote a "MethodSymbol" representing the compile-time view of myMethod().
If you define (in addition to its name), an apply(Object, Object...)
method on it; you would be able to call a precise method, without
dynamic binding.
This could let you access other methods than the specific one...
For example:
 Object.#toString.name
would be equivalent to Object."toString" (qualified string) and:
 Object.#toString.apply(new Integer(1))
would apply on "new Integer(1)" the method "toString()" defined on
"Object" instead of the one defined on "Integer".
This is, of course, only an example to demonstrate the concept behind
qualified strings, not to discuss about object-oriented principles...

Referring now to the second message, I agree that one of the reasons
behind this is to add some kind of meta-programming facility.
Nevertheless, I understand if it has already been discussed along the
years and therefore doesn't
meet the adopted design philosophy.
But, it was very tempting to suggest this concept regarding to its
quite straightforward implementation
and the added possibilities it brings...

bsrbnd

2015-10-12 12:58 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
> 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.