For the next major version, we may consider a new naming scheme that is simpler for downstream consumers, e.g.
- Modules
Graphics -> GraphicsBasePlatformGraphics -> Graphics (re-exporting everything needed, including Utils)
- Types
Image (+ BufferedImage) -> ImageProtocolPlatformImage -> Image
Ideally, we would want parity between the different backends and polyfill as needed, so that they can be used interchangeably. It should not matter whether a CoreGraphicsImage or a CairoImage is used and portable code should not have to deal with this distinction, i.e. Image should always refer to the "one true" image type.
Perhaps introducing a wrapper layer (e.g. have Image and GraphicsContext be shared types that internally uses a platform-specific backends) would be worth looking into, to avoid accidentally leaking platform-specific implementation details if the platform-specific types implement something not declared in the protocol. This might require renaming the protocol for clarity (e.g. BackingImage, ImageBackend or similar).
For the next major version, we may consider a new naming scheme that is simpler for downstream consumers, e.g.
Graphics->GraphicsBasePlatformGraphics->Graphics(re-exporting everything needed, includingUtils)Image(+BufferedImage) ->ImageProtocolPlatformImage->ImageIdeally, we would want parity between the different backends and polyfill as needed, so that they can be used interchangeably. It should not matter whether a
CoreGraphicsImageor aCairoImageis used and portable code should not have to deal with this distinction, i.e.Imageshould always refer to the "one true" image type.Perhaps introducing a wrapper layer (e.g. have
ImageandGraphicsContextbe shared types that internally uses a platform-specific backends) would be worth looking into, to avoid accidentally leaking platform-specific implementation details if the platform-specific types implement something not declared in the protocol. This might require renaming the protocol for clarity (e.g.BackingImage,ImageBackendor similar).