>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3553397. --> Reported by: [tedbow](https://www.drupal.org/user/240860) Related to !384 >>> <h3 id="overview">Overview</h3> <p>I was under the assumption that if we documented some class as @internal that classes that we didn't document as such were not considered internal</p> <p>But chatting with @wim leers I learned that is not the case.</p> <blockquote><p>Our API is what&rsquo;s in canvas.api.php and in other explicit docs.</p></blockquote> <p>This might just be common practice in contrib and I am not keeping up in which case maybe we can just close this issue but in case it is not I think we should make it clear. </p> <p>For example, \Drupal\canvas\PropSource\PropSource::parse. This class is <strong>not</strong> marked as internal but also I could not find it in any of our docs. So it seem we do <strong>not</strong> consider it part of API and are free to remove at any time.</p> <p>But if I was another contrib developer and I wanted to implement \Drupal\canvas\ComponentSource\ComponentSourceInterface which is in our docs I very likely would look at \Drupal\canvas\Plugin\Canvas\ComponentSource\GeneratedFieldExplicitInputUxComponentSourceBase to see how things would in an example. GeneratedFieldExplicitInputUxComponentSourceBase is marked as @internal so I would know not to extend that but I would see that calls PropSource::parse. Since that is not marked as internal I would probably assume I could call that. I would not think to search the docs for this class to determine if I could use it.</p> <h3 id="proposed-resolution">Proposed resolution</h3> <p>Either document that our very clearly somewhere what we consider to be an API or just add @internal to classes we don't consider to be our API(which would be most classes?)</p> <h3 id="ui-changes">User interface changes</h3>