Extending Builders: Layout Builders

[Richard Bair]

>> It really is one of those situations where having a nice dynamic language would have been slick.
>> 
>> So the question I have here is, what is the type of the layoutConstraints (Object? LayoutConstraint?)? How does a layout container implement getting a constraint -- instance of and casting?
> 
> One way of thinking could be that Constraint is a map like construct
> because then the layout containers access their information through the
> same means they do today and don't have to cast to anything
> 
> class Constraint {
>  private Map<String,Object> data;
> 
>  protected void set(String key, Object value) {
>     data.put(key,value);
>  }
> 
>  public <O> get(String key) {
>     return data.get(key);
>  }
> }
> 
> And then you have concrete subclasses e.g.
> 
> class HBoxConstraint extends Constraint {
>  public void setHgrow(Priority priority) {
>    set(key,priority);
>  }
> 
>  public Priority getHgrow() {
>    return get(key);
>  }
> }
> 
> So that users have a type-safe API.

That does look like one way, have a type-safe API for developers (more or less -- they still have to cast the constraint if they do node.getConstraint() but at least when they set the constraint up they have some type safe API). However another problem I've had with this approach (and with our current approach) is that layout happens A LOT and costs a lot, so having to hit a map for all the constraint information (and not just the constraint object, but every property in the constraint object) is going to be expensive. Especially when thinking about embedded.

Between that and just having a type-safe API and having to cast, I'd probably go with the cast. Get the object, if instance of then extract the constraint values into local fields, otherwise set those local fields to default values, and off you go. Probably the fastest approach, but does require a cast. I wouldn't use a type-parameter on the Node based on constraint type (yikes).

Richard