This discussion is archived
1 2 Previous Next 16 Replies Latest reply: Dec 30, 2009 11:33 AM by 843798 RSS

How to make a simple Plugin system?

843798 Newbie
Currently Being Moderated
hey guys, first let me say I see very much hostility here, and I'm not here to annoy anyone, so if you don't feel like answering then simply don't.

I want to design a simple Plugin System for my application. I think what I need is a bit of reassurance and redirection if I'm making wrong assumptions.

here is the stages I see:

1. the system has a HashMap<String,PluginTypeData> that holds types of plugins, and the folder of the application that hold the libraries files for the plugins among other details.
(this would be saved in the application configuration file)
2. once the application starts/on request the system would load the libraries into the memory.
3. in each library there should be a file that holds the textual fully qualified name of the classes that this plugin would require to operate properly.
4. the objects in the library would have to be familiar to the application, therefore they must implement or extend a known base object from the application, and once loaded a reference to that known base object is assigned to the new object.
5. and then if I want to load a GUI component from the plugin I just get it from the reference.

lets start with how does that sound? I would like to get a feed back, just a serious one please, that may help me understand any mistakes I might be doing, and not just to understand that I'm wrong....

Thanks in advance,
Adam Zehavi.

Edited by: Adam-Z. on Dec 19, 2009 12:34 AM
  • 1. Re: How to make a simple Plugin system?
    843798 Newbie
    Currently Being Moderated
    Adam-Z. wrote:
    hey guys, first let me say I see very much hostility here, and I'm not here to annoy anyone, so if you don't feel like answering then simply don't.
    Pretty hostile way to open, isn't it? "Here, let me admonish you all up-front" basically. If you're referring to [this thread|http://forums.sun.com/thread.jspa?threadID=5419973&tstart=0], do bear in mind that the OP is the only person being hostile, because he didn't like having flaws in his question pointed out.
    I want to design a simple Plugin System for my application. I think what I need is a bit of reassurance and redirection if I'm making wrong assumptions.

    here is the stages I see:

    1. the system has a HashMap<String,PluginTypeData> that holds types of plugins, and the folder of the application that hold the libraries files for the plugins among other details.
    (this would be saved in the application configuration file)
    2. once the application starts/on request the system would load the libraries into the memory.
    3. in each library there should be a file that holds the textual fully qualified name of the classes that this plugin would require to operate properly.
    4. the objects in the library would have to be familiar to the application, therefore they must implement or extend a known base object from the application, and once loaded a reference to that known base object is assigned to the new object.
    5. and then if I want to load a GUI component from the plugin I just get it from the reference.

    lets start with how does that sound? I would like to get a feed back, just a serious one please, that may help me understand any mistakes I might be doing, and not just to understand that I'm wrong....
    Hmmm. Do you mean that all plugin config details - the FQN of each of the plugin classes - are configured directly in the app? That may not be necessary. You could bundle a properties file in each plugin jar that gives it's own plugin entry point's FQN. That way, plugins can be discovered. Not sure why you'd need to explicitly configure the FQNs of a plugin's dependencies, though. Other than those points, this seems reasonable enough, although a common practice in these things is to load each plugin in a classloader of its own.

    But is this a mechanism you actually need, or are you writing it as an exercise? Because there already exist several such mechanisms you can just reuse, rather than re-inventing the wheel, if you just need the functionality somehow.
  • 2. Re: How to make a simple Plugin system?
    843798 Newbie
    Currently Being Moderated
    well, I'm building a bridge between a J2Me platform I'm designing and J2Se Tool pack to efficiently save audio and images data to perform multiple actions on the phone while loading the data into the application via the platform.

    The plugins I'm interested are actually the data types, I would like each of the data types to be a plugin, the thing is with J2Me is that it does not support external jars in the application build path, and while I try to use the same DataChunk to save itself and load itself, from the same physical object, on both platforms, to prevent later IO mistakes that might pop up, there is no point in keeping all the plugin data in a file, only the imperative data, and since I must implement the new DataType itself on the J2Me platform and inherit it on the plugin package to be used as a plugin with Swing GUI and stuff....

    I know this is a bit much, but I don't think making the plugin mechanizem should be too hard besides, its nice practice with loading classes dynamically, and it's a new approach I would like to see what would come out of it... so if there are any points you can give me, it would be a pleasure.

    Thanks,
    Adam Zehavi.
  • 3. Re: How to make a simple Plugin system?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    Adam-Z. wrote:
    hey guys, first let me say I see very much hostility here, and I'm not here to annoy anyone, so if you don't feel like answering then simply don't.
    Being hostile or not and wanting to post or not are two different things.
    I want to design a simple Plugin System for my application. I think what I need is a bit of reassurance and redirection if I'm making wrong assumptions.

    here is the stages I see:

    1. the system has a HashMap<String,PluginTypeData> that holds types of plugins, and the folder of the application that hold the libraries files for the plugins among other details.
    (this would be saved in the application configuration file)
    What is "PluginTypeData"? Specifically what behavior and data will it have?
    2. once the application starts/on request the system would load the libraries into the memory.
    Why not load when needed?
    What happens when the configuration file is wrong?
    3. in each library there should be a file that holds the textual fully qualified name of the classes that this plugin would require to operate properly.
    Library? If you have a configuration file then it should specify the name. Nothing else is needed. (There are self determining designs but you said you wanted it to be simple.)
    4. the objects in the library would have to be familiar to the application, therefore they must implement or extend a known base object from the application, and once loaded a reference to that known base object is assigned to the new object.
    Base class or interface.
    5. and then if I want to load a GUI component from the plugin I just get it from the reference.
    That is really specific from the general comments above.

    For example if you create a plugin library for GUI widgets it is significantly different than a plugin library of element management interfaces with a configuration GUI.
    lets start with how does that sound? I would like to get a feed back, just a serious one please, that may help me understand any mistakes I might be doing, and not just to understand that I'm wrong....
    Plugins must do some specific task. You need to start with that.
  • 4. Re: How to make a simple Plugin system?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    Adam-Z. wrote:
    ...so if there are any points you can give me, it would be a pleasure.
    Have you implemented at least two of these already? Generalizing from multiple cases is easier than a single case.
  • 5. Re: How to make a simple Plugin system?
    843798 Newbie
    Currently Being Moderated
    First, thank you for your reply.

    since I first posted, I have managed to get a clearer sense of what the demands of what I want to accomplish require.

    first I have a couple of data level, where each is based on another, for example I have a plugin that creates objects of type A and inheritances of it,
    then I need a plugin that creates objects of type B which are based on types of A, and then I need to create C objects that based on both types B and A and some other data, which would be given by the user.

    After hopefully making myself clearer,
    What is "PluginTypeData"? Specifically what behavior and data will it have?
    I hope it is clearer now what I meant with that, type A or B or C, or any other type,
    and since I want to save them all into one file, I need to save them in stages, first A, then B and finally C.
    2. once the application starts/on request the system would load the libraries into the memory.
    Why not load when needed?
    What happens when the configuration file is wrong?
    on request, I meant when needed, not when the user requests it.
    and if the configuration is wrong then it would report something is wrong with the plugin and would post the error into the application console.

    3. in each library there should be a file that holds the textual fully qualified name of the classes that this plugin would require to operate properly.
    Library? If you have a configuration file then it should specify the name. Nothing else is needed. (There are self determining designs but you said you wanted it to be simple.)
    well since I try to build a bridge between the J2Me and J2Se platforms, and since there are some limitation to the J2Me platform* I needed to define a few things in a few objects, it was possible to make all the data to fit into one object, but it would make that object too heavy for the J2Me platform (besides I rather having two objects it felt more OOD right way to do), where one is a type definer that can produce only one instance of this object although it is inheritable, that defines the type of the object that this plugin produces, together with an abstract method that returns a J2Se GUI component to edit that data on the desktop computer, and the other method return the data holder object itself of type A,B or C, with different ways to create it.

    * The limitation I'm facing are:
    1. I cannot import into the build path of the project any external libraries.
    2. The J2Me platform runs on the JRE 1.3.
    3. J2Me does not support serialization, which is the real pain in the S.

    urrrr... so hard to explain this in words, this is terrible.
    here is the highlights of the most basic type class:
         public abstract static class J2MeDataChunkType {
              private final int value;
              private Object panel;
              
              private void loadSubTypes() {
              }
              
              public Vector getSubChunks() {
                   return subTypesList;
              }
              
              public J2MeDataChunkType(int value) {
                   this.value = value;
                   if (typeList == null)
                        typeList = new MapRef();
                   typeList.add(dataChunksName.elementAt(value), this);
                   loadSubTypes();
              }
              public int getChunkTypeValue() {
                   return value;
              }
              
              public Object getPanel() {
                   if (panel == null)
                        panel = _generatePanel();
                   return panel;
              }
              
              public abstract J2MeDataChunk _generateChunk();
              public abstract J2MeDataChunk _generateChunk(DataInputStream dis) throws IOException;
              
              public Object _generatePanel() {
                   throw new IllegalModeException("No component defined for type");
              }
         }
    there are a few advantages to this such as memory usage on the phone among other things, although it makes the plugin making process a bit more complicated, and makes a few extra classes on the J2Me platform which is very annoying but necessary, and in the long run it would actually save me some classes, since they would all be defined in data in files and would be created on the fly on the phone.

    so what I need to have in the configuration file is a reference to which type of object this plugin is based on A,B,C, or maybe a future D type.
    and the fully qualified name of the object that generates the GUI for editing this data type.
    4. the objects in the library would have to be familiar to the application, therefore they must implement or extend a known base object from the application, and once loaded a reference to that known base object is assigned to the new object.
    Base class or interface.
    well, in my case it would extend an abstract class from the J2Me platform, maybe two object I'm still thinking about a better implementation so the plugin would be more simple, consist of only one object, that needs to be loaded.
    5. and then if I want to load a GUI component from the plugin I just get it from the reference.
    That is really specific from the general comments above.
    well I think not really, since the base object that the plugin inherit from the J2Me platform, has an abstract method to return an Object which the application casts into an EditingPanel for the J2Se application to edit the data type.
    Plugins must do some specific task. You need to start with that.
    well, it does, it edits the data of a specific type, saves it on a J2Me format, and that that.

    now I have two basic data types, one is an Image data chunk, and the other is an Audio data chunk, the Image data chunk is composed of two more basic chunks, that define the images sizes and crops the image on the phone, and loads the desired audio type that the phone supports, on run time.

    I did not make these editors/creators plugins yet, I wait until I would get a full sense of what am I going to do... like you said:
    Generalizing from multiple cases is easier than a single case.
  • 6. Re: How to make a simple Plugin system?
    843798 Newbie
    Currently Being Moderated
    I have to be honest, it took me over an hour to post this reply because it got me thinking about a few things, and I think I got most of this figured out, I'll try to make this and post back with future realization and questions, Thank you so much for your help...
  • 7. Re: How to make a simple Plugin system?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    Adam-Z. wrote:

    first I have a couple of data level, where each is based on another, for example I have a plugin that creates objects of type A and inheritances of it,
    then I need a plugin that creates objects of type B which are based on types of A, and then I need to create C objects that based on both types B and A and some other data, which would be given by the user.
    And this will be required for every single plugin in exactly the same way? If not then each plugin should include a factory.
    After hopefully making myself clearer,
    What is "PluginTypeData"? Specifically what behavior and data will it have?
    I hope it is clearer now what I meant with that, type A or B or C, or any other type,
    and since I want to save them all into one file, I need to save them in stages, first A, then B and finally C.
    "Save" them? I suspect even if the creation pattern is the same then requiring the plugin to do it would be easier.
    3. in each library there should be a file that holds the textual fully qualified name of the classes that this plugin would require to operate properly.
    Library? If you have a configuration file then it should specify the name. Nothing else is needed. (There are self determining designs but you said you wanted it to be simple.)
    well since I try to build a bridge between the J2Me and J2Se platforms, and since there are some limitation to the J2Me platform* I needed to define a few things in a few objects, it was possible to make all the data to fit into one object, but it would make that object too heavy for the J2Me platform (besides I rather having two objects it felt more OOD right way to do), where one is a type definer that can produce only one instance of this object although it is inheritable,
    "produce"? You mean a factory?
    * The limitation I'm facing are:
    1. I cannot import into the build path of the project any external libraries.
    2. The J2Me platform runs on the JRE 1.3.
    3. J2Me does not support serialization, which is the real pain in the S.
    What do you mean "external" libraries? Your code doesn't count right?
    The other two limitations are not limitations at all as far as I can see.
    urrrr... so hard to explain this in words, this is terrible.
    That isn't good. If you can't describe it then building it will be even harder. However it shouldn't matter in terms of this discussion.
    there are a few advantages to this such as memory usage on the phone among other things,
    Memory in terms of the class or the instance? If the instance then it doesn't have much to do with this discussion. If the class then that impacts your design because with a limited memory size and large impact then unloading might come up - and that requires a class loader.
    so what I need to have in the configuration file is a reference to which type of object this plugin is based on A,B,C, or maybe a future D type.
    and the fully qualified name of the object that generates the GUI for editing this data type.
    Presuming that each "type" really is a type (say you have 4 interfaces any of which might be implemented) then you would need the following in a configuration file for each entry.
    1. Type of the implemented class.
    2. Full name of the implemented class
    3. Full name of the GUI dialog object.
    4. Optional Name of this entry. I suggest this as it allows you to report errors using this name rather than plugin class names

    Per your requirements there is no path nor jar is needed nor can be specified.
    well, in my case it would extend an abstract class from the J2Me platform, maybe two object I'm still thinking about a better implementation so the plugin would be more simple, consist of only one object, that needs to be loaded.
    It shouldn't matter to you how the class is implemented.
    now I have two basic data types, one is an Image data chunk, and the other is an Audio data chunk, the Image data chunk is composed of two more basic chunks, that define the images sizes and crops the image on the phone, and loads the desired audio type that the phone supports, on run time.
    Presumably you are managing the data items because the base class is going to provide functionality relevant to them.
    I did not make these editors/creators plugins yet, I wait until I would get a full sense of what am I going to do... like you said:
    I suggest you do that first before attempting specifics of the plug in.
  • 8. Re: How to make a simple Plugin system?
    843798 Newbie
    Currently Being Moderated
    well, English is not my native, so I find it hard to describe, sometimes I feel the lack of words to describe what I want, and I have to take a break, and use a dictionary to find the right word to use, and sometimes these are basic words that I miss so I'm sorry if I'm not clear.
    And this will be required for every single plugin in exactly the same way? If not then each plugin should include a factory.
    Yes, they are all saved the save way, every plugin has a method that create an instance of a basic class J2MeDataChunk.
    The types of the data chunks are defined on the J2Me platform and only there.

    The reason that they are defined on the J2Me platform is because of the first limitation of the J2Me platform.
    1. I cannot import into the build path of the project any external libraries.
    Therefore in the future when I would like to add more chunk types, I would have to add them into the J2Me project as classes, and not as a jar in the build path, but the plugin would have to refer to the J2Me project and to know which chunk type it is going to edit.

    Each plugin knows how to edit a different type of J2MeDataChunk, the data chunks saves them selfs into a data output stream using a serialize method in each of them, and the serialize method is invoked from the plugin itself when the user (me) press the save button.
    "produce"? You mean a factory?
    No, I meant that the object I posted earlier (J2MeDataChunkType) is an object that represent the type of the data chunk for each of the data chunk types, and that there can only be one instance of the object that represent the type of the data chunk, and that single instance of the object that represent the type of the data chunk is the one that can create new instances of that data chunk type, it can create an empty data chunk,or to deserialize the data chunk type using a DataInputStream, and it has an abstract method, that returns Swing component only on the J2Se platform (a class that extends the J2MeDataChunkType object on the J2Se platform that overrides the abstract method for the editing Frame/Panel).
    What do you mean "external" libraries? Your code doesn't count right?
    I mean that a J2Me project cannot import other jar files into its build path, only the classes files that are in the project are known to the complier.
    The other two limitations are not limitations at all as far as I can see.
    well the third one might not be a limitation but it is a pain in the .. S since I have to implement every object I want to serialize myself
    but the second one, well, if you don't use the full strength of the 1.5 then you might not miss it, but there are so many elements I miss when programming on J2Me platform... like this one, I don't know how it is called:
    class A {
    }
    class B  extends A {
    }
    
    class C {
          A getA() {
    //  return instance of A
          }
    }
    
    class D extends C{
          B getA() {    // this is not implementable on J2Me, and I miss this for better implementation of things since I try to integrate my J2Me platform I'm building with J2Se application.
    //  return instance of B
          }
    }
    moreover I miss enumeration, god I love using the
    for(Object o: objectList)
    very useful very efficient to use...

    and how could I leave generics out... wow no generics... terrible oh, and enums, no enums... hell if there were enums on J2Me... life would have been less gray.

    so yes I see all this as limitations, it slows me down allot, and it makes my code less readable.

    well since I try to build a bridge between the J2Me and J2Se platforms, and since there are some limitation to the J2Me platform* I needed to
    define a few things in a few objects, it was possible to make all the data to fit into one object, but it would make that object too heavy for the
    J2Me platform (besides I rather having two objects it felt more OOD right way to do), where one is a type definer that can produce only one
    instance of this object although it is inheritable,
    Memory in terms of the class or the instance? If the instance then it doesn't have much to do with this discussion. If the class then that impacts >your design because with a limited memory size and large impact then unloading might come up - and that requires a class loader.
    well this design actually adds an extra class for each type I decide to add to my platform although at the end I intend to join all the objects that represent the type of the data chunk into one object only on the J2Me platform which would actually add only one class to the memory on the phone, it is just easier for me to see things clearer now as I design this bridge application between the platforms, besides it allows maximum flexibility to create new types of chunks, and that was my main aim, to make as many types to be saved on files that I can transfer via a wireless onto the phone and the platform on the phone would know exactly what to use them the data chunks for with out any user intervention.
    as for instances, this way I reduce the memory each of the chunks would use and in the total calculation it would improve memory usage while creating objects from these chunks.
    Presumably you are managing the data items because the base class is going to provide functionality relevant to them.
    Right, the base class is the most common ground I could find for all the chunks together.
    Presuming that each "type" really is a type (say you have 4 interfaces any of which might be implemented) then you would need the following in
    a configuration file for each entry.
    1. Type of the implemented class.
    2. Full name of the implemented class
    3. Full name of the GUI dialog object.
    4. Optional Name of this entry. I suggest this as it allows you to report errors using this name rather than plugin class names
    Per your requirements there is no path nor jar is needed nor can be specified.
    well I hope that by now you did get that I generalized all the data chunk types that I created into one basic object which I posted earlier, this object handles everything, and the plugin main object would be design on the J2Se platform and would extend that J2MeDataChunkType class and it would return the Swing frame/panel when the J2Se application calls the getPanel method and an empty chunk on the getDataChunk() method.
    well, in my case it would extend an abstract class from the J2Me platform, maybe two object I'm still thinking about a better implementation >> so the plugin would be more simple, consist of only one object, that needs to be loaded.
    It shouldn't matter to you how the class is implemented.
    But of course it does, I want to make my life as simple as possible when I implement new plugins, having one object with abstract method, that when I extend it Eclipse would automatically add the abstract method for me to implement, and just a short glimpse at another implementation of the plugin would let me design another plugin in seconds.(with out making the GUI for the data chunk editing obviously).

    I think I got my head around this, especially now that it feels like I could explain what I'm making better in words.

    Thank you for taking the time to respond to my posts, I see you currently have 37k post so I guess you are a very quick typer, yet you take the time to try and understand my design. Thank you.

    Adam Zehavi.
  • 9. Re: How to make a simple Plugin system?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    Adam-Z. wrote:
    The other two limitations are not limitations at all as far as I can see.
    well the third one might not be a limitation but it is a pain in the .. S since I have to implement every object I want to serialize myself
    but the second one, well, if you don't use the full strength of the 1.5 then you might not miss it, but there are so many elements I miss when programming on J2Me platform... like this one, I don't know how it is called:
    covariant return types. If you are using (or want to use) a lot of that in your code your design might have problems.

    >
    so yes I see all this as limitations, it slows me down allot, and it makes my code less readable.
    The only real impact on readablity is the developer not the language. I can write readable assembly (and have.)
    It shouldn't matter to you how the class is implemented.
    But of course it does, I want to make my life as simple as possible when I implement new plugins, having one object with abstract method, that when I extend it Eclipse would automatically add the abstract method for me to implement, and just a short glimpse at another implementation of the plugin would let me design another plugin in seconds.(with out making the GUI for the data chunk editing obviously).
    Be careful about that path. Do not implement code and especially hierarchies solely based on limiting how much code one must write. Maintenance has a much higher cost that initial implementation and adding complexity simply to limit initial creation will add to the cost later.
  • 10. Re: How to make a simple Plugin system?
    843798 Newbie
    Currently Being Moderated
    covariant return types. If you are using (or want to use) a lot of that in your code your design might have problems.
    why is that, I find it an imperative tool to save casting in the code, for example:
    class A {
    }
    class B  extends A {
    }
     
    class C  extends A {
    }
     
    class D  extends A {
    }
     
    class R {
          A getA() {
    //  return instance of A
          }
    }
     
    class S extends R{
          B getA() {    // this is not implementable on J2Me, and I miss this for better implementation of things since I try to integrate my J2Me platform I'm building with J2Se application.
    //  return instance of B
    class T extends R{
          C getA() {    
    //  return instance of C
      }
    I use this implementation for both the J2Se plugin application, and the bridge I'm designing, it would allow me to add future types of chunks with ease.

    I really think this is much more organized...

    please do correct me if I'm wrong.

    The only real impact on readablity is the developer not the language. I can write readable assembly (and have.)
    No doubt about that, I meant that while using these functionalities the code is more condensed, and in a way more readable, I don't think there is a way to compare a code with tones of casting with a code with hardly any casting...

    Be careful about that path. Do not implement code and especially hierarchies solely based on limiting how much code one must write. >Maintenance has a much higher cost that initial implementation and adding complexity simply to limit initial creation will add to the cost later.
    yes well, I read a few articles about Inheritance vs. composition designs and after playing around with some code, I'm really a mix, and as for this specific implementation, I tried a different approach earlier this month, and it didn't work so well...

    Thanks, Adam.
  • 11. Re: How to make a simple Plugin system?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    Adam-Z. wrote:
    covariant return types. If you are using (or want to use) a lot of that in your code your design might have problems.
    why is that, I find it an imperative tool to save casting in the code, for example:
    For starters that reason has nothing to do with creating hierarchies. You create hierarchies for very specific reasons. And in your total code base if you have an excessive number of hierarchies it suggests design problems. And of the correct hierarchies very few should need covariant return types.

    And further many classes, should not be exposed in many places in an application (excluding certainly utility classes such as java.lang.String.) If they are it certainly means more coupling and can represent a design problem.

    Because of the limiting factors above it should not be a significant problem in your entire code base. Where "significant" would be a percentage of usage - even 1% might be problematic.

    This of course might be impacted by the fact that you might have a much smaller code base which you are working on.
  • 12. Re: How to make a simple Plugin system?
    843798 Newbie
    Currently Being Moderated
    but, I don't understand, then how else would I implement the type of plugin I want, instead of just an interface I have an abstract class that the plugin inherit of, and then every plugin has a different data chunk type that it handles, and a specific editor that knows how to handle that specific data chunk type, if I would not use covariant return type I would have to cast the data chunk I receive from the plugin every time I call the method generateChunk(). perhaps my design was not clear here is the highlights of the design:
    // this object is defined on the J2Me platform JRE 1.3
    
    public abstract class Plugin {
       private Object editor;
       public abstract DataChunk generateChunk();
       public abstract DataChunk generateChunk(DataInputStream dis);
       protected abstract Object _getEditor(); // this method 
       public Object getEditor() {   // this way I make sure there is only one instance of the editor
            if(editor==null)
                editor=_getEditor();
            return editor;   
       }
    }
    so far that is all the data I need for my plugin... every plugin handles different type of data chunk for example, ImageDataChunk, so, I would have this object:
    // this object is defined on the J2Se platform JRE 1.5 allows covariant return types:
    
    public class ImageDataChunkPlugin extends Plugin {
       public ImageDataChunk generateChunk(){...}
       public ImageDataChunk generateChunk(DataInputStream dis){...}
       protected ImageDataChunkEditor _getEditor() {
           return new ImageDataChunkEditor();
       }
    }
    and of course:
    public class ImageDataChunk extends DataChunk {
    ...
    }
    and the same of each type of plugin I'm going to make for that specific task

    is this a bad design for a plugin ??
  • 13. Re: How to make a simple Plugin system?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    Adam-Z. wrote:
    but, I don't understand, then how else would I implement the type of plugin I want, instead of just an interface I have an abstract class that the plugin inherit of, and then every plugin has a different data chunk type that it handles, ....
    That isn't what I said.

    You suggested that the lack of covariant return types was a significant problem. A significant problem would be one that impacts the entire code base of a project, not just a couple of lines in a project.

    So if you have 100,000 lines of code then 1,000 lines is significant. But 3 isn't.
    and a specific editor that knows how to handle that specific data chunk type, if I would not use covariant return type I would have to cast the data chunk I receive from the plugin every time I call the method generateChunk(). perhaps my design was not clear here is the highlights of the design:
    Not sure about that statement but an "editor" which is specific to the plugin should in fact be part of the plugin. In that case the caller should not need to cast nor care about the real type. And it would be quite reasonable for the entry point to the editor to cast to the real type.

    What functionality of the framework, not plugin and not plugin editor, is impacted by the functionality of a specific data type? If there is none, which is probably the way it should be then a interface/base class is all that is needed in the public API that the framework expects.
  • 14. Re: How to make a simple Plugin system?
    843798 Newbie
    Currently Being Moderated
    Great, Thank you for all your help, I would try to use all of the information you gave me wisely.

    Thanks again,
    Adam.
1 2 Previous Next