Since attribuets can be versioned, we should simply add support for removing them at a specific version from the API, like we do for operation.
No special cases needed. It's simply a small limitation to fix. Of course, that doesn't pre-empt the discussion as to whether we should simply decide to unilaterally break our backward compatibility. But I don't see why attributes would be special in this case compared to operations. I think the reason we only added removal support for named operation is related to Leonard's goal of removing all named operation in favor of more restful APIs. (turn accessor/mutator into a property, searchable collection, POST factories, DELETE removal, etc.) Cheers -- Francis J. Lacoste francis.laco...@canonical.com On June 6, 2011, Aaron Bentley wrote: > On 11-06-03 09:57 PM, Robert Collins wrote: > > So we should: > > - think twice before exposing attributes > > You make it sound like attributes deserve special consideration, but an > attribute is equivalent to setter method and a getter method. Their > special syntax is really just syntactic sugar. If we choose to change > the underlying implementation later (so that they actually are a > setter/getter pair), Python will support us. > > So I don't think attributes deserve any more consideration than methods. > > We now expose attributes and methods in the "devel" API so that we we > have license to change or remove them freely. I don't think the > circumstances that led to Brad's issue still apply. > > If you mean "expose attributes" in the broad sense that we expose them > as part of the user model, regardless of how they are manipulated, I can > see some logic in that. But there is a constant push to expose more and > more, so that our web service clients are just as empowered as local > code is. At times, you yourself have championed that. > > Aaron > > _______________________________________________ > Mailing list: https://launchpad.net/~launchpad-dev > Post to : launchpad-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~launchpad-dev > More help : https://help.launchpad.net/ListHelp
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
