To clarify things it is best to see a method as standard function that gets an additional implicit parameter : the "Self" parameter that references the object. So if you don't need any access to the object, use a simple function and not a method (note that this is not entirely the same, as the Self parameter is really treated specially, but that is not relevant here).
But then you may ask why you'd ever need to have a normal function inside a type, and why not simply put it in the global scope? The first reason is for documenting purpose, and to make things more logical.
Typical example: a "Create" function that creates an object with some parameters:
Isn't it logically neater to have such a "Create" function in each type, rather than to create functions like CreateMyType2, CreateMyType2 etc.
Second point (correct me if I'm wrong, this is from memory - from the beta version), you can have private member functions, just like private fields or methods. This is something that you could hardly do if the function were not part of the type itself.
But then you may ask why you'd ever need to have a normal function inside a type, and why not simply put it in the global scope? The first reason is for documenting purpose, and to make things more logical.
Typical example: a "Create" function that creates an object with some parameters:
Type MyType Field f1% Field f2$ Function Create.MyType(param1%, parm2$) Local obj:MyType = New MyType obj.f1 = param1 obj.f2 = param2 Return obj End Function End Type ... Local o.MyType = MyType.Create(5,"blabla")
Isn't it logically neater to have such a "Create" function in each type, rather than to create functions like CreateMyType2, CreateMyType2 etc.
Second point (correct me if I'm wrong, this is from memory - from the beta version), you can have private member functions, just like private fields or methods. This is something that you could hardly do if the function were not part of the type itself.