Extending Builders: Layout Builders

[Tom Schindl]

Am 29.11.12 19:32, schrieb 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).
> 

Who says it has to be a map

class Constraint {
  private Object[] data;

  protected Constraint(int attributesCount) {
    data = new Object[attributesCount];
  }

  protected void set(int index, Object value) {
    data.put(key,value);
  }

  public <O> get(int key) {
    return data[index];
  }
}

class HBoxConstraint extends Constraint {
  public static final int PRIORTIY = 0;

  public HBoxConstraint() {
     super(1);
  }

  public void setHgrow(Priority priority) {
     set(PRIORTIY,priority);
  }

  public Priority getHgrow() {
     return get(PRIORITY);
  }
}

All we need to some reflective way to access the data without casting
I'm not sure about the overhead of array-index look ups but I think they
are fairly small and they don't we only have one object instance

If we have constraints with really many attributes we could move the
ones with expect to be used more often at the beginning and the others
with a higher value and make our initial array size smaller.

Tom


-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834