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.al...@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.den...@inria.fr> > wrote: >> >> >> > On 20 Aug 2017, at 23:48, Brad <bsselfri...@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
