Explicit Self

[jem5519]

I have been more active recently in using Swiftify over the last month than I have since I purchased they subscription. One enhancement that would be a great help for my workflow would be a tool-level preference that would explicitly generate "self" for all properties and methods for a class.

I realize that many/most folks like being able to not have "self" spelled out unless absolutely required but I find it very useful in conversion of objc code and for maintenance in general.

Would love to have this feature. - Jim

[alex-swiftify]

Hi Jim,

Thanks for the suggestion!

To better understand your need, can you mention the reason why do you want to keep the self. prefix in the output? Just wondering if (1) you have an internal code style / policy that requires explicit usage of self keyword for class methods and properties, or (2) you have some cases when the code produced by Swiftify does not compile (that is, the self. prefix is missing while it is required by the compiler for a particular case)?

Few references to mention the reasoning why we keep the self. prefix only when required by the compiler:

1. Ray Wenderlich Style Guide:

For conciseness, avoid using self since Swift does not require it to access an object's properties or invoke its methods.

Use self only when required by the compiler (in @escaping closures, or in initializers to disambiguate properties from arguments). In other words, if it compiles without self then omit it.

2. Swiftify review by swifting.io team:

6. PROPAGATES SELF TO METHOD CALLS While this is a safe option it is usually completely unnecessary and redundant piece. Still, better working code than optimized and broken.

// ArticleRepository.m
- (void)saveFavouriteArticle:(nonnull Article *)article {
    [self.articles addObject:article];
    [self saveFavouriteArticlesToDefaults];
}
 
// ArticleRepository.swift
func saveFavouriteArticle(_ article: Article) {
    self.articles.append(article)
    self.saveFavouriteArticlesToDefaults()
}

Anyway, we've already got enough votes to add configurable conversion options to the converter, so there is a chance that we will make this one configurable, too.

[jem5519]

Hi Alex,

As I stated, I understand that a large number of folks agree with references you have sited. I respect their views. In this case I do not agree with their view. I have been writing software for over 37 yrs. Does not mean I am an expert, but it does mean I have looked at it a great deal.

First point – removal of explicit ‘self’ should never have an effect on the compiler nor its optimization level – ever!

Second point – the merit of removing it would be A) saves typing; and B) helps deal with folks that get annoyed seeing something they perceive as “unnecessary” and “redundant.”

Why would I want to see “self” everywhere?

1. helps me quickly see the scope of a property as being within a block of code or within a class definition. This is very important to me as I am looking as code that was freshly generated from objc to Swift or code that I have not looked at in 6 months. It may be just me, but it makes it faster to scan it in my head. Just the way I am wired.

2. In situations that I want the property to be optional (nullable) but I wish to create a local var within a scope of an “if let” statement I have the option of using the form if let myVar = self.myVar { … }

If self is explicit everywhere than this pattern is not confusing.

This approach works for me in the case of objc-to-swift code.

I am not suggesting that others would agree with me – I am suggesting that there is room for more than one “approach.” This, to me, is the same as javescript- style {}s – the trailing open{ thing.

I don’t expect you to agree with me – but I hope you understand my view. I am asking this as an option – not as a default behavior.

• Jim

[alex-swiftify]

Hi Jim,

Thanks for your points - they make sense for sure. After looking in our issues tracker I see that your report to wish the self. prefixes kept is at least the second one, so we will consider adding this feature.

This will be definitely implemented sooner or later, and I am keeping your vote for this feature. I can't suggest any exact timeline though since this requires changes to both our converter, web API and all clients including the website, Xcode Extension and the Advanced Project Converter.

[jem5519]

Thanks Alex!

• Jim

From: Alex Petuschak [email protected] Reply-To: Swiftify-Corp/Swiftify [email protected] Date: Monday, September 10, 2018 at 12:18 To: Swiftify-Corp/Swiftify [email protected] Cc: Jim Malak [email protected], Author [email protected] Subject: Re: [Swiftify-Corp/Swiftify] Explicit Self (#3)

Hi Jim,

Thanks for your points - they make sense for sure. After looking in our issues tracker I see that your report to wish the self. prefixes kept is at least the second one, so we will consider adding this feature.

This will be definitely implemented sooner or later, and I am keeping your vote for this feature. I can't suggest any exact timeline though since this requires changes to both our converter, web API and all clients including the website, Xcode Extension and the Advanced Project Converter.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Swiftify-Corp/Swiftify/issues/3#issuecomment-419971892, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA1Psf_j2A-WwHETn8REBWbaQoiRmOApks5uZpDEgaJpZM4WhdNS.

[arlomedia]

I want to vote for this, too. I always use self for instance variables because it makes it easy to see the scope of the variable. In any case, I think the purpose of Swiftify is to convert from Objective-C to Swift, not to impose a coding style. So I feel like the most logical solution would be to leave the "selfs" as they are. If the developer chose not to use them in the original code, they won't be added, and if the developer chose to use them in the original code, they won't be removed.

[alex-swiftify]

Thanks, @arlomedia for your vote here!

The thing is, sometimes Swift requires the self. prefix when Objective-C does not. For example, a backing field (converted to a property) requires a self. prefix if a local variable or method with the same name exists.

Thus, at least we have a few cases when not adding a self. prefix in Swift breaks compilation. Anyway, it should be possible to keep self. prefixes if they exist in the Objective-C code, and I'll line up implementing this.