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

Object Function Overloading #381

Open
genusistimelord opened this issue Jan 4, 2022 · 4 comments
Open

Object Function Overloading #381

genusistimelord opened this issue Jan 4, 2022 · 4 comments

Comments

@genusistimelord
Copy link
Contributor

Maybe Add to Module to have Object call overrides than will run a set function for checks and returns similar to module.field_fn but as object_fn.

So maybe module.object_fn(Type_Npc , "obj", Npc::handle_object_lookup)?;

pub fn handle_object_lookup(&mut self, key: String) -> Value {}

struct Type_Npc {
  obj: rune::runtime::Object,
}

So when someone calls

obj.x

then x will be sent as the key for lookup and return. this way we could lookup data and error it out if it doesn't Exist on the script side which would allow for slightly more dynamic structures. OR static Data returns that don't need to be pre-made or saved into the struct.

As request by "Granny Joe" on Discord. For more information or if I'm a bit wrong on what they are asking Ill link them here so they can fix anything missed in comments.

@LoopyAshy
Copy link

LoopyAshy commented Jan 4, 2022

Although This seems like a valid solution to the issue. I would prefer something like this:
Potentially Add a ability to either have a custom getter/setter handler which takes the requested field as a string argument.

OR

Add the ability to create at types at runtime the same way you import rust types into modules. However due to it using runtime data it would allow you to basically create the layout of the generated struct along with its name, its fields (and types) and the usual stuff such as methods and protocols which is attached to the generated struct.

example of how that may look is:

let mut module = Module::new();
module.dyn_ty("NPC")
      .add_field::<String>("name");
      .add_field_with_default::<i32>("health", 69);

This could use a system very similar to Object/Struct however it would allow rust functions (and hopefully even rune functions) to be attached exclusively to the generated struct and could even allow compile time checks for spelling mistakes and similar issues.

I can see this being possible already in the same way that the derive(Any) proc macro works but that is not user friendly whatsoever and honestly more work than it is worth.

Now I can see this being a issue to implement due to the fact it could require specific changes to rune to function but it would be a potentially powerful feature and definitely something I would be more than grateful to have.

@genusistimelord
Copy link
Contributor Author

I do like the dynamic type creation idea better than our previous discussion. So returning a dynamic type like this would just return a rune::runetime::Object of the rune struct.

@LoopyAshy
Copy link

LoopyAshy commented Jan 4, 2022

I do like the dynamic type creation idea better than our previous discussion. So returning a dynamic type like this would just return a rune::runetime::Object of the rune struct.

Definitely seems like the easiest course of action, however I'd say a bit of a more specialised variant which also says the dynamic type's name and such for better identification.

@LoopyAshy
Copy link

LoopyAshy commented Jan 4, 2022

I will add as a side note (not the original point of the idea) but I spend a lot of time in game development and the rust game engine I am most invested in is definitely Bevy.
Bevy is doing its best to add a system to allow scripting languages easy access to information at runtime and even generate structs at runtime via reflection. In my honest opinion this is a absolutely fantastic area rune could be used for. Adding such features as modding support.
This feature being requested would also help make that a possibility in the future.

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

No branches or pull requests

2 participants