Skip to content

Conversation

tamasvajk
Copy link
Contributor

No description provided.

@tamasvajk tamasvajk marked this pull request as ready for review October 10, 2024 13:09
@tamasvajk tamasvajk requested a review from a team as a code owner October 10, 2024 13:09
return
}

TODO()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think ideally we would minimise the number of mid-method returns, so

} else {
    TODO()
}

(without the return) would be better.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no clear preference. I think this will become a three-long if-else chain: we'd need to handle string.plus and the method call variant for the non-special cases.


extractExprContext(id, tw.getLocation(expression), callable, exprParent.enclosingStmt)
extractExpressionExpr(expression.left!!, callable, id, 0, exprParent.enclosingStmt)
extractExpressionExpr(expression.right!!, callable, id, 1, exprParent.enclosingStmt)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't we going to want to do these 3 lines in every case, after the when (op) has finished?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know, maybe. In many cases X + Y will be extracted as X.opPlus(Y), so as a method call. Would we want to handle this case together with the above? Maybe we could, because the child indices are the same.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good point. Maybe best to leave it as-is for now and possibly refactor later.

}
*/

private fun isFunction(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if something like isFunctionNamed would be clearer. And maybe add a comment

/**
 * True iff `symbol` is the function `packageName.className::functionName`
 */

(I'm not sure if I have the best punctuation in packageName.className::functionName OTTOMH)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The KE1 equivalent of this function has some extra parameters, such as nullability, so adding Named would not necessarily make sense.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK; I don't like the name isFunction, because it sounds like it tells you whether something is a function or something else (e.g. a class), but perhaps it's too early to pick the best name.

}

context(KaSession)
private fun KotlinFileExtractor.extractBinaryExpression(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a doc comment here would be useful, saying that sometimes these map to primitives like DbAddExpr, whereas at other times they are overloads (and give an example of how an overload of plus is defined in Kotlin).

@tamasvajk tamasvajk merged commit bc15f40 into github:ke2 Oct 11, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants