always load all scripts in type/, command/ and handler/ #83
Conversation
rapus95
changed the title
rapus95
force-pushed
the
feature-genericload
branch
from
0103efa to
76dc200
Compare
| wd = walkdir(joinpath(@__DIR__, dir)) | ||
| commands = first(wd) | ||
| close(wd) |
There was a problem hiding this comment.
Since it only works with single level, it's simpler to use readdir with join = true instead.
There was a problem hiding this comment.
but readdir is single level only aswell. Am I misunderstanding it?
There was a problem hiding this comment.
Right, that’s why I suggested that. The code would be simpler since you don’t need to deal with the tuple from walkdir.
There was a problem hiding this comment.
but on the other hand I only need the files (not the directories) and walkdir already sorts by type of element. readdir returns files and directories arbitrarily mixed.
| @@ -24,29 +24,27 @@ import StructTypes | |||
|
|
|||
| const COMMAND_PREFIX = get(ENV, "HOJBOT_COMMAND_PREFIX", ",") | |||
|
|
|||
| function loadplugins() | |||
There was a problem hiding this comment.
Can we use underscore to separate words in function names? We try to follow the BlueStyle.
https://github.com/invenia/BlueStyle#function-naming
There was a problem hiding this comment.
But Julia itself suggests to use underscores only if the name is otherwise unreadable: https://docs.julialang.org/en/v1/manual/style-guide/#Use-naming-conventions-consistent-with-Julia-base/
:/
There was a problem hiding this comment.
Yes, I'm aware of that. But coding style standard is made for a reason. The BlueStyle is quite widely used in the industry, and it has a good balance of consistency that tends to work well for larger projects.
RE: naming convention, the standard Julia recommendation is too loose in my humble opinion-- when does one decide when the smashed-together name is starting to become unreadable? It's subjective.
|
Mmm… on a second thought, this would be broken if I have any source files from the same directories that must be loaded in a specific order, perhaps due to some dependency. There is no easy way to fix that… |
We could switch to making proper (sub)modules rather than bulk-including everything into the Main-Module on the other hand, only types can get dependency problems. So for all stateless functions that don't rely on custom types, that should work. What was the reason that |
|
Separating type definitions allows you to use it in multiple files without worrying about the order of the included files. It's simpler to just place it at the beginning of includes than trying to figure out how to order the rest of the files. |
|
But why do multiple independent plugins need the same types? 👀 This already suggests some coupling which makes me think whether it should be designed differently anyway. |
|
Right, independent plugins don't generally need the same types -- except in the case that a common set of utilities are made available for the plugin's, which is quite conceivable. In any case, I think we should work on #11. |
No description provided.