Closed kornelski closed 1 month ago
I'm happy with squashing the commits as much as you'd like since I very rarely ever look at git history personally.
I'm happy with Gray.v
. What do you mean by renaming the (nevermind I see now in Gray
struct at the point of definition and then re-exporting it and renaming it across versions not being necessarymain
)?
I'm happy with HomPixel
becoming Pixel
. I thought about it when first naming {Hom,Het}Pixel
traits but I defaulted to being more descriptive, on the other hand I think this would be really useful if/when integrating with the image
and imageproc
crates since it is the same name as their current Pixel
trait which would reduce the amount code churn during a migration.
Oh I see now in the main
branch about the Gray_v08
and the Gray_v09
structs. Yeah that seems better if it makes rustc
give clearer error messages. I hope we can eventually remove the old Gray
type once the ecosystem has migrated, although I don't know how long that will take.
I see you've made changes to the main
branch, are we just using main
to make the final v0.8
release and then switching main
with the v0.9
branch to the make the first v0.9
release?
@ripytide The v0.9 branch deleting and re-adding v0.8 code throws away git history (git blame) for these files. Also the v0.9 branch does zig-zags with redesigns and renames. I'm thinking about squashing it all to a couple of commits.
Also some renames:
Gray.v
seems to be the best after all.v
for value is neutral, avoids specificity ofLuma
, and readability of.l
vs.1
. I've figured out that renaming the struct at the point of definition, and exporting under a differentpub use
name makes nicer error messagesGray_v08
vsGray_v09
, so renaming of the struct across versions is not necessary.Maybe
HomPixel
could be renamed to justPixel
? I suspect most users won't care about the heterogeneous case, and that will be a more straightforward name.