Improve metaclass logic#1189
Conversation
slozier
left a comment
slozier
left a comment
There was a problem hiding this comment.
I'm glad one of us is good at writing tests! Just some minor comments, looks goot to me otherwise.
| return obj; | ||
| // ------------------------------------------------------------------------ | ||
|
|
||
| static Func<CodeContext, CodeContext> getClassCode(CodeContext/*!*/ context, FunctionCode funcCode, Func<CodeContext, CodeContext> body) { |
There was a problem hiding this comment.
Not that you need to change this, but I usually PascalCase local functions. We should probably adopt a convention. I'll have to check if there's an editorconfig rule for this.
There was a problem hiding this comment.
I usually use dromedaryCase for anything local (inc. functions) to distinguish it from regular methods. But I am happy to adopt any convention; .editorconfig check would be good. However, I may have committed my dromedaryCase in some other places already, though now I can't find it...
There was a problem hiding this comment.
I managed to define an .editorconfig rule, unfortunately it seems like the file has to be open in VS for it to display an issue. Anyway, I opened a bunch of files to see if it would find rule violation and there are indeed a few. An exception to the rule might be the helper methods like link.linkWindows where the casing matches the public parent. Another interesting case is where the local function is essentially replacing lambda (e.g. in SurrogatePassErrors). I assume I would have dromedaryCased the lambda? I guess it's not as clear cut as I thought it was.
2 participants
It addresses a part of the problem reported in #1154 (duplicate calls to
__prepare__) and several other related issues. Off the top of my head:__init____prepare__,__new__,__init__by metaclasses__prepare__on a function used as "metaclass"