Standard for Dragonfly module

[ghost]

Introduction

Reusing someone else's code is good programming practice.

It will be great if the Dragonfly developers, who do not want to add their changes to the Dragonfly code (for various reasons), will create their add-ons according to some standard. For example using the "plugin" package.

My suggestion

When I want to write a separate module for Dragonfly, I make a separate package with init functions. Then, in main.go, I import the modules I need using the "stub"

What's you mind about it? Wait for comments

[Thunder33345]

Please be more in depth, whats a "stub" in this context?

Is there a need of a standard? every module is going to need different things, just read the doc to find what's the setup functions and what it takes

I fail to see the benefits of having a standard, reading docs is not that hard

Are you aware about that events handler are singular? even if i can have a standardized setup functions, you still need to be responsible of recieving and forwarding events to the module...

[T14Raptor]

I don't really understand what this issue is for exactly

[RestartFU]

are you suggesting to add a plugin like system? Because we've talked about doing this before on the discord and I don't think that's ever gonna be a thing

[ghost]

Please be more in depth, whats a "stub" in this context?

For example:

import _ "github.com/user/df-module"

Is there a need of a standard? every module is going to need different things, just read the doc to find what's the setup functions and what it takes

I think that the standard will make it possible to make a single system of initialization of modules, which will make it easier for developers to understand the code. For some things, I think you can make special "interfaces". For example: MultiHandler.

I fail to see the benefits of having a standard, reading docs is not that hard

It will become even easier :)

Are you aware about that events handler are singular? even if i can have a standardized setup functions, you still need to be responsible of recieving and forwarding events to the module...

This is indeed a problem for the standard. Maybe you should change the handler? In future versions

[ghost]

I don't really understand what this issue is for exactly

Please read my answer above :)

[ghost]

are you suggesting to add a plugin like system? Because we've talked about doing this before on the discord and I don't think that's ever gonna be a thing

This is not a plugin system at all and I don't see any similarities. I remind you, the plugin is a separate compiled file. I offer modules that are included in main.go (above I gave an example of how) and build together with main.go.

[ghost]

Does it make sense for me to write something, for example?

[Sandertv]

While fundamentally, I agree with Reusing someone else's code is good programming practice.. I don't feel like a standard like this necessarily achieves that. Currently, people can simply expose their own handlers and libraries so that other people can use them in whichever way they want.

Say, for example, you have your own player.Handler that does something when the player moves: For example, it stops movement under a certain circumstance. The player.Handler of the library you import might have a handler for movement too, which you would only want to call if you don't already stop movement at a given moment. This kind of behaviour requires control, and you can't obtain that kind of control with an automatic system like you described.

I think the fundamental thing with Dragonfly is to understand that it is primarily aimed at developers looking to write a full server. Re-using code is good, but a system that (at least to an extent) functions similarly to plugins is just not necessarily something we're after because it limits control over the behaviour of libraries.

[Sculas]

Reading your suggestion in the issue, this kind of feels like mixins. Is that what you mean?

[Thunder33345]

This is indeed a problem for the standard. Maybe you should change the handler? In future versions

I think dragonfly's stance on multi handler is as clear as it can it, there's only going to be a single handler

With that said, there's nothing stopping you from making your own handler that can support multiple handlers, it's just not part of the scope of df(or should have been something that's default)

There's merits to single handler, this allows the developer to configure events in perciese order they intended, with full programming capabilities, like said by sander

In order to impliment such systems, there would be 2 possibilities:

• It turned out like a mess in PMMP, just look at priorities level bandage, the whole thing is gonna be undefined if you have the same priority
• It turns out maybe usable, but at what maintanance cost that would be tacked into the core?

[Thunder33345]

Here's another question: Is this necessary to be part of dragonfly? you can easily establish your own multi handler and module standards, if other people agrees to it, they will follow it regardless if it's official or not..

In my opinion if it can exist without being part of dragonfly, it shouldnt be part of dragonfly

[ghost]

In my opinion if it can exist without being part of dragonfly, it shouldnt be part of dragonfly

I think this is the right decision. I close the Issue, because I think that the point in this matter has been put