It's relatively easy to accidentally make floorplanning slow by implementing a slow hooks method. Hooks never change, so we should just store them once they're computed like we do with geometry. Composite components already do this, populating a private dictionary using map_hooks when hooks is called. It's trickier for regular components because users directly implement the interface function hooks. Components should at least be able to opt in to caching hooks by implementing SchematicDrivenLayout._hooks instead. We can deprecate the current convention of implementing SchematicDrivenLayout.hooks.
Unfortunately I think the internal dictionary still needs to be converted back to a NamedTuple when hooks is called, at least until we make a breaking change.
We could also change hooks(::AbstractComponent, ::Symbol) to populate and access the dictionary, and consistently use that internally instead of getproperty on hooks(::AbstractComponent). This is more like what happens with CompositeComponents. That could be nice because at least for internal usage the hooks only get computed once. It would mean that revising the hooks method does nothing for already-instantiated components with cached hooks (and could lead to inconsistency between a user calling hooks(comp) and what happens internally), but revising geometry without reinstantiating components is already dangerous, so that seems acceptable.
It's relatively easy to accidentally make floorplanning slow by implementing a slow
hooksmethod. Hooks never change, so we should just store them once they're computed like we do with geometry. Composite components already do this, populating a private dictionary usingmap_hookswhenhooksis called. It's trickier for regular components because users directly implement the interface functionhooks. Components should at least be able to opt in to caching hooks by implementingSchematicDrivenLayout._hooksinstead. We can deprecate the current convention of implementingSchematicDrivenLayout.hooks.Unfortunately I think the internal dictionary still needs to be converted back to a NamedTuple when
hooksis called, at least until we make a breaking change.We could also change
hooks(::AbstractComponent, ::Symbol)to populate and access the dictionary, and consistently use that internally instead ofgetpropertyonhooks(::AbstractComponent). This is more like what happens with CompositeComponents. That could be nice because at least for internal usage the hooks only get computed once. It would mean that revising thehooksmethod does nothing for already-instantiated components with cached hooks (and could lead to inconsistency between a user callinghooks(comp)and what happens internally), but revising geometry without reinstantiating components is already dangerous, so that seems acceptable.