Always prepend an underscore for fields

[yotamN]

Because of the way of how Frida resolve conflicts between methods and field with the same name it require the user to know if there is a method with the same name as the requested field before accessing it. I propose adding an underscore anyway, so people could always prepend an underscore to the field and expect it to work.

[yotamN]

So excluding the current solution of prepending an underscore sometimes and sometimes not, there are three possible solutions that I think would be easier when developing (even if a bit more verbose):

1. As I suggested, prefixing all the properties with an underscore. #241 is backward compatible, we could maybe remove the option to access a property without an underscore in a later major version.
2. Accessing all of the properties and methods through a methods and properties fields which could be aliased to m and p for brevity. Of course in the migration period, the existing fields will override the new fields but the new fields will still be accessible with a Symbol object.
3. Removing the special handling of clashed names and instead provide methods and properties through the existing mechanism but instead of prepending an underscore, clashed names will have to be accessed through the methods and properties fields. If there is a methods or properties fields in the Java code of course, it will clash, but for the rare cases that it does, we will provide a Symbol object.

Another less drastic solution that might help a bit is to prepend a dollar sign instead of an underscore, I personally haven't seen $ signs used in the start of an identifier but it might be only my limited experience.

[oriori1703]

I personally like option 2 the best, but option 3 also seems good.

BTW, I think fields / f are better names then properties / p

[oriori1703]

I also think this is a good opportunity to remove a feature I never really liked; needing to add .value after accessing fields.

I can't recall a single time I ever needed anything from the field holders, that is not their values. Maybe the fieldReturnType, but that could easily be received from the field value itself using $className.

My proposal is when accessing fields using javaObject.fieldName you would get the current field holder, for backwards compatibility, but while using javaObject.fields.fieldName you just get the actual field value.