Community
Participate
Working Groups
Currently Expressions view doesn't call methods that are defined by the actual object's class, but do not exist in the declared type. For example, the Expressions view refuses to evaluate s.indexOf("abc"), if s is declared as Object, but contains a String. To evaluate this expression a user has to type ((String) s).indexOf("abc"). It gets even uglier if the run-time class is not imported in the current context. In this case the user has to use the fully qualified class name. It would be nice if the Expressions view was smart and did the cast for the user. All it has to do is to always assume a cast to the actual type. For example, an expression s, where s is an object, should be treated as ((TheActualClassOf_s) s). This change would eliminate inequality between treatment of data members and methods. Currently the data members can be viewed without an explicit cast, but calling methods requires a cast.
Not targeted for 3.4. This turns out to be more involved. Since an expression could contain multiple statements and could re-assign the value of a variable to another object, we cannot assume that any newly assigned value will be of the same type as the first value (and thus we cannot downcast/sepcialize the type of the object).
