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

  1. ‹ Older
  2. 3 days ago

    Scott C

    Mar 24 Pre-Release 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!

  3. Markus R

    Mar 24 Pre-Release 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 ..

  4. Emile S

    Mar 25 Europe (France, Strasbourg)
    Edited 3 days 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.

  5. James D

    Mar 25 Pre-Release 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.

  6. Markus R

    Mar 25 Pre-Release 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.

  7. Tim J

    Mar 25 Pre-Release 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

  8. Norman P

    Mar 25 Pre-Release Testers, Xojo Pro outside drowning sorrows

    @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

  9. Norman P

    Mar 25 Pre-Release Testers, Xojo Pro outside drowning sorrows

    @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/ )

  10. Markus R

    Mar 25 Pre-Release 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.

  11. Norman P

    Mar 25 Pre-Release Testers, Xojo Pro outside drowning sorrows
    Edited 3 days 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

  12. Scott C

    Mar 25 Pre-Release 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!

  13. Markus R

    Mar 25 Pre-Release 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)

  14. Norman P

    Mar 25 Pre-Release Testers, Xojo Pro outside drowning sorrows
    Edited 3 days 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

  15. Markus R

    Mar 25 Pre-Release 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.

  16. Norman P

    Mar 25 Pre-Release Testers, Xojo Pro outside drowning sorrows

    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

  17. Markus R

    Mar 25 Pre-Release 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 :)

  18. 2 days ago

    Brian O

    2 days ago Pre-Release Testers 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
  19. Norman P

    2 days ago Pre-Release Testers, Xojo Pro outside drowning sorrows
    Edited 2 days 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

  20. yesterday

    Markus R

    yesterday Pre-Release Testers, Xojo Pro Europe / Germany / Lower Saxon...

    @Brian OBrien 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

    it would call the method direct and a typical event would start after the end of a method if the event loop continue.
    EventName could be a Enumeration.
    most of all events i define are unique.

  21. James D

    yesterday Pre-Release Testers, Xojo Pro Europe (Switzerland)

    @Brian OBrien 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

    Use a call back function or an observer pattern if appropriate.

or Sign Up to reply!