On 2012-11-30, at 11:33, Igor Stasenko <[email protected]> wrote: > It says: > > "I am an abstract collection of elements with a fixed range of > integers (from 1 to n>=0) as external keys." > > now that leaves me clueless, why then it does not defines (introduces) > a protocol: > #at: > and > #at:put: > > at least as an abstract one , i.e. subclassResponsibility
=> definitely should be abstract > is it because they are already in Object protocol? And because > subclasses (like Array) using default #at: implementation? > > I don't know, but i think Object should not have #at:/#at:put: > protocol.. because: > - it applicable only to variable subclasses > - many classes have own implementation of it > - the behavior behind this is to access a variable fields . while > other classes use this protocol for higher abstractions (like > dictionaries) > > so, to my thinking, Object should not define this protocol.. for this > purpose we having #basicAt:/put: methods. yup I think the same way. Happened to already too many times that I call #at:put: on a random object and to my surprise it worked :P > btw, just an idea to clarify things even more, we could rename them to > variableAt: [put:] > (or any other name which properly tells that method provides an access > to variable fields of object). on simple collections: #at:put: => #basicAt:put: on normal objects: #fieldAt:put => #basicAt:Put: I prefer fieldAt: since it is not always the instance variable you access like on variableSized objects where you simply access an item. Also it goes along the naming convention we had in our slot paper ;)
