Hi, Am 11.04.2012 um 19:49 schrieb Michael Dürig:
> > > On 11.4.12 18:31, Felix Meschberger wrote: >> Hi, >> >> Am 11.04.2012 um 12:03 schrieb Michael Dürig: >> >>> >>> >>> On 11.4.12 10:15, Felix Meschberger wrote: >>> >>> [...] >>> >>>> But then: the move and copy methods look like out-of-band somehow and do >>>> not really concern the state of the node itself but potentially completely >>>> unrelated ones. >>>> I would move them somewhere else. >>> >>> That'd mean we need to introduce a Branch class on which those methods >>> lived. Branch instances would then be returned from NodeStore.branch() >>> and would additionally contain methods for obtaining NodeStateEditor >>> instances. >>> >>> OTHO, those methods are not more out of band than Object.equals(). So in >>> a way we are idiomatic ;-) >> >> How is Object.equals(Object) out of band ? It returns information on >> equality of another object with this. >> >> NodeStateEditor.move(src, dst) moves a node(state) to another location. This >> is per-se urelated to this NodeStateEditor. > > It is not so out of bound after all if you consider that a NodeState > consists not only of its immediate children but rather of the full > reflexive transitive closure on child states. The src and dst parameters > may refer to such states only (see Javadoc) and thus only modify the > state of this node state alone. The JavaDoc says "path relative to this" which per-se does not say "below" because a relative path can also be "../../some/other". In addition the move and copy methods are the only ones taking "relative path" instead of just name. Its just kind of inconsistent. Regards Felix > > Michael > >> >> But we could modify the API to actually related to this NodeStateEditor: >> NodeStateEditor.moveTo(dst) and NodeStateEditor.copyTo(dst). This in fact >> also sounds less "side-effecty" >> >> Regards >> Felix >> >>> >>> Michael >>> >>>> >>>> Regards >>>> Felix >>
