Should there be an interface to a container control as a rule?

  1. 3 months ago

    Brian O

    Mar 24 Calgary, AB

    If you create a container control, in the IDE, is the intent that you add methods to the container control as you would a class?
    or does one define an interface and have the container control implement it implement it?

    @Brian OBrien If you create a container control, in the IDE, is the intent that you add methods to the container control as you would a class?
    or does one define an interface and have the container control implement it

    Generally speaking, I think when using Container Controls, the design goal is that any controls you place inside a Container should be marked as Private scope, so that nothing outside of the Container can or should be able to access those controls (deliberately or inadvertently).

    So if the above is a preferred design goal for your project, then yes, you then want to add Public Methods, Events and/or Properties to the Container itself to interact with the inner contained Private controls.

    An Interface is then useful if you plan in your code design to reuse your Container Control to create more than one variation of your Container. In which case, your interface would generally only implement the "generic" Methods that are useful for each of your control variations, e.g., Methods to "Set" and "Get" data in & out of the Container, or common Events used by each.

    With the above in mind, I would build the Container Control first, then once you're satisfied with the functionality, right-click on the Container Control in the IDE and choose "Extract Interface..." to save yourself some steps. This way you get a working Interface quickly, which you can then pair down to the limited common Methods you want to implement on the next Container.

    I did this recently with some Containers that I use as views to display a common set of controls, when clicking on specific kinds of records in a Listbox.

    @Beatrix Willius You could define an interface. But why?

    Note: Strictly speaking an Interface is not required, but is useful for the idea of re-usability. The only down-side to Interfaces in Xojo (at this time) is that Interfaces appear to only support Methods and not Properties or Event Definitions. But I usually just add a Note to remind me what I need to add (and why).

    I hope that helps to answer your question. Good luck!

  2. Beatrix W

    Mar 24 Testers, Third Party Store Europe (Germany)

    Yes, you add methods. You could define an interface. But why?

    I let the containers communicate with the window by events. Then I make most of the methods in the container private so that there are only very few public methods. But for most communication I now use notifications.

  3. Scott C

    Mar 24 Testers, Xojo Pro Answer twitter.com/ScottCadillac

    @Brian OBrien If you create a container control, in the IDE, is the intent that you add methods to the container control as you would a class?
    or does one define an interface and have the container control implement it

    Generally speaking, I think when using Container Controls, the design goal is that any controls you place inside a Container should be marked as Private scope, so that nothing outside of the Container can or should be able to access those controls (deliberately or inadvertently).

    So if the above is a preferred design goal for your project, then yes, you then want to add Public Methods, Events and/or Properties to the Container itself to interact with the inner contained Private controls.

    An Interface is then useful if you plan in your code design to reuse your Container Control to create more than one variation of your Container. In which case, your interface would generally only implement the "generic" Methods that are useful for each of your control variations, e.g., Methods to "Set" and "Get" data in & out of the Container, or common Events used by each.

    With the above in mind, I would build the Container Control first, then once you're satisfied with the functionality, right-click on the Container Control in the IDE and choose "Extract Interface..." to save yourself some steps. This way you get a working Interface quickly, which you can then pair down to the limited common Methods you want to implement on the next Container.

    I did this recently with some Containers that I use as views to display a common set of controls, when clicking on specific kinds of records in a Listbox.

    @Beatrix Willius You could define an interface. But why?

    Note: Strictly speaking an Interface is not required, but is useful for the idea of re-usability. The only down-side to Interfaces in Xojo (at this time) is that Interfaces appear to only support Methods and not Properties or Event Definitions. But I usually just add a Note to remind me what I need to add (and why).

    I hope that helps to answer your question. Good luck!

  4. Markus R

    Mar 24 Testers, Xojo Pro Europe / Germany / Lower Saxon...

    for container controls are computed properties really useful.
    but it is difficult to find a name that is not a key word^^

    The only down-side to Interfaces in Xojo (at this time) is that Interfaces appear to only support Methods and not Properties or Event Definitions.

    agree i missing that too ..

  5. Emile S

    Mar 25 Europe (France, Strasbourg)
    Edited 3 months ago

    @Markus R but it is difficult to find a name that is not a key word^^

    No: use "_MR" (without quotes) as a suffix of whatever name you want. (for example)

    Edit:
    I use _FI as suffix for FolderItem variables;
    PB_ as prefix for PushButtons
    TA_ or TF_ as Prefix for… TextArea and TextField

    You understand the idea.

  6. James D

    Mar 25 Testers, Xojo Pro Europe (Switzerland)

    @Emile S No: use "_MR" (without quotes) as a suffix of whatever name you want. (for example)

    Edit:
    I use _FI as suffix for FolderItem variables;
    PB_ as prefix for PushButtons
    TA_ or TF_ as Prefix for… TextArea and TextField

    You understand the idea.

    I have not seen a need to add the type to a variable since I was a Windows system programmer coding in C and there was a need for Hungarian notation.

    These days, my naming convention is simple:

    • Class definitions begin with T and Interfaces with I, so the real name is still available for use as a variable
    • Event definitions begin with On to make them easy to find among the framework events
    • Private and protected properties begin with m, except for Id which is usually called mRecordId
    • Labels end with Title

    Thus for a UI component, mFirstNameTitle would be the label, mFirstName the input control and firstName can be used as a variable name.

  7. Markus R

    Mar 25 Testers, Xojo Pro Europe / Germany / Lower Saxon...

    @Emile S properties

    properties with prefix / suffix makes the source code looks pretty ugly.
    in case of computed properties for controls in container controls your idea is ok.

  8. Tim J

    Mar 25 Testers, Xojo Pro N. Phoenix, AZ

    As for pretty versus readable, I'll go for readability every time. The days of 2 character Commodore BASIC variable naming is long behind us.

    I use a combo of both Emile and James' methods. Served me well for far longer than I've been involved with RS/Xojo :D

  9. Norman P

    Mar 25 Testers, Xojo Pro outside admiring the sunshine,...

    @Markus R for container controls are computed properties really useful.
    but it is difficult to find a name that is not a key word^^

    agree i missing that too ..

    A pair of methods can be made to be semantically and even syntactically indistinguishable from a property (computed or otherwise)
    The code that USES this interface has no means of knowing if indeed it is a property or get/set method pair without introspection
    And thats the point of an interface - to define the API but NOT the implementation of that api

    If you need a "property" define it as

        function myProperty() as type
        end function
    
        sub myProperty(assigns value as type)
        end sub
    

    and then ANY implementor can have this "property" and it can be computed, statiuc, fecthed on demand from the file system or ANYTHING you can dream of

  10. Norman P

    Mar 25 Testers, Xojo Pro outside admiring the sunshine,...

    @James D I have not seen a need to add the type to a variable since I was a Windows system programmer coding in C and there was a need for Hungarian notation.

    Systems or Application Hungarian ? :P
    One worked well - the other was a mess and got it totally wrong (see https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ )

  11. Markus R

    Mar 25 Testers, Xojo Pro Europe / Germany / Lower Saxon...

    @Tim J The days of 2 character Commodore BASIC variable naming is long behind us.

    it did not change the fact that every keyword or class name is in conflict with a propertie name and that happens really often.

    @Norman P

    If you need a "property" define it as

    in a interface? i can not copy this two methods into.

  12. Norman P

    Mar 25 Testers, Xojo Pro outside admiring the sunshine,...
    Edited 3 months ago

    @Markus R @Norman P
    in a interface? i can not copy this two methods into.

    interfaces do not provide the implementation
    they specify an API that the implementor promises to implement - completely (and they happen to define a new data type you can use with ISA which is also handy as heck)

    Suppose your interface has a means to ask for the "count" of something
    Some implementors may simply keep a static array or dictionary and can return the count of those items
    Some implementors may need to dynamically get the count - perhps the implementor needs a count of folderitems and since people can add and remove these without your class' knowledge it probably should be dynamically retrieved from the file system.

    If your interface said "Count" must be a property, defined simply as an integer, this would be a problem for that dynamic use case.

    But, making "Count() as Integer" something each implementor has to add and implement in its own way, you get a known API (the interface) but the flexibility fo implement it differently as needed

    And from outside that interface you cannot tell its done this way

    Is myListBox.ListCount a property ? a computed property ? or a method called "ListCount" that returns an integer ?

          dim i as integer = myListBox.ListCount

    in most cases you do not care nor is it relevant
    You use it as if it is a "property" (something that can be read and set) and you move on

  13. Scott C

    Mar 25 Testers, Xojo Pro twitter.com/ScottCadillac

    @Norman P A pair of methods can be made to be semantically and even syntactically indistinguishable from a property (computed or otherwise)
    The code that USES this interface has no means of knowing if indeed it is a property or get/set method pair without introspection
    And thats the point of an interface - to define the API but NOT the implementation of that api

    If you need a "property" define it as

        function myProperty() as type
        end function
    
        sub myProperty(assigns value as type)
        end sub
    

    and then ANY implementor can have this "property" and it can be computed, statiuc, fecthed on demand from the file system or ANYTHING you can dream of

    You're quite right Norman, as usual ;-)

    I was recently playing around with how a Method can act as a Property using Assigns.

    I didn't clue in at the time that this would a very good substitute for implementing/storing property-like definitions in an Interface.

    Thank you!

  14. Markus R

    Mar 25 Testers, Xojo Pro Europe / Germany / Lower Saxon...

    @Norman P interfaces do not provide the implementation

    yes, your example was without and only a definition.
    i think a interface can not have the same method name twice.

       function myProperty() as type
        end function
    
        sub myProperty(assigns value as type)
        end sub

    its more

    function GetPropertyName() as type
    sub SetPropertyName(assigns value as type)

    then it is a workaround and not listed as property if you have a class with this interface.

    my thought was to define also a property as interface. if you have a class you just select a interface and bam all
    properties are there. (instead of define them in a base class)

  15. Norman P

    Mar 25 Testers, Xojo Pro outside admiring the sunshine,...
    Edited 3 months ago

    @Markus R i think a interface can not have the same method name twice.

       function myProperty() as type
        end function
    
        sub myProperty(assigns value as type)
        end sub

    this ABSOLUTELY works because they have 2 completely different signatures
    try it
    and it works whether its in an interface OR just on some class that isnt using or implementing an interface

    @Markus R

    function GetPropertyName() as type
    sub SetPropertyName(assigns value as type)

    no - you DO NOT need to do this

    do the overloaded methods and it works perfectly fine - but yes the method will NOT be listed as "properties" but they BEHAVE as if they were getting & setting a property

  16. Markus R

    Mar 25 Testers, Xojo Pro Europe / Germany / Lower Saxon...

    @Norman P this ABSOLUTELY works because they have 2 completely different signatures
    try it

    at least i tried to copy/paste your example into a interface but only one method appear for some reason.

  17. Norman P

    Mar 25 Testers, Xojo Pro outside admiring the sunshine,...

    oh I have no expectation you CAN copy paste from the forums into the IDE'
    but you can certainly create methods like I described
    I do this all the time

  18. Markus R

    Mar 25 Testers, Xojo Pro Europe / Germany / Lower Saxon...

    @Norman P oh I have no expectation you CAN copy paste from the forums into the IDE'
    but you can certainly create methods like I described
    I do this all the time

    ok i will test this later. its valuable :)

  19. Brian O

    Mar 26 Calgary, AB

    I love the interface idea.. makes my coding a lot faster (i don't have to define methods over and over again)...
    but.. no events?!

    Visual Basic eventually added a With Events definition didn't it?
    I'm considering adding a RaiseEvent method to every interface that is

    RaiseEvent(EventName as string, ParamArray params() as variant) as variant
  20. Norman P

    Mar 26 Testers, Xojo Pro outside admiring the sunshine,...
    Edited 3 months ago

    at firs tglance event definitions seem like they could be a plausible addition since they dont specify how something is implemented
    they too just specify WHAT is to be implemented

    dunno if any one ever asked event defs be added to an interface

  21. Newer ›

or Sign Up to reply!