You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, if one wants to document a custom component obtained using @mtkmodel, everything must be written by hand, in order to provide potential users with the proper arguments for the block.
However, one a instance of the block is created, plenty of information is available, yet the specifics are the one of the instance, not of the type.
Describe the solution you’d like
Ideally, I would like to be able to provide all the information about parameters, structural_parameters, ... automatically, since I'm pretty sure everything could be recovered by the @mtkmodel macro, leveraging description and other fields.
This looks much like $TYPEDEF from DocStringExtensions, but that doesn't seem to work on @mtkmodels.
I figured this functionality is not already available since there is no evidence of this in the standard library blocks.
Such an approach would be far much safer and easier for any developper or user.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently, if one wants to document a custom component obtained using
@mtkmodel
, everything must be written by hand, in order to provide potential users with the proper arguments for the block.However, one a instance of the block is created, plenty of information is available, yet the specifics are the one of the instance, not of the type.
Describe the solution you’d like
Ideally, I would like to be able to provide all the information about
parameters
,structural_parameters
, ... automatically, since I'm pretty sure everything could be recovered by the@mtkmodel
macro, leveragingdescription
and other fields.This looks much like
$TYPEDEF
fromDocStringExtensions
, but that doesn't seem to work on@mtkmodel
s.I figured this functionality is not already available since there is no evidence of this in the standard library blocks.
Such an approach would be far much safer and easier for any developper or user.
The text was updated successfully, but these errors were encountered: