[swift-users] Why can't Swift instance methods call class methods without qualification?

[Rick Mann]

> On Jul 1, 2016, at 17:15 , Jens Alfke <jens at mooseyard.com> wrote:
> 
> 
>> On Jul 1, 2016, at 3:24 PM, Rick Mann via swift-users <swift-users at swift.org> wrote:
>> 
>> Maybe it's just my C++ upbringing
> 
> I think that’s it, yes. (No offense intended.) Different languages have very different ways of doing things. C++ has a very intense focus on performance, and that’s led to its object model being very limited (I could say “crippled”) compared to almost any other OO language. Part of this is the way that static methods are really just namespaced functions, not true methods.
> 
>> Hmm. It sounds like you're saying it is the way it is as a side-effect of the language implementation.
> 
> No, it’s a side effect of the language design. I could go into more detail, but I’d just be repeating what Brent said, basically.
> 
> If you really want to dive into this rabbit hole, I suggest learning about Smalltalk, which is in most respects the original OO language, and the direct ancestor of Obj-C’s OO features. Metaclasses are a pretty deep concept and well worth learning about. (I remember poring over the class hierarchy diagram in the flyleaf of the Smalltalk-80 “Blue Book” as a college student…)
> 


I'm willing to let the matter drop after this comment. But based solely on the syntax of how one defines a class, I think it makes perfect sense to be able to call a class method from an instance method with no special qualifier, but the reverse is obviously not true. There's more than adequate information 

It also makes sense to disallow class and instance methods to have the same name. That's just asking for trouble, especially with implicit scoping.

I say this because the class and the instance are declared in the same place (i.e. in a "class" declaration). To me, this is is a part of the design of the language, and why nothing about this design screams to me that you can't implicitly understand that an unqualified call to a class method is what it is.

Anyway, I'm done discussing it. I don't like it, I think it's an esoteric argument for why it is, and I think it's nonintuitive, I think the alternative is better (i.e. easier to use), and wouldn't prevent any reasonable or necessary programming paradigm.

-- 
Rick Mann
rmann at latencyzero.com