[ http://issues.apache.org/jira/browse/WSCOMMONS-23?page=comments#action_12378839 ]
Brian Hulse commented on WSCOMMONS-23: -------------------------------------- This is going to be a "taste" issue, but for my taste a good interface is one that is: (a) Easy to explain (b) Predictable If we say that Id is just like any other attribute, the user knows what will happen when clearAttributes() is called. In truth, I can't really think of a scenario where anyone would actaully use this call to support my argument, but if we start adding in all sort of special processing it's going to break (a) and (b). Equally, a user could add in Id via the addAttribute() call, and remove it via removeAttribute(), but not clear it via clearAttributes()? ... then we shoul add in special processing for addAttribute() and removeAttribute() ... well, you can see where I'm going here. This isn't a massive issue, and I'm not going to labour it, but one of the advantages of having written a WS-Policy package already is you get to fix the things you didn't like when you do it again ... :-) Anybody else got an opinion? > Fix attribute problems in Test_Policy > ------------------------------------- > > Key: WSCOMMONS-23 > URL: http://issues.apache.org/jira/browse/WSCOMMONS-23 > Project: WS-Commons > Type: Bug > Components: Policy > Reporter: Brian Hulse > Attachments: Test_Policy.txt > > I haven't been consisitent with my model here. I believe that architeched > attributes, like Id, should be treated as other attributes as this will ease > the burden of serialization/deserialization ... which is how the code works > at the moment. However, these tests assume otherwise. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
