Generic ObjectId types for better type safety

[gswifort]

Proposal: Generic ObjectId Types for Better Type Safety

Problem

Currently, PyRx functions return ObjectId objects, but there's no type-level indication of what kind of database object they reference. This leads to potential runtime errors when trying to open objects with the wrong type:

# Current situation - no type safety
line_id = some_function_that_returns_line_id()  # returns ObjectId
circle_id = some_function_that_returns_circle_id()  # returns ObjectId

# Both of these compile, but only one is correct at runtime
line = Db.Line(line_id)    # ✅ OK if line_id actually references a Line
line = Db.Line(circle_id)  # ❌ Runtime error - wrong object type

Proposed Solution

Introduce generic ObjectId[T] types that encode the database object type at the type level:

from typing import Generic, TypeVar
from pyrx import Db

Object_T = TypeVar("Object_T", bound=Db.DbObject)

class ObjectId(Generic[Object_T]):
    """Generic ObjectId that knows what type of object it references"""
    pass

# Usage examples
def get_line_id() -> ObjectId[Db.Line]:
    pass

def get_circle_id() -> ObjectId[Db.Circle]:
    pass

# Type-safe object creation
line_id = get_line_id()      # ObjectId[Db.Line]
circle_id = get_circle_id()  # ObjectId[Db.Circle]

line = Db.Line(line_id)         # ✅ Type checker knows this is safe
circle = Db.Circle(circle_id)   # ✅ Type checker knows this is safe
line = Db.Line(circle_id)       # ❌ Type checker catches this error!

Benefits

1. Type Safety: Catch type mismatches at development time instead of runtime
2. Better IDE Support: IntelliSense can provide more accurate suggestions
3. Self-Documenting Code: Function signatures clearly indicate what types of objects they work with
4. Refactoring Safety: Type checker helps ensure correctness when changing code

Example API Changes

# Current (untyped)
class Database(PyRx.RxObject):
    def modelSpaceId(self, /) -> ObjectId: ...

# Proposed (typed)
class Database(PyRx.RxObject):
    def modelSpaceId(self, /) -> ObjectId[PyDb.BlockTableRecord]: ...

[CEXT-Dan]

How would that work for derived types? The way I check the type is use ObjectId.isDerivedFrom

        db = Db.curDb()
        line = Db.Line(Ge.Point3d(0,0,0),Ge.Point3d(10,0,0))
        id = db.addToModelspace()
        if id.isDerivedFrom(Db.Curve.desc()):
            curve = Db.Curve(id)

[gswifort]

Oh, so this would be caught by some linter?

Yes.

What would need to be added to make this happen ?

We need to change all the __init__ definitions as in the Line class above (this seems easy to do in a stub generator). Then we'll need to complete all the methods that return ObjectId, e.g.:

class Database(PyRx.RxObject):
    def modelSpaceId(self, /) -> ObjectId[PyDb.BlockTableRecord]: ...

This probably requires a lot of C++ work.

[CEXT-Dan]

I don’t specify the return types in C++, this is generated by the compiler and BOOST
I think all the return types can be overridden in return types database though

[gswifort]

Yes, that's right. But it's probably still a lot of work.

[gswifort]

I don’t specify the return types in C++

Not only the return types need to be completed, also the types of function parameters, e.g.:

class Database(PyRx.RxObject):
    def setClayer(self, val: ObjectId[PyDb.LayerTableRecord], /) -> None: ...

[CEXT-Dan]

Please don’t start yet, I have not agreed to this yet, also return_types get overwritten

[CEXT-Dan]

Return types.json is generated

I’m still on the fence about this.

• Personally, I don’t really want to change the stubs again, it’s just now getting stable with a few odd fixes here and there.
• Does this mean we have to label every ObjectId type in the system? Brx, Bim and Civil?
• I don’t fully understand how this will impact users, cost / benefit.

[gswifort]

It's not necessary to mark each one for this to work. The unmarked ones will simply be treated as ObjectId[Any].

I don't see any costs; the benefits are that errors are detected while writing the code, not at runtime. I can immediately see what a given function returns without reading the documentation – for example, here I don't know what ID I should pass:

[CEXT-Dan]

Cost

(gci -include *.cpp,*.h -recurse | select-string 'PyDb.ObjectId').Count 796 arguments
(gci -include *.cpp,*.h -recurse | select-string PyDbObjectId).Count 3626 return types

So probably around 3500 entries, that’s months if they are hand edited. I haven’t even finished the return types for tuples yet, or tests, or a bunch of the other “no fun” stuff that needs to be done. You will have to forgive my lack of enthusiasm

[gswifort]

You don't have to do everything at once. You don't even have to finish it. Using the setSectionViewStyle example, after knowing which object to pass to the function, I'd like to add the ObjectId type so I don't have to search for it again in the future.

[gswifort]

Return types.json is generated

Does that mean I shouldn't edit it?

[CEXT-Dan]

Ok we can try it. I think the doc string generator should log the signatures that have not been updated.

Does that mean I shouldn't edit it?

Right, the master is in the SQLite database, I use SQLiteStudio to add entries.

The original doc string generator used to pull directly from the SQLite database, I had to change that because BricsCAD is not compatible with SQLite, so I export the tables to json. The SQLite database ensures a unique docstring ID, and I can run quick queries. It’s not great, but it works