I've been looking at ways to make CDateTime more flexible in the types of selection it can hold and am exploring making it a generified type.
The advantage of this is that the selection could then be a java.util.Date, java.sql.Date/Time/Timestamp, Date[], etc..., while only requiring one set of getters/setters: T getSelection(); void setSelection(T). This would reduce the API complexity and allow great flexibility for future implementations. The first disadvantages is that current code would have to be modified (not much, but still modified). Code like this would still work: CDateTime cdt = new CDateTime(parent, CDT.BORDER); but would show warnings (irritating). The real problem is that although getSelection() would return a java.util.Date object, it would need to be explicity cast. To fix both of these a type could be specified: CDateTime<Date> cdt = new CDateTime<Date>(parent, CDT.BORDER); The second disadvantage is that the type needs to be passed into the CDateTime constructor. This is because CDateTime must create selection objects itself, rather than just have them passed in like a List does, and because of the wonders of type erasure, it cannot infer the type from the generic. This actually has two problems: 1. this eliminates the SWT style two param constructor; and 2. the type is bounded by Object (because the possible selection types share no common hierarchy) which means that there's no way to get real type safety from the compiler without using static factory methods: CDateTime<Timestamp> cdt = CDateTime.createTimestamp(parent, style). So far the negatives could be worth it, but I wanted to gather some input before making anothing drastic change. Does anyone see another disadvantage to taking this direction, or have a reason that the above drawbacks are unacceptable?
_______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
