brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <aled.s...@gmail.com>
Subject Consistency of our getConfig/setConfig methods
Date Fri, 22 Aug 2014 11:57:41 GMT
Hi all,

I'd like us to make the config methods the same on Entity, Location, 
Policy and Enricher.

As well as making things easier to understand/use, it will also allow 
for more code reuse (i.e. deleting code duplication) by pushing this up 
into the super-type BrooklynObject.

---
PROPOSAL
We add `BrooklynObject.getConfigSupport()` which returns 
`ConfigSupport`, which has a rationalised set of methods for accessing + 
setting config.

We deprecate (most of?) the methods on Entity etc.

We stop needing to use `EntityLocal.setConfig`, which currently causes a 
whole load of ugly casts in our code!

---
JUSTIFICATION

  * It's confusing (and results in more code) that the methods are
    different on Entity versus Policy etc.
  * We have nine methods on Entity/EntityLocal for getConfig, setConfig
    or getConfigRaw.
    That number easily justifies grouping them in a class with something
    like `getConfigSupport`.
    On Location, we have size methods (with an overlap of two on Entity!)

---
QUESTION:
Which top-level methods on Entity do we keep?
Is `entity.getConfig(configKey)` called so often that we don't want to 
force `entity.getConfigSupport().getConfig(configKey)`?
Any others?

---
PROPOSAL PART TWO
We could do the same for attributes/sensors (which are currently only 
available on Entities, so that is where we'd put `getAttributeSupport`). 
Currently one casts to be able to call `EntityLocal.setAttribute`.

Alternatively, `setAttribute` could be moved to be a top-level method on 
`Entity`.



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message