I avoid get/set prefixes in method selectors, however it is a "good practice pattern" the use of the "set" prefix as a private accessor. I use it to build initialized instances, MyClass class>>#attribute: anObject ^self new setAttribute: aString In some cases MyClass doesn't have the `#attribute:` setter because it's not meant to be modified externally. In the case of the `name` setter for a class, adding the `class` prefix is redundant, so I think that `setName:` is the right selector to use. It's like the Clipboard class, that has the `clipboardText:` selector instead of `text:` or something similar, but without the redundant `clipboard` prefix. But without diverting from the main topic, I think that the `name` accessor is one of the things that causes a lot of trouble because of unanticipated side effects. It indirectly becomes some sort of "reserved word" of the language. Also `name` is a common property in many domain objects, and creating the accessors will create name:/name1 selectors, which is confusing for newcomers as well, because they'd expect the #name getter instead of #name1. Regards, Esteban A. Maringolo 2017-08-21 9:42 GMT-03:00 Dimitris Chloupis <kilon.alios@gmail.com>:
its inconsistent to start using (set) in front of the name of methods and unnecessary
className:
makes more sense to me
Another way to do this instead have something like classMetaData which can be a dictionary containing all the data like name of the class, method dictionary etc this way we ensure that what happened with name does not happen with other methods too that may find themselves in a name conflict by an unaware user.
Or we can provide both ways or something else.
Class name has caused me pain too and I am no newbie , when I was making an API for Blender it clashed with the name of the 3d objects. So this is definitely not newbie orientated problem , its a fundamental problem.
I dont mind which solution you guys follow , afterall its easy to solve cause its easy to override any solution I don't like. The beauty of Smalltalk :)
On Mon, Aug 21, 2017 at 11:05 AM Marcus Denker <marcus.denker@inria.fr> wrote:
On 20 Aug 2017, at 23:48, Brad <bsselfridge@gmail.com> wrote:
I vote for setClassName:
setName: is better because this is what is there since many many years⦠and by just using it we must need to deprecate one method, not two.
Marcus