[Pharo-project] About ArrayedCollection and at:/put:
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 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. 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). -- Best regards, Igor Stasenko.
On 2012-11-30, at 11:33, Igor Stasenko <siguctua@gmail.com> 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 ;)
On Nov 30, 2012, at 3:33 PM, Igor Stasenko 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
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.
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).
+ 1
-- Best regards, Igor Stasenko.
participants (3)
-
Camillo Bruni -
Igor Stasenko -
Stéphane Ducasse