Nico Klasens wrote: > I thought a little more about this and I realized that the scope for > 1.9/2.0 is not clear to me. The abstract of the release plan would be > transition to java 1.5 and first version of mmbase framework and > component infrastructure. The above makes it sound like a minor change, > but I believe it are big ones. > > At the component weekend we discussed a new config directory structure > which would be much more future proof. When we are going to use that one > then all webapps have to change. We are than not backwards compatible in > respect to file locations. Source, build and deployment will change for > all webapps.
Yes, I'd not be against changing that. It is rather big change, though it does not sound as very much work. > > Transition to java 5 is still a "scary" thing when not well prepared. > Does it mean only transition of the mmbase internals to java 5 or is it > also exposed to the outside world? When only the internals are changed > then it is not a major change for webapps, but when the api exposes java > 5 then it is. In the first place I would think of the internals and of course the permission to use java 5 features for new code. > Telling people to just use the erasure of our generic > list type is stupid. The compiler will even warn you for these stupid > statements. A generic type guarantees that only certain types can go in > and out of the class. > The NodeList does not have this constaint, because > you can throw in a list of mixed types and retrieve only Node objects. I think the implementation of NodeList is not optimal any way. It should perhaps not extend AbstractList but rather wrap a list. Then the constructor can relatively easily stay as it is (accepting any collection), and the implementation can avoid copying the complete list (hence improving performance). Of course you cannot put other objects then Node's in it any more then, but I seriously hope that people where not doing that anyway. Actually, changing a node-list which only wraps a query-result rather then copying it, should be disallowed too. For code which as doing that (of which there exists presumably not much) a 'ChainedNodeList' or so can be provided. The 'NodeList' interface can then perhaps me made deprecated to start with. You should use lvalues of type List<Node> or perhaps BridgeList<Node> (for the 'property' methods). Erasure can be profited from for backwards compatibily, just as Sun has done. And must code which naivily states NodeList list = cloud.getList(..) should remain compling and working. IOW, I think it is possible to have a situation which is very much backwards-compatible, though probably it is impossible to make improvements with absolute backwards compatibility. Michiel -- Michiel Meeuwissen mihxil' Peperbus 107 MediaPark H'sum []() +31 (0)35 6772979 nl_NL eo_XX en_US _______________________________________________ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
