[Lldb-commits] [lldb] 02d8813 - Add a comment in the SB API doc about keeping the SB API's lightweight. (#108462)

[via lldb-commits]

Author: jimingham
Date: 2024-09-13T10:18:03-07:00
New Revision: 02d8813820b1ebf3fae6993e677db269f0077272

URL: https://github.com/llvm/llvm-project/commit/02d8813820b1ebf3fae6993e677db269f0077272
DIFF: https://github.com/llvm/llvm-project/commit/02d8813820b1ebf3fae6993e677db269f0077272.diff

LOG: Add a comment in the SB API doc about keeping the SB API's lightweight. (#108462)

Added: 
    

Modified: 
    lldb/docs/resources/sbapi.rst

Removed: 
    


################################################################################
diff  --git a/lldb/docs/resources/sbapi.rst b/lldb/docs/resources/sbapi.rst
index cf32cc6c815581..4ca3909e0f2919 100644
--- a/lldb/docs/resources/sbapi.rst
+++ b/lldb/docs/resources/sbapi.rst
@@ -72,6 +72,17 @@ building the LLDB framework for macOS, the headers are processed with
 ``unifdef`` prior to being copied into the framework bundle to remove macros
 involving SWIG.
 
+Another good principle when adding SB API methods is: if you find yourself
+implementing a significant algorithm in the SB API method, you should not do
+that, but instead look for and then add it - if not found - as a method in the
+underlying lldb_private class, and then call that from your SB API method.
+If it was a useful algorithm, it's very likely it already exists
+because the lldb_private code also needed to do it.  And if it doesn't at
+present, if it was a useful thing to do, it's likely someone will later need
+it in lldb_private and then we end up with two implementations of the same
+algorithm.  If we keep the SB API code to just what's needed to manage the SB
+objects and requests, we won't get into this situation.
+
 Lifetime
 --------
 Many SB API methods will return strings in the form of ``const char *`` values.