Create "Autobuild fields from enum type param" #181
Conversation
|
What's the purpose of a set of grades? That seems like a pretty odd use-case. |
It doesn't make sense for grades, but I was planning to think of a better example, eventually. I just started Typing A,B,C and thought "maybe notes of a chord", but didn't want to add sharps/flats, so I put grades. In reality, I would probably use something like this for a tagging system, since tag order doesn't matter and there's no need for multiple instances of the same tag |
|
A set of chords would be strange as well. A set of notes though would make some sense in a program that determines a chord. For brevity just A-G would suffice here. It ultimately doesn't matter but I always prefer when these examples make some sense. |
|
Went with the DnD 5e damage types, and chose a weapon with multiple types of damage |
| } | ||
|
|
||
| static function addFields(enumType:EnumType, fields:Array<Field>) { | ||
| final enumCT = Context.getType(enumType.module + "." + enumType.name).toComplexType(); |
There was a problem hiding this comment.
Build macros should avoid triggering typing (Context.getType here), especially in cases like that where it's avoidable. Best to keep bad practices out of cookbook
There was a problem hiding this comment.
I'm still pretty new to macros, and their best practices. Why should this be avoided, and what is the better way to do this?
There was a problem hiding this comment.
Oh I see, this line is no longer needed as the field isn't used
| try { | ||
| return switch Context.getLocalType() { | ||
| // Extract the type parameter | ||
| case TInst(getEnumType(_.get()) => enumType, _): | ||
| // Generate fields | ||
| addFields(enumType, fields); | ||
|
|
||
| fields; | ||
| case found: | ||
| throw 'Expected TInst, found: $found'; | ||
| } | ||
| } catch(e) { | ||
| // Catch thrown errors and point them to the failing class | ||
| Context.error(e.message, Context.currentPos()); | ||
| return Context.getBuildFields(); | ||
| } |
There was a problem hiding this comment.
I've found that this is my preferred way of handling macro errors, using throw everywhere, catching them and converting them to a Context.error that points to the line that triggered the macro. This is more informative to the dev utilizing the macro, but less informative to devs adding to or maintaining the macro, which I fix by temporarily commenting out the try/catch.
Would it be better or simpler to just use Context.error everywhere and remove the try? Alternatively should I trim down the error handling altogether and just have a simpler but perhaps more fragile example that just needs to work for the given usage example?
There weren't any great cookbook examples of the following things
@:autoBuildto generate fields. Even the manual page for autoBuild doesn't actually do anything practicalEnumValueI would also like to do this with
@:genericBuildas there aren't many great resources for that either, but first, this may be a bit too meaty for a manual. I'm wondering if I should break it down into smaller ones