[PB 5.2b4] Please Rename Module to Package

[fsw]

EDIT: This request was almost completed with PB 5.2b5
Library "Module" was renamed to "Music".
The only thing that remains is the renaming of UnusePackage, as "unuse" is not a commonly used word (there is "unused" but this doesn't fit either).
Suggestions:
Bind / Unbind suggested by Demivec;
Attach / Detach suggested by Luis;
Use / Release suggested by fsw.

Thinking of it: Attach / Detach would be the best choice.
- end of edit -
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The commands would look like this:

Code: Select all

DeclarePackage
EndDeclarePackage
Package
EndPackage
UsePackage
UnusePackage

See here:
http://www.purebasic.fr/english/viewtop ... 3&start=25

The reason:
Modules already exist as music modules...

Code: Select all

CatchModule
FreeModule
GetModulePosition
GetModuleRow
IsModule
LoadModule
ModuleVolume
PlayModule
SetModulePosition
StopModule

Thanks

BTW: ClosePackage is the logical complementary command to UsePackage instead of UnusePackage.
It follows the following conventions:

Code: Select all

UseGadgetList() / CloseGadgetList()
Use...Database() / OpenDatabase() / CloseDatabase()
Use...Packer() / OpenPack() / ClosePack()

[Little John]

The reason:
Modules already exist as music modules...

Code: Select all

CatchModule
FreeModule
GetModulePosition
GetModuleRow
IsModule
LoadModule
ModuleVolume
PlayModule
SetModulePosition
StopModule

UUUhhh...

Oh yes, the new "Modules" should be renamed then.
+1

[PB]

+1

[eddy]

I forgot these functions

[Fred]

BTW: ClosePackage is the logical complementary command to UsePackage instead of UnusePackage.
It follows the following conventions:

Code: Select all

UseGadgetList() / CloseGadgetList()
Use...Database() / OpenDatabase() / CloseDatabase()
Use...Packer() / OpenPack() / ClosePack()

No, UseGadgetList() has no complement (CloseGadgetList() works only after OpenGadgetList())
Use...Database() and Use...Packer() has nothing to do with the respective close commands.

Open -> Close
Load/Create -> Free
Use -> nothing for now, so it's Unuse (may be not the best english word, but at least it describes well the behaviour).

I will think about the renaming. May be it would easier to rename the Module lib to Music lib as it's a better description anyway.

[ts-soft]

+1 for renaming the "Music"-Module lib.

[Demivec]

+1 for renaming the "Music" Module lib.


Suggestions on alternative names for UseModule/UnuseModule in the other Module lib:

• IncludeModule/ExcludeModule
  ActivateModule/DeactivateModule
  OpenModule/CloseModule
  EnterModule/LeaveModule
  BindModule/UnbindModule

Each have Pro's and Con's regarding their use but I lean towards either Activate/DeactivateModule or BindModule/UnbindModule (costs only an extra letter each ).


I am also interested in an 'ImportModule ... As ...' or a 'RenameModule modulename, newname' for dealing with name clashes.

[c4s]

I am also interested in an 'ImportModule ... As ...' or a 'RenameModule modulename, newname' for dealing with name clashes.

You should put this in a separate feature request as it's a great suggestion!

[PB]

> Use -> nothing for now, so it's Unuse (may be not the best english word [...]

Maybe Use/Discard ?

[Little John]

I am also interested in an 'ImportModule ... As ...' or a 'RenameModule modulename, newname' for dealing with name clashes.

This would be useful, but I think no new keyword is needed. This functionality can be offered as extended syntax of "UseModule":

Code: Select all

UseModule X
UseModule X As Y

[ts-soft]

This would be useful, but I think no new keyword is needed. This functionality can be offered as extended syntax of "UseModule":

Code: Select all

UseModule X
UseModule X As Y

But you can't use this Syntax for fullqualified using of Module.
example:

Code: Select all

ImportModule Common As Default
Default::Foo()

[Little John]

But you can't use this Syntax for fullqualified using of Module.

Ah, I understand. Thanks for the explanation.

[fsw]

...I will think about the renaming. May be it would easier to rename the Module lib to Music lib as it's a better description anyway.

Sure, renaming the music library would work too. My initial thought was that tons of users would not be amused about changing it, but maybe nobody uses it anyway...

BTW: What about ReleaseModule?

[luis]

We have StartDrawing. When executed the following graphic operations works on a specified target/context.
StopDrawing release the association.

There is some analogy with modules.
So maybe StartUsingModule and StopUsingModule would be fair equivalents.

The little problem I see is StopUsingModule does not really block you to use it if you specify a fully qualified name, so it's slightly improper.

A better candidate could be AttachModule / DetachModule.

This does not have the implications of "closing", "freeing", and "releasing", all denoting an impossibility of further access not really existing thanks to the "::" qualifier.

When you attach a module, you can call its procedures without qualifiers, when you detach the module you can't do that anymore but you can still invoke its procedures using the full name qualifier since the module does not cease to exist (not freed, closed, released).

Sounds reasonable to me, and almost anything it's better than "Unuse"

EDIT: Just saw the Bind / Unbind suggested by Demivec above. This too sounds nice, even if I still slightly prefer Attach / Detach. Binding brings to mind a slightly different concept to me.

[Tenaja]

+1 to addressing this issue; I, too, saw the issue immediately when searching Help to see if it was documented.

If you like "Module", I would be ok with changing the music module; like you said it was not as consistent with current naming. Anyone with old code can either use an old compiler or do a search/replace.

Another option for renaming the new Module (in lieu of Package) is Unit, which is used in Pascal. Or maybe you would rather avoid that if the two systems have significant conflicts in their implementations.