Currently, we use case to distinguish between newly created objects (upper-case class name) and properties (lower-case). Otherwise, it would not be clear when there's e.g. a text property and text class if we should set a property called text or create new text object and try to assign it to the default property. The same problem with static setters. Is "hello.text.text" a fully qualified name of text class in or "text" static setter of a hello.text class?

I guess we could define some order in which we would try out this options in the current context, but SB will have a problem since they use static mode which can be used without having the classes on the cp.


On 5.6.2014 20:57, Stephen F Northover wrote:
I see no reason why we should enforce this.  Martin, any idea?


On 2014-06-05, 12:05 PM, Guillaume Anctil wrote:

on a project I work on, the code convention does not follow the Java
standard and class names start with a lower case 'c': ""

In the <?import ?> parsing of the FXMLLoader, the loadType function looks
like this:

int i = name.indexOf('.');
int n = name.length();
while (i != -1
     && i < n
     && Character.isLowerCase(name.charAt(i + 1))) {
     i = name.indexOf('.', i + 1);

if (i == -1 || i == n) {
     throw new ClassNotFoundException();

String packageName = name.substring(0, i);
String className = name.substring(i + 1);

This causes a ClassNotFoundException on our custom controls because of the
lowercase check.

I was wondering if a simple:

int i = name.lastIndexOf('.');

Instead of the lowercase check could be viable. The ClassNotFoundException
would still be thrown later on, when trying to actually load the class.

Is there a reason that I don't see why the convention _must_ be upheld in
this case?


Reply via email to