On 26/05/20 9:13 pm, Marcel Taeumel wrote:
> 1) Is "SystemPlatform" a fitting name? Alternatives: ExternalPlatform, 
> HostPlatform, ...

HostPlatform gets my vote. System is a much abused word :-).

> 2) Is it useful to document the known platform shorthands via 
> #isWindows, #isARM, etc.?

I prefer HostPlatform to be an abstract class with UnixHostPlatform or 
MacHostPlatform subclasses like in OSProcess. Having such concrete 
classes also makes it easy to create OS-specific code without having to 
use statements like 'name asLowercase ....' all over the image.

> 3) Is it necessary to access the last platform and the current platform 
> in that #systemPlatformChangedFrom:to: callback? Would 
> #systemPlatformChanged be sufficient?

The host platform changes only during cold start. why not name it 
coldStartOn: and pass the concrete class as an argument? Checking for 
platform change across every snapshot would be an overkill.

> 
> 4) What are your thoughts on #isCompatibleWith: and #isMoreSpecificThan:?

Not sure if they are really needed at this time.

> 5) Is it too specific to FFI to be in the "System" package? Can you 
> think of VM plugins that would benefit from such a detection? Not sure 
> about FileDirectory ... because those instances become invalid after 
> startup anyway.
No. Being able to reflect on host platform's properties will help 
platform-specific code degrade gracefully on unsupported hosts. While 
multiplatform capability is a good feature during development, I suppose 
most apps would run on the same host for years together.

Regards .. Subbu