|
An installer that extends LibraryInstaller reaches for the Composer object
graph in ways the proxy did not answer: the download manager and the config,
the writable repository methods, a React promise as its own return value, and
`new Package(...)` from its supports() path.
* `Composer::getConfig`/`getDownloadManager` are dispatched, and both classes
become generated proxy stubs. Their reads and mutators answer from the Rust
entity; the surfaces needing stubs of their own (ConfigSourceInterface,
DownloaderInterface) stay explicit errors.
* The download manager's futures are driven to completion and handed back as
already-settled React promises, since PHP declares a non-nullable
PromiseInterface there. A promise a plugin returns is drained the same way:
settled yields its value, rejected re-raises, pending is an explicit error.
* Proxy stubs now carry the real class's constructor and ask the Rust side to
allocate the entity; reviving a stub for an existing entity binds the handle
without running it. Classes Rust cannot build name themselves in the error.
* The package proxy covers `Package`'s own setters, `CompletePackage`'s
metadata, `RootPackage`'s root-only state, and `BasePackage::$id`.
Link values and release dates still have no wire image, so the methods
carrying them remain explicit errors.
|
|
Emit the eleven stubs a subscriber plugin's object-graph calls reach
(BasePackage through RootPackage, the installed-repository hierarchy,
RepositoryManager, InstallationManager). The generator learns the member
kinds these classes need: builtin interfaces contribute no closure entries,
public static properties are materialized, public instance properties
forward through __get/__set, __toString forwards like a plain method,
__clone throws (proxy clone semantics are still an open design question),
and a subclass stub may add interfaces to its inherited surface.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
