PureBasic Forums - English

I don't know yet what is a module, but if it is something we do create and remove afterwards, then I agree terminologically with Kuron.
I would even use Module instead of UseModule or any other prefix, as it is not necessary. If we say Module, it means to use it.
FreeModule is to remove it from Memory and looks perfect to me.

charvista wrote:FreeModule is to remove it from Memory and looks perfect to me.

What you write?
The module is part of the static code of the program and can not remove it from memory!
Read more about the modules. http://en.wikipedia.org/wiki/Namespace

charvista wrote:I don't know yet what is a module

Oh, now I see what it is. In this case, FreeModule is certainly NOT appropriate, as it does not free any memory!

In this case, I have two naming suggestions:

Module / EndModule (like Enumeration / EndEnumeration)
or
StartModule / StopModule (like StartDrawing / StopDrawing)

Spasibo/Thank you User_Russian for your clarification.

Module / EndModule is already used to the definition area of the Module itself.
To give more significance it could be:
WithModule / EndWithModule

You can discuss it in this thread -> http://www.purebasic.fr/english/viewtop ... =3&t=55196

I believe Fred would appreciate it. After all he has already dropped three hints.

Thanks Fred, and thank you to the Fantaisie team. Great work guys!

Just figured out the new Module system, and realised that it may be PureBasic's first steps into OOP, complete with namespace support. Evolutionary.

TI-994A wrote:first steps into OOP

No. http://www.purebasic.fr/english/viewtop ... 70#p403070

Fred wrote:PureBasic won't be object oriented, period.

A pity.
If objects used wisely (and not where you can do without them), can simplify programming and make the code more readable.

User_Russian wrote: If objects used wisely (and not where you can do without them), can simplify programming and make the code more readable.

It depends on the kind of program.
That affirmation is valid only for concrete cases.

I've just switched our project from using PB5.11 to PB5.20b5.

And I must say: well done! Only had to change one constant from #PB_Sort_Integer to #PB_Integer, and this in a 38,000 lines sourcecode!
(@Fred: this should also be mentioned in the 'Changed:' section of the PB5.20 announcement)

Andre wrote:Only had to change one constant from #PB_Sort_Integer to #PB_Integer, and this in a 38,000 lines sourcecode!
(@Fred: this should also be mentioned in the 'Changed:' section of the PB5.20 announcement

This was already changed in PB5.10:

5.10 Changelog wrote:Changed: replaced #PB_Sort_ with #PB_ to avoid possible errors

@c4s: ....hm, so the #PB_Sort_... constants must still have been present in PB5.11 (at least on MacOS), because my project compiled just fine with PB5.11 until now. Anyway... no or only one change for the switch to PB5.20 is good

Had the same problem with #PB_Sort_String; changed it to #PB_String and it seems to work.

Stupid question - how do I download the latest beta?

[edit]

scratch that, dumb question, have figured it out.... Doh!

Andre wrote:...constants must still have been present in PB5.11 (at least on MacOS), because my project compiled just fine with PB5.11 until now.

Hello Andre. Yes, both the PB_Integer and PB_Sort_Integer constants are present in PureBasic v5.11, but they hold different values.

Furthermore, although the PB_Sort_Integer and PB_Sort_Long constants have the same values, PB_Integer and PB_Long hold different values.

It is not necessary at all to struggle with those type constants for sorting. We don't have to give this information to PB, because PB knows it itself.

see e.g. http://www.purebasic.fr/english/viewtop ... 78#p415278