As far as I understand, there is three ways to add code that will be used in a Class. To make the question a bit more specific, I will take the ListBox Class as an example.
Suppose that I need an Open and Save (a text file) method in my ListBox.
What will I use:
a. Two Standard Methods (probably set in a Module),
b. Add a Module and set two Methods using Extends,
c. Sub-Class the ListBox Control and add the two Methods into it.
a) and b) are the same. b) is only syntactic sugar for a).
The big difference is, that with c) you can introduce additional state in form of properties to the subclass.
You can’t add properties with a) or b) .One would need a Tag property for that so one could attach arbitrary data in a Extends methods I made a feature request years ago (20676 - Feature request: a Tag property for all controls, for Window and for ContainerControl).
if you plan to use a listbox in an extensive way, you’d better subclass it and use the subclass
it is then very easy to add an event, method or property to all the subclass
you cannot add a property if you use a method, you must add the property to all your listboxes first
(for example the folderitem you want to save to-load from and that you must keep in the class)
[quote=213138:@Emile Schwarz]As far as I understand, there is three ways to add code that will be used in a Class. To make the question a bit more specific, I will take the ListBox Class as an example.
Suppose that I need an Open and Save (a text file) method in my ListBox.
What will I use:
a. Two Standard Methods (probably set in a Module),
b. Add a Module and set two Methods using Extends,
c. Sub-Class the ListBox Control and add the two Methods into it.[/quote]
In general, using extensions is the better approach. Because Xojo is single-inheritance, subclassing locks you into the decision.
This is because Interfaces can’t have properties - mostly because Xojo refuses to add them.Their reasoning is that interfaces are suppose to describe functionality and not implementation. But the reality is that interfaces were added to solve the issue of not supporting multiple inheritance and it would be a lot better to allow them to support properties. (As many other languages do like C#)
[quote=213390:@Brock Nash]https://en.wikipedia.org/wiki/Interface_(computing)
Interfaces between software components can provide: constants, data types, types of procedures, exception specifications and method signatures. Sometimes, public variables are also defined as part of an interface.[/quote]
This part of the wikipedia page does not address OOP interfaces.
You can add properties to an interface. Just add two methods, a getter and a setter, like this:
Interface MyInterface
Sub MyProperty(Assigns value As Integer) // Note the Assigns keyword
End Sub
Function MyProperty() As Integer
End Function
End Interface
You will have to implement these two as methods in the class, but to the user of the class implementing the interface they will behave like a property.
Actually, class interfaces are in Xojo as an alternative to multiple inheritance. It is certainly possible, and not hard, to implement a scheme that allows one to add properties as part of class interfaces. For framework classes, I’ve used extension methods and some storage to add properties to them.
Otherwise, I’ve not really wished too much for multiple inheritance in Xojo. I use it some in Python, but mostly for mixins; I’m still thinking in terms of composition over inheritance.
I don’t want to implement MyProperty() twice on every single implementation of this interface let alone for every single other Property added to the interface. Other languages auto-implement these methods unless you specifically do it. - Yeah, you can accomplish it in XOJO. But its such a pain to manage and implement I typically don’t bother.
The difference is C# will auto create the setter and getter and backend field to store the property.
if you add this to a class or interface:
string myString {get; set;}
When compiled C# will automatically create a field called “__myString” and generate the Setter and Getters
It’s similar to how when you create a computed property XOJO creates the “mVariableName” property for it and creates the default Setter and Getter implementation.
In XOJO there is not a good solution to generate these using an interface. I want to add an interface to a class and have these Setter and Getters automatically generated with the default implementation and have it add the property name to the class if it doesn’t exist yet.
The problem is that Xojo doesn’t handle the scaling of this well. The problem grows exponentially. For each property I want on an interface I need to add 2 methods and 1 property to every implementation of that interface.
So if I have an interface with 10 properties and I have 5 classes that implement this interface I would need to add 120 method definitions and 50 properties. Obviously there’s a problem.
Yes, Xojo will only create the setter and getter - but this has nothing to do with interfaces at all: Xojo does not support auto-implemented computed properties, so it will not work with interfaces too.
[quote=403522:@Djamel AIT AMRANE]Until now i worked with module, about the class is it possible that base class inherit several subclass.
Example : StellarObject inherit stars,sun,planets,moon, etc … ?[/quote]
I think you mean the other way around
Stars, Sun, Planets and Moon are all StellarObjects, so yes you can create Stars based on StellarObjects, and Planets based on Stellar Objects etc… etc… and each of the new subclasses can have new or altered properties
If you follow the inheritance structure of Xojos objects you will see a rather long pedigree for some
[quote=403542:@Dave S]StellarClass would be a SUPERClass (ie. Parent)
Sun, Moon etc are subclasses (ie. Children)[/quote]
Understood Dave, is perfect …
Thank you.