Type, Class or Module?

[wonder]

In order to choose the right one for you, ask yourself these simple questions:
1) Will my object contain functions? YES: Class or Module | NO: Type
2) Will there be more than one instance of my object? YES: Class or Type | NO: Module

So...
NO, NO: Type
NO, YES: Type
YES, NO: Module
YES, YES: Class

Happy programming!

 

[EnriqueGonzalez]

Types are also useful for B4X language because by storing them on a list, you can order them with this specific function:

    Type Person (name As String, age As Int)

    Dim listOfPersons As List
    listOfPersons.Initialize
  
    listOfPersons.SortType("age",True)

 

[LucaMs]

I don't agree completely, although your concepts are valid.

1) Mainly you should use classes when you need to represent an object, real object or immaterial object.
2) You can use a single instance of a class instead of a code module; so, if later you will need typical characteristics of classes you are ready to add them.
3) Types can be useful but a class can be used for the same purpose with more power and control (you can validate the values and also raise events)

Surely it is easier and faster, sometimes, to write:

Type tPoint(X As Int, Y As Int)

Anyway a class is better, even in cases like this one.

Microsoft, after many releases of its products, decided that all things in its languages should be an object, an instance of a class. To me it seems right.

 

[Erel]

I mostly agree with Luca.

Classes vs modules

Classes are preferable over static modules in most cases.
- You are not limited to a single instance.
- In B4A classes can handle events while code modules cannot (this is not true in B4J and B4i).

Code modules are useful for utility methods.

Types vs classes

Types have two important advantages:
- Very simple to create.
- They are serializable with B4XSerializator. This means that you can very easily store the data in a file (or database) or send it over the network.

 

[LucaMs]

- Very simple to create.

"Someone" might invent something like TAB after Sub, which shows... (you know) to get automatically a skeleton of property.

- They are serializable with B4XSerializator. This means that you can very easily store the data in a file (or database) or send it over the network.

This is very important (and my previous comment shows that I did not know or, more likely, I'd forgotten)

 

[wonder]

I'm glad I've started this discussion, today I've learned a thing or two...

 

[thedesolatesoul]

- They are serializable with B4XSerializator. This means that you can very easily store the data in a file (or database) or send it over the network.

I slightly disagree with serializing types using a generic serializer. I've had many issues in the past specifically related to types inside a list (that i cant remember). One of them was the packagename being written with the type making it unportable. But anyway those were just implementation issues.
The one problem with a type is that once you serialize it, and and later you need to add a new field to it, it makes the de-serializer non-generic in order to maintain backwards compatibility. Its easier to do with JSON/Dictionaries instead of hardened types.

 

[Erel]

B4XSerializator deals with missing fields and also deals with different package names (in that case the types must be declared in the Main module).

There are two types of usages for B4XSerializator:
- Communication with another process or device.
- Persisting data.

In the later case you do need to plan ahead and decide how will your code deal with future changes. For example you can add a version field to the custom type.

 

[thedesolatesoul]

Cool, thats great to know.
A few years too late for me though