Julian Foad wrote:
> Hyrum K. Wright wrote:
>> Bert Huijben wrote:
>>> Shouldn't we create some kind of context/args object that we can
>> extend in future versions for methods that probably have yet another
>> version in the next release?
>>> Adding boolean number 4 to a function doesn't make user code more
>> understandable, and with a context/args struct with a constructor
>> function we can just extend that structure in the next release without
>> breaking the ABI.
>>
>> I thought about this same issue when extending the status API on the
>> ignore-mergeinfo branch. I suspect there are several APIs we could do this too
>> next time we rev them. If we identify those, we should put a note in their
>> comments.
>>
>> Bert, could you write the patch (against the ignore-mergeinfo branch, of course)
>> for this?
>
> I think it would be sensible to do that on trunk. Although there's an
> overlap, it's a logically independent change that can happen before or
> after the ignore-mergeinfo changes.
The reason I suggested it should happen on the branch is because such changes
should probably happen if and when we rev and API for something else, i.e. let's
not gratuitously rev the API just to add an arguments structure. We're already
rev'ing this particular API on the ignore-mergeinfo branch, so it seems logical
to do the work there.
I've no real opposition to doing it on trunk, excepting the fact that merging
back to the branch could be painful (but not impossible).
-Hyrum
Received on 2008-09-17 16:46:29 CEST