GetClasses
Monkey Forums/Monkey Programming/GetClasses
| ||
| Hello there, I have a question regarding GetClasses and #REFLECTION_FILTER. As far as I understand it is possible to reflect all classes compiled and used by your code. But what about other assemblies? I mean assemblies build by someone else. Is it possible to load them somehow and get classes that resides inside that foreign assembly? Using c# is is possible to load a Type or an assembly and get all the members out of that assembly. What is the monkey way to do this (if possible)? |
| ||
| It's not possible as some of the targets do not provide valid class interfaces for their compiled modules. I think that's one of the reasons why Monkey modules are not precompiled |
| ||
| From what I understand, you can't use reflection with external classes directly. You'd have to use a wrapper class of some kind. To this same effect (Unless this has changed), generic/template classes within Monkey aren't supported by reflection. I think that was part of the reasoning behind not making the standard "box" classes generic. Wait, hang on just a minute, do you mean external code, or another module? If it's external (Target native; C++, C#, etc) code you're talking about, then what I said above is the situation. If you're talking about another module made in Monkey, then you just need to add that module to the reflection filter using the '+=' operator (Or manually assign it with '='). Or you could use "*" as your filter if you want everything to be reflected. I don't think private elements (Private classes, functions, etc) can be accessed through reflection, though. (It's not like they're supposed to be, anyway) Okay, so it sounds like you're not too familiar with Monkey's mindset with regard to source code. Monkey is very modular. Every single file you make is considered a module. That module is separate from any other source code you have. By importing a module, you get access to that module and its public imports. You can import any module your compiler has been given access to. Your compiler's configuration file has a section in it about module directories. These directories are all places the compiler can look for a module. Standard behavior for Monkey when importing is for it to search the local directory of the current module before searching the global directories you specify. Once Monkey's compiler finds a module, you have access to it, plain and simple. Since global and local modules are seen as the same in Monkey, the reflection functionality doesn't actually care where you put the module. If you add a module to the filter, you're just telling the compiler that module should be reflected (From a Monkey perspective, not the native language it becomes). Where the module is, who wrote it, and how it relates to your modules directly doesn't matter. All that matters is that the module is imported. With all of that in mind, you should see how Monkey doesn't really have a sense of local and global, only available modules. But with this mindset comes a problem, Monkey doesn't compile modules individually. Once a module's imported, it's just compiled to the native language for the target, then placed in a source file with every other module (Which is then compiled by each target's SDKs/tools). But, since not all targets support compiled objects (Or similar), you end up with Monkey needing to compile the source each time. So, compiled modules aren't a thing in Monkey. You could technically use external tools to compile the library, but then it's out of the scope Monkey code lives in (Not to mention each platform would need a compiled version). You'd need to set that code up externally, and it's overall not worth it to most. This means the only way for someone to release a module is by releasing its source, or using external means. See: The documentation's "Programs and declarations" section. Your game or other project on the other hand is compiled as per usual. Releasing your games source code is up to you. But, if you at one point are willing to release a specific module you made for your game, this tends to be a lot easier with Monkey's modular design. This is not always the case, but with general purpose code you write (Input mapping for example), it usually is. TL;DR: Monkey code which is not external code / accessing external code (Target native source; not Monkey code), or generic/template based is always accessible by the reflector. If you want to use an external language's reflection functionality, you'll have to set it up like any other external code. If you haven't read it already, here's the official page for the 'reflection' module. |
| ||
| Wow, thank you for these overwhelming and perfect answers. Now I have sth. to think about. Thanks to you guys I found a solution for my problem, but what scares me is the fact that generics cannot be reflected. Are you absolutely sure? Is there a workaround for this? For example: to extend a generic class in a non generic class or sth. like that? UPDATE: I can confirm that generic classes cannot be reflected :( |
   |