Revisit on append method behavior of objectIter about openapiart HOT 5 CLOSED

The append method was never fully implemented and was added to for a clone test case.
The original append method required a user to import a class, instantiate it and the append that instance which is counter to the intent of the library (no imports required by a user except for the single top level import).
Users of the original append method were advised that breaking changes were coming and to not use it.
The current refactored implementation is in use should not be commented out.

from openapiart.

The change to comment out the current append behavior should be reverted.

from openapiart.

sure Andy
@ashutshkumr, FYI

from openapiart.

I think both the behaviours are derived from valid use cases and we should decide whether to overload the meaning of append or provide methods with different names.

First usecase

f1, f2 = config.flows.flow(name='f1').flow(name='f2')
# when most configurations in f2 and f3 are common
f3 = f2.clone()
f3.name = 'f3'

f1, f2, f3 = config.flows.append(f3)

Second usecase

f1, f2 = config.flows.flow(name='f1').flow(name='f2')
# when most configurations in f2 and f3 are not common
f3 = config.flows.append(name='f3')

from openapiart.

As discussed, for second use case above, we'll introduce add.

f1, f2 = config.flows.flow(name='f1').flow(name='f2')
# when most configurations in f2 and f3 are not common
f3 = config.flows.add(name='f3')

from openapiart.