launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Mon, Mar 29, 2010 at 5:55 PM, James Westby <jw+debian@xxxxxxxxxxxxxxx> wrote:
> On Mon, 29 Mar 2010 17:21:56 +0100, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
>> I think ultimately you'll need to be explicit. For example,
>> IBranchTarget(sourcepackage).name != sourcepackage.name for any
>> ISourcePackage.
>
> Right, that's true, which pretty much rules out the invisible to clients
> approach, unless a prefix is added.
>
>  branch_target_name
>
> would be ok in my eyes, but
>
>  branchTargetNewCodeImport()
>
> or similar would not be.
>

I guess you could implement IBranchTarget(obj).name and
IBranchTarget(obj).newCodeImport() on the client-side too.

>> > If there are writeable attributes in any adapted objects then you have
>> > the choice between a PATCH to the object and it's adapted version that
>> > would have to infer which attributes are associated with which object,
>> > or two PATCH requests with the inherent atomicity concerns.
>> >
>>
>> I'd lean to the second – to being explicit. The atomicity concerns
>> would not be unique to adapted objects.
>
> True.
>
> I think we are in agreement then.
>
> There's pretty much nothing that would stop you implementing this
> approach now, just without any sugar to make it easy to do so. Should I
> have a look at doing it this way for IBranchTarget.newCodeImport()?
>
> Actually, perhaps I don't want to volunteer for that, as I'm not sure
> how I would implement the canonical url for IBranchTarget, given that it
> would change based on the target, and IBranchTarget doesn't actually
> have any attributes for gettting the original object.
>

It's not on the interface, but all of the implementations define a
'context' property.

jml