Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ApplicationVariants.all conversion #19

Open
AlexHuicu opened this issue Apr 7, 2020 · 5 comments
Open

ApplicationVariants.all conversion #19

AlexHuicu opened this issue Apr 7, 2020 · 5 comments

Comments

@AlexHuicu
Copy link

AlexHuicu commented Apr 7, 2020

In groovy we have
applicationVariants.all { variant -> //do stuff }

but, when converting to kotlin, the same block of code changes it's functionality:
applicationVariants.all { variant -> //do stuff }

This is due the fact that in groovy the closure given as a parameter to .all method can rename it's receiver (in this case it's renamed to variant).
BUT the same block code in kotlin is not a closure anymore, it becomes a lambda. The ".all" method called now is the one in the Iterable interface. (before it was calling the .all inside DomainObjectSet<> interface)

The real kotlin correspondent is:
applicationVariants.all { val variant = this //do stuff }.

I do not expect your converter to go so deep into the conversion, but please add this information to this wiki as it is very tricky to observe it

@AlexHuicu
Copy link
Author

AlexHuicu commented Apr 7, 2020

Further more:

applicationVariants.all {
          val variant = this
          variant.outputs.all { output ->
              //Do something with the output
         }
}

should be converted to

applicationVariants.all {
        val variant = this

        variant.outputs.all { 
              val output = this
              //Do something with the output
         }
}

To improve it further:
val output = this
should be changed to
val output = this as ApkVariantOutputImpl
Groovy has loose typing and output is automatically casted to it's actual type, but kotlin will see "option" as a BaseVariantOutput, which is not very usefull.

@bernaferrari
Copy link
Owner

Oh ohhh.. Makes sense. I can add a comment before it like // HEY THIS IS BROKEN or just add what you suggested, but I'm not sure how it would work in more complex scenarios. Do you have a few examples? It doesn't look too complex to implement.

@AlexHuicu
Copy link
Author

applicationVariants.all {
        val variant = this
        var flavor = variant.mergedFlavor
        var name = flavor.versionName
        var code =  getCustomCodeNumber()
        variant.outputs.all {
            this as ApkVariantOutputImpl
            versionNameOverride = name
            versionCodeOverride = code
            outputFileName =getOutputFileName(flavor,name,code)
        }
    }

@AlexHuicu
Copy link
Author

AlexHuicu commented Apr 7, 2020

This is the usage of the code I wrote above

@AlexHuicu
Copy link
Author

Something like:
"Check if the correct .all method is called. Does it belongs to DomainObjectSet interface? If not, please remove the named argument inside the closure," - and here maybe an url to the wiki where this problem is stated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants