factory functions for Java UI libraries

Some UI libs, like Swing or Android, use property setters to build and don’t have any builder/constructors for those, which makes them cumbersome to build.

We could propose compiler flags to auto-generate factory functions that would turn:

public class Foo extends View{
 public Foo(View parent){}
 public void setTitle(String title){}
 public void addChild(Child child){}
}

Into:

shared foo(View parent, String= title, {Child*} children){}

Then, title would be passed with the setter and children would be passed with addChild. This is all compile-time magic.

We’d have to be able to configure which packages/classes get this feature activated because it is expensive otherwise. We’d also have to configure which method to generate variadics for (addChild for example). For Android, we’d also have to consider making parent optional and default to this IFF the caller is a subtype of View, or if there’s such a subtype in scope. That’s very special-casey.

[lucono]

We could propose compiler flags to auto-generate factory functions that would turn:

public class Foo extends View{
 public Foo(View parent){}
 public void setTitle(String title){}
 public void addChild(Child child){}
}

Into:

shared foo(View parent, String= title, {Child*} children){}

I think what might be more useful for addressing the problem (or a significant part of the pain point) in this issue would be a standard language-level feature that allows the setting of multiple properties at once on an object. This could also help to some extent with the stated situation in Android and Swing.

So for instance, any code like this:

value foo = Foo();
foo.propA = "propA";
foo.propB = "propB";
foo.propC = "propC";

could be replaced with something like the following (using a fictional syntax):

value foo = Foo();
foo.{ propA = "propA"; propB = "propB"; propC = "propC"; };

Another interesting extension might be to have this syntax return the object, so as to allow chaining, including with construction:

class Foo(String name) { /* ... */ }

value foo = Foo("bar").{ propA = "propA"; propB = "propB"; propC = "propC"; };

But regarding the Android UI problem, I think something more extensive, such as a focused library, is what would really be needed (which may be something that ends up coming from the community rather than from the language team).

[xkr47]

I think @lucono has valid points with regards to readabilty. His proposal also allows for smooth updating of already instantiated objects. I would find that beneficial in many situations.

However, this also brings to memory the with keyword in the Javascript language which didn’t fare so well (see e.g. https://stackoverflow.com/questions/1931186/with-keyword-in-javascript#1931195). But I think the static typing in Ceylon (or Java for that matter) would probably avoid most problems that the with keyword had,