[Pharo-dev] Lowering the pain of newbies
i.uhnak at gmail.com
Mon Aug 21 14:39:36 EDT 2017
I'd prefer to not use `setName:` nor `setClassName:` as `setX:`/`setX:Y:`
is often used as a constructor initialization pattern (as per Kent Beck's
Using `className:` could be confusing, as it could be unclear whether you
are changing the name of the class itself, or the name of the class of the
class (the "Class class" class :)).
Maybe `changeNameTo:` to explicitly state the intent?
> It indirectly becomes some sort of "reserved word" of the language.
Class has many such methods (and I've destroyed my image many times before
I subconsciously learned to avoid them), but only name tends to be
problematic so introducing "special" methods for meta methods seems
pointless, as a person doing metaprogramming would (must) take the care
anyway to distinguish on which side they are working on.
On Mon, Aug 21, 2017 at 3:08 PM, Esteban A. Maringolo <emaringolo at gmail.com>
> 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.
> Esteban A. Maringolo
> 2017-08-21 9:42 GMT-03:00 Dimitris Chloupis <kilon.alios at 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
> > 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
> > 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 at inria.fr>
> > wrote:
> >> > On 20 Aug 2017, at 23:48, Brad <bsselfridge at 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev