added more enum handling. Now enum of type works, and enum with set v… #93
Conversation
…alues will output a helper class method in enum to create from raw values
|
Just by looking at the code it gets pretty hard to follow the reasoning for all your cases, but the usage of sealed classes is definitely the way to go to convert complex Swift enums. What called my attention on your changes is the usage of Can you give some examples of the desired conversion Swift->Kotlin that you are trying to get? |
|
Hi
The main need really is to be able to initialize simple enums from raw values. I haven’t found a way to do that without the helper class.
As it is now, these become:
enum Number { case Five, Six, Seven }
enum Num:Int { case Five, Six, Seven }
enum Num:Int { case Five = 5, Six, Seven }
->
enum class Number {
Five,
Six,
Seven
}
enum class Num(val rawValue: Int) {
Five(0), Six(1), Seven(2);
}
enum class Num(val rawValue: Int) {
Five(5), Six(6), Seven(7);
companion object : ZEnumCompanion<Int, Num>(Num.values().associateBy(Num::rawValue))
}
Where the bottom one can be inited from a raw value.
tor
… On 18 Feb 2019, at 09:33, Angel G. Olloqui ***@***.***> wrote:
Just by looking at the code it gets pretty hard to follow the reasoning for all your cases, but the usage of sealed classes I definitely the way to go to convert complex Swift enums.
What called my attention on your changes is the usage of ZEnumCompanion. We should avoid custom types like this to keep the tool neutral.
Can you give some examples of the desired conversion Swift->Kotlin that you are trying to get?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#93 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB-irgb_ZoR73B8zkMdV_z5mAZErKH6zks5vOmVLgaJpZM4bATnR>.
|
|
I think I am still not understanding your usecase. For example, if you want to initialize the enum from a rawValue, wouldn't this fit your needs? With it, then you could use the enum like: Is your usecase different? |
|
Hi
That is exactly what I was wanting actually :-)
Just was writing something simular to message you.
Do you think it would be good to always output that code, or only if values are set in enum, or some kind of option or what?
tor
… On 18 Feb 2019, at 11:20, Angel G. Olloqui ***@***.***> wrote:
I think I am still not understanding your usecase. For example, if you want to initialize the enum from a rawValue, wouldn't this fit your needs?
enum class Num(val rawValue: Int) {
Five(5),
Six(6),
Seven(7);
companion object {
fun fromRawValue(rawValue: Int): Num? =
Num.values().firstOrNull { it.rawValue == rawValue }
}
}
With it, then you could use the enum like:
val myEnum = Num.fromRawValue(5)
Is your usecase different?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#93 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB-irhfXLHbwUtnCdKjTsSoLOAReAj8Qks5vOn6EgaJpZM4bATnR>.
|
|
I think giving this Which is not the same than the suggested Kotlin counterpart, and will therefore not translate properly... Maybe (I am not sure), we could try to detect that you are instantiating an enum in swift to convert it to a call to |
|
BTW, in your example with the |
|
Actually, to answer both questions at once, I had a pretty rough hack in my fork:
class func TransformKotlinFunctionCallExpression(_ tokens:[Token]) -> [Token] {
if tokens.count >= 5 {
if tokens[0].kind == .identifier && firstCharIsUpper(str:tokens[0].value) &&
tokens[1].kind == .startOfScope && tokens[1].value == "(" &&
tokens[2].kind == .identifier && tokens[2].value == "rawValue" {
// this is a real hack that converts <Enum>(rawValue:xxx) to <Enum>.rawValue(xxx),
var newTokens = [Token]()
if let origin = tokens[0].origin, let node = tokens[0].node {
newTokens.append(tokens[0])
newTokens.append(origin.newToken(.symbol, ".", node))
newTokens.append(tokens[2])
newTokens.append(tokens[1])
newTokens += tokens[4...]
}
return newTokens
}
}
…
- So it assumed an call with rawValue: label was an enum init.
… On 18 Feb 2019, at 11:37, Angel G. Olloqui ***@***.***> wrote:
I think giving this fromRawValue (or similar) makes sense indeed, since you can do the same with Swift out of the box. The only point I dislike is that from Swift you would do:
let myEnum = Num(rawValue: 5)
Which is not the same than the suggested Kotlin counterpart, and will therefore not translate properly... Maybe (I am not sure), we could try to detect that you are instantiating an enum in swift to convert it to a call to fromRawValue, but I suspect that this would not be possible since we do not have data types for the expression.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#93 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB-irpNHhke-Cl7Qu2_t5T-RzUT5O7JFks5vOoJugaJpZM4bATnR>.
|
|
All right, that is indeed what I suspected. I do not see any other way with the information about types we have... This piece of code, is it part of a plugin? I am doubting if we should provide the whole feature of |
|
It wasn’t really a plugin, but a file made to ease using a plugin in the future.
Not sure what is best, plugins or options for man conversion.
Some things would be very usefull for users of the system to just be able to turn on and off, a plugin just moves that process outside main converter.
tor
… On 18 Feb 2019, at 11:53, Angel G. Olloqui ***@***.***> wrote:
All right, that is indeed what I suspected. I do not see any other way with the information about types we have...
This piece of code, is it part of a plugin? I am doubting if we should provide the whole feature of fromRawValue (adding the method and converting the calls) as part of the main core or as a post processor plugin (so people could disable)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#93 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB-irmTXAJti-tI5qwlH6e0Gg0gaI-sGks5vOoYTgaJpZM4bATnR>.
|
|
Link to the issue tracking: #94 |
Yes, my idea behind the plugins was to provide hooks to add extra converters that not everyone will want to use and that are not part of the language itself. For example, a converter between RxSwift and RxKotlin or a converter between UIKit and Android widgets would fit on this category. But this one is on the limit, since the |
|
It seems like a core functionality; And also like something that will perhaps be part of kotlin in the future, so having it in the core makes sense.
tor
… On 18 Feb 2019, at 12:14, Angel G. Olloqui ***@***.***> wrote:
Some things would be very usefull for users of the system to just be able to turn on and off, a plugin just moves that process outside main converter.
Yes, my idea behind the plugins was to provide hooks to add extra converters that not everyone will want to use and that are not part of the language itself. For example, a converter between RxSwift and RxKotlin or a converter between UIKit and Android widgets would fit on this category.
But this one is on the limit, since the enum(rawValue:) is a Swift feature, from the language, but it does not exists in Kotlin itself. From Swift perspective it should be on the core, but from Kotlin perspective is an artificial companion object we are creating that might not be even wanted (for example if you have other initializers). My feeling so far is that it should be part of the core, since it is a Swift language feature, but I will think about it. What do you think?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#93 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB-irubwWrs0aEM9vhf7ZBT46ax9wY4zks5vOosSgaJpZM4bATnR>.
|
|
Take a look to my last comment on #94. If that works, it gets the best from both worlds. |
|
Just replied. Seems like a clean solution is possible.
tor
… On 18 Feb 2019, at 12:33, Angel G. Olloqui ***@***.***> wrote:
Take a look to my last comment on #94 <#94>. If that works, it gets the best from both worlds.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#93 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB-irgaEqvg3a5EQHFJw6-hTJvUBemVmks5vOo96gaJpZM4bATnR>.
|
|
Is this one still valid? I think with #97 this is no longer needed right? |
|
Hi, yes, #97 was the new simpler version I did. Great, I'll have a look at you changes! |
Adding this early before adding tests etc to get feeback; Is this a good idea or are there better ways to do it. Existing code now uses some "sealed class" that might be a better way?
Being able to init a simple enum from a raw value is very useful though, so some way of doing that is pretty important.