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

Multiple Inheritance #1

Open
bigfug opened this issue Apr 30, 2020 · 0 comments
Open

Multiple Inheritance #1

bigfug opened this issue Apr 30, 2020 · 0 comments
Assignees

Comments

@bigfug
Copy link
Owner

bigfug commented Apr 30, 2020

Currently objects are arranged in a hierarchy using the parent field to denote the parent of each object. Parent can be OBJECT_NONE (like on the Root object) but generally every object has a parent.

An object inherits all the verbs and properties of all its ancestors, which is powerful but requires careful planning of where to put these attributes.

Multiple inheritance (having more than one parent) would be useful to divide up functionality. Stunt does it by having parents() and chparents() functions.

I'm not too worried about the performance of doing this but I wonder if there is a cleaner way rather than just lumping bunches of objects into a complex hierarchy.

Mixins

One idea would be to use a mixin style system where objects continue to have a single parent, which then becomes useful for categorisation so Car.parent = Vehicle and Car.is_child_of( Vehicle ) == true but we can add functionality:

Box:add_mixin( Lockable ) -- box is now lockable
Door:add_mixin( Lockable ) -- door is now lockable

User:add_mixin( BuilderTools ) -- allow user access to create/dig verbs
User:rem_mixin( BuilderTools ) -- user is no longer allowed to build

Objects would still inherit verbs and properties from mixin objects, and it might be a nice idea that add_mixin() calls MixinObject:mixin_added( DestObject ) to initialise properties.

It would seem to make things a bit easier to understand but probably a bit harder to design.

Another benefit would be that a cleanly designed mixin should be able to be exported and imported between systems.

Implementation

Internally this would require an extra text field in the database that contains a comma delimited list of mixin object numbers. As we'd already have the object loaded into memory, I don't think having a separate table is really necessary.

ODB will load the field and convert it into an array of ObjectId's

Object->findProp and Object->findVerb would need to search the array of mixins

@bigfug bigfug self-assigned this Apr 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant