Skip to main content

Getter/Setter/Field simplification

12 replies [Last post]
golly
Offline
Joined: 2005-05-11

In Mustang will there be some kind of way to simplify adding getters/setters and fields?

I've searched and haven't found any other solutions.

I think it could be solved with annotations, eg:
@JavaBeanStyleProperty{class=String.class,name=username,...}
public class User { .... }

Also, i know java will never implement multiple inhertence but would it be good if it could implement a similar functionality? For example the ability to include multiple abstract classes as long as there are no conflicts?

For example if we have the following three abstract classes:

abstract class HasUsername {
protected String username;
public void setUsername(String username) { this.username = username; }
public String getUsername() {return username;}
}

abstract class HasPassword {
protected String password;
public void setPassword(String password) { this.password= password; }
public String getPassword() {return password;}
}

abstract class HasJob {
protected String job
public void setJob(String job) { this.job = job; }
public String getJob() {return job;}
}

then we could make these 2 classes with ease.

public class SomeClass extends HasUsername, HasJob {}
public class AnotherClass extends HasUsername, HasPassword {}

Well, i guess that is multiple inheritence isn't is.... and everyone says it evil because you get too many conflicts and over complicates things but if you just set some rules and make it very strict to enforce simplicity (like no extending two classes that contains any matching methods or fields), then i think it would be very helpful.

Or back to the point, is there a better (and simple) way to implement this functionality?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
golly
Offline
Joined: 2005-05-11

Exactly. Which is why i'm not asking for anything complex such as c++ MI or anything, just a simple means to simplify multiple classes all containing the same code.

My example (just an exmple) of the "partial" concept is quite simple and allows classes to implement common code fragments.

public partial class P1 { private String hehe; }
public partial class P2 { private int i=0; public int ah() {return ++i;}}
public partial class P3 { public int ah() {return -1;}}
public partial class P4 { public long ah() {return -1;}}

... and then ...

public class C1 includes P1, P2; <-- Great.
public class C1 includes P2, P3; <-- Duplicate error.
public class C1 includes P2, P4; <-- Ambigious error.

Simple to use. No complicated ambiguity issues etc. Just a nice simple way to isolate common class elements (including those that contain fields).

ulfzibis
Offline
Joined: 2005-02-18

I think, that there is no need for a new keyword "partial", if you define, that abstract classes don't inherit the [i]implementations[/i] of Object's methods as toString().

So when you compile ExampleClass1, toString() is implemented same without conflicts as it should be done by:
[code]class ExampleClass1 {
protected String name;
protected int age;
public void setName(String name) { this.name = name; }
public String getName() {return name;}
public void setAge(int age) { this.age = age; }
public String getAge() {return age;}
}[/code]

ulfzibis
Offline
Joined: 2005-02-18

Golly claims:
> no extending two classes that contains any matching methods or fields

[b]@ ryan_ernst:[/b] In defining 2 different toString() methods, you violate this rule.

I claim for a different rule:
- No extending of two classes that contain any matching methods with different return types or matching fields of different types.
- If there are matching methods, they must be overridden.
- If there are matching fields, existing initializations must be overridden (alternative: .. depend on the order of inheritance).

Example:[code]
class AnotherClass extends HasUsername, HasPassword {
public String toString() {return HasUsername.toString();}
}[/code]

ryan_ernst
Offline
Joined: 2005-05-11

What you described is a complex set of rules the compiler must enforce. There would be no difference really between MI in C++ and the proposed MI in Java. The slight difference would be that javac would have complex rules regarding how classes must not inherit from specific other classes, and certain methods must be overriden, versus C++ which has a complex set of rules for which similar function is used in a given subclass using MI with common base ancestors.

ulfzibis
Offline
Joined: 2005-02-18

What means MI ?

ryan_ernst
Offline
Joined: 2005-05-11

MI = Multiple Inheritence

c_e_gesser
Offline
Joined: 2005-02-19

A more simple alternative (and equally usefull) would be and way to automatically delegate the implementation of an interface to a member.
Something like:

[code]
class CustomList implements List
{
@Implements(List.class)
private List data = new ArrayList();
}
[/code]

In this case the compiler should generate the methods specified on List, and delegate their calls to data:

[code]
class CustomList implements List
{
private List data = new ArrayList();

public int size() { return data.size(); }

public Object get(int index) { return data.get(index); }

//... and so on...
}
[/code]

I saw this proposed somewhere else already.... just can't remember where.
It is not multiple inheritance, but is pretty much like that, I think.

ryan_ernst
Offline
Joined: 2005-05-11

Interesting thought. What part of OO design would this then fall under? A custom list would then BE-A list, and HAVE-A list, but the list is the same for both. I like the idea, but it seems like its manipulating OO concepts.

ryan_ernst
Offline
Joined: 2005-05-11

Remember that all classes extend from Object.

So lets say in HasUsername you override the toString() method to

public String toString() {return "User" + username;}

Then in the HasPassword class you override it to be

public String toString() {return "Password=XXX";}

Now you have a code sequence as follows:

AnotherClass inst = new AnotherClass("Me", "myPassword");
System.out.println(inst.toString());

Which toString method should it use? This is a classic example of problems with multiple inheritence.

Multiple inheritence will lose its power if you restrict it in too many ways. And as you stated, without severely limiting (like disallowing common base classes), it is a nightmare.

golly
Offline
Joined: 2005-05-11

Good point. To be honest I completely forgot about Object. Very valid point. Maybe this problem could be solved by adding a few new keywords.

public partial class HasName() {}
public partial class HasAge() {}
public partial class HasCar() {}
public class ExampleClass1 includes HasName, HasAge {}
public class ExampleClass2 includes HasName, HasCar {}

Introduce partial classes that don't extend Object, and are just includable code fragments. Oh man, that'd be perfect! God somebody please implement this in mustang... or at least give me a push in the right direction and I'll try and do it myself if it's possible, hehe :)

ryan_ernst
Offline
Joined: 2005-05-11

One of the key design elements of the Java languages is that everything extends from Object. Removing this feature would take away from what the language already has. In this way, you can see that Java, from its conception, was created withOUT multiple inheritence in mind. Removing key design features from the language will never fly with Sun.

golly
Offline
Joined: 2005-05-11

But the classes would extend object. In the example:
public class ExampleClass1 includes HasName, HasAge {}
ExampleClass1 would extend object.