Skip to content

New POC for Borrowing "non store" Child Objects from Parents#95

Draft
chrisgitiota wants to merge 3 commits into
mainfrom
feat/borrow-non-store-objects-poc
Draft

New POC for Borrowing "non store" Child Objects from Parents#95
chrisgitiota wants to merge 3 commits into
mainfrom
feat/borrow-non-store-objects-poc

Conversation

@chrisgitiota
Copy link
Copy Markdown
Contributor

@chrisgitiota chrisgitiota commented Feb 11, 2026

Warning

DON'T MERGE THIS PULL REQUEST

This PR is only a POC and will never be merged but may be the base for a future component

This PR provides a POC demonstrating how "non store" child Objects can be borrowed from Parent objects.

The POC main Move file is: borrow_non_store_obj_poc/sources/parent.move

The POC also introduces a BorrowedChild enum which can be used to abstract away multiple types of child objects (not having store ability) that shall be borrowed from their parent objects where childs have been send to their parents as been described here. This pattern is needed in case multiple object types (child types), not having store ability, shall be borrowed by multiple object types (parent types).

The BorrowedChild enum helps to collect all child dependencies in the borrowed_child module so that parent object implementations only need to depend on borrowed_child.

Motivation

The problem:

  • Usually in a scenario with P parent types and C child types, all P parent modules would need to implement the child specific transfers, receives etc. for C child types in their modules. This results in P * C almost redundant implementations.
  • Every time a new child type is added, all P parent modules would need to be extended accordingly.

How BorrowedChild solves this:

  • All child specific transfers, receives etc. actions are implemented in the borrowed_child module.
  • Instead of P * C implementations of child specific code, only
    • P implementations of BorrowedChild specific code and
    • One BorrowedChild implementation for the C child types are needed
  • Users access client specific types using functions provided by the borrowed_child module:
    1. Get BorrowedChild from parent module
    2. Extract BorrowedChild into child type and a Pledge (hot potato) using borrowed_child module functions
    3. Do something with child in the PTB
    4. Restore the BorrowedChild using child type specific functions provided by the borrowed_child module (Pledge will be needed for this)
    5. Put back the BorrowedChild to the parent

To see the borrow_non_store_obj_poc::parent::borrow_child() and borrow_non_store_obj_poc::parent::put_back() function in action, have a look into the test test_borrow_child_and_put_back() in the borrow_non_store_obj_poc/tests/parent_tests.move file.

Tests

The file borrow_non_store_obj_poc/source/parent_tests.move is used to test the implementation:

cd borrow_non_store_obj_poc
iota move test

Additionally the files deploy.sh and poc.sh in the borrow_non_store_obj_poc folder can be used for tests using real networks as been described in the project README.md file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant