JList jl = new JList(items); jl.setLayoutOrientation(JList.HORIZONTAL_WRAP); jl.setVisibleRowCount(-1); jl.setSelectionMode(ListSelectionModel.SINGLE_SELECTION); jl.setDragEnabled(true); jl.setDropMode(DropMode.ON_OR_INSERT); jl.setTransferHandler(new TransferHandler() { ...
Because Java has no Delphi with construction, we cannot write simply say
JList jl = new JList(items);
with jl { setLayoutOrientation(JList.HORIZONTAL_WRAP); setVisibleRowCount(-1); setSelectionMode(ListSelectionModel.SINGLE_SELECTION); setDragEnabled(true); setDropMode(DropMode.ON_OR_INSERT); setTransferHandler(new TransferHandler() {
I, therefore, avoid redundancy using double-brace initialization
JList jl = new JList(items) {{
setLayoutOrientation(JList.HORIZONTAL_WRAP); setVisibleRowCount(-1); setSelectionMode(ListSelectionModel.SINGLE_SELECTION); setDragEnabled(true); setDropMode(DropMode.ON_OR_INSERT); setTransferHandler(new TransferHandler() {
It is a nice syntactic trick. At first glance it seems ok and encouraged by both java experts, who recommend a "Helper" class for every tiny problem and Java workflow itself (recall that every single callback and event handler requires a new class). But, I suspect that there is an implementation overhead: creating a class for the sake of initializing just a couple of fields results in many classes. Their loading takes time and storage takes space, which also implies additional caching penalty.
I have invented alternative way: the language must support properties, which must/may be initialized by the user:
jl = new JList( items = items, layout = HORIZONTAL_WRAP, rowcount = -1, selectionMode = SINGLE_SELECTION, dragEnabled = true, dropMode = ON_OR_INSERT, transferHandler = new TransferHandler() {... ); :))I wish Java had the Delphi with construction. But named arguments could also be very helpful, especially in constructors. They enable optional parameters and make the code more self-descriptive.
There is a final-problem with object initializers in Java.
No comments:
Post a Comment