Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove BlockBase.parent and BlockBase.next properties #45

Open
adroitwhiz opened this issue Mar 7, 2020 · 6 comments
Open

Remove BlockBase.parent and BlockBase.next properties #45

adroitwhiz opened this issue Mar 7, 2020 · 6 comments
Labels
API / interface Relevant to object structures and interfaces beyond serialization

Comments

@adroitwhiz
Copy link
Collaborator

Currently, the BlockBase class has the properties parent and next, which appears to be the IDs of its parent block and the next block in the stack respectively.

They don't appear to be used anywhere in the export code, and could make it much harder to manipulate the block tree.

It looks like they're modeled after the SB3 JSON structure, but given that sb-edit's API has already deviated from SB3, it's unnecessary to have them. Can/should these properties be removed?

@adroitwhiz
Copy link
Collaborator Author

/cc @PullJosh for your thoughts on this.

Also @towerofnix, parent and next are never accessed from BlockBase in the toSb3 code, right? I did a quick search through and didn't find any usage of them (it looks like the parent and next properties on the serialized blocks are calculated in other ways, which is good), but I may be missing something.

@PullJosh
Copy link
Collaborator

PullJosh commented Mar 8, 2020

Removing both makes sense. 👍

@towerofnix
Copy link
Member

@adroitwhiz Yep! It's safe to remove parent and next. I was slightly concerned about "next" but that block link is calculated by serializeBlockStack without reference to that property.

@towerofnix
Copy link
Member

@adroitwhiz Do you think it still makes sense to remove these relational properties? It's worth noting that it will have an influence on how "mutation" functions are written (for lack of a proper term, currently) — any function which performs static analysis and replaces input blocks with an equivalent but different set.

(We don't have any of those yet, and maybe we won't include any as built-in behavior, but sb-edit is ostensibly about manipulating projects including blocks, so it's worth considering for the sake of library-consuming code too. By removing parent and next, we would rule out certain code patterns for any modular "mutations". That could be a good thing! But I'm not sure.)

@towerofnix towerofnix added the discussion Looking for feedback and input label Mar 11, 2023
@adroitwhiz
Copy link
Collaborator Author

I think removing these would actually make it much easier to manipulate block stacks. It might even open up the possibility of placing the same block object in multiple stacks at once, which you can't do right now.

@towerofnix
Copy link
Member

Sure thing! I think the styles it rules out forces you into much cleaner ones as a consequence, which is a win in my books 📦

@towerofnix towerofnix added the API / interface Relevant to object structures and interfaces beyond serialization label Mar 11, 2023
@towerofnix towerofnix changed the title Purpose of BlockBase.parent and BlockBase.next? Remove BlockBase.parent and BlockBase.next properties Mar 11, 2023
@towerofnix towerofnix removed the discussion Looking for feedback and input label Mar 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API / interface Relevant to object structures and interfaces beyond serialization
Projects
None yet
Development

No branches or pull requests

3 participants