Remove requirement for matching "Module" for "DeclareModule"

[Mistrel]

Not all modules require additional definitions. The current requirement just adds unnecessary code.

Code: Select all

DeclareModule SomeModule
  Enumeration
    #A
    #B
    #C
  EndEnumeration
EndDeclareModule

Code: Select all

[COMPILER] Module 'SomeModule' has been only declared (Module/EndModule part missing).

[ts-soft]

+1

and versa vice

Code: Select all

  DeclareModule CommonConstants
    ; Form
    Enumeration FormWindow
    EndEnumeration
    Enumeration FormGadget
    EndEnumeration
    Enumeration FormMenu
    EndEnumeration
    Enumeration FormImage
    EndEnumeration
    Enumeration FormFont
    EndEnumeration
    ; Event
    Enumeration EventCustom #PB_Event_FirstCustomValue
    EndEnumeration
    Enumeration EventTypeCustom #PB_EventType_FirstCustomValue
    EndEnumeration
  EndDeclareModule
  
  Module CommonConstants
  EndModule

[Mistrel]

I made a mistake with my original post. It was already aligned with your request, ts-soft but I posted the wrong snippet.

Is there a use case for a Module/EndModule without a DeclareModule/EndDeclareModule?

[luis]

Requested here -> viewtopic.php?f=3&t=64991

In the meantime I finally gave up on modules though.

[#NULL]

Is there a use case for a Module/EndModule without a DeclareModule/EndDeclareModule?

Good question I think you could wrap any code in a module for encapsulation and the module will execute itself wherever it's included, even though nothing could be called from outside.

Code: Select all

DeclareModule msg
EndDeclareModule
Module msg
  m.s = "hello"
  MessageRequester("msg", m)
EndModule

[the.weavster]

In the meantime I finally gave up on modules though.

Me too. I experimented with Modules, then OOP(ish) Interfaces and ended up back at Namespace_Command().

[Mistrel]

I think you could wrap any code in a module for encapsulation and the module will execute itself wherever it's included, even though nothing could be called from outside.

This is actually a very good use case as it would be equivalent to creating temporary scope. It would be even more useful if we didn't have to provide a name for this purpose.

In the meantime I finally gave up on modules though.

Me too. I experimented with Modules, then OOP(ish) Interfaces and ended up back at Namespace_Command().

I've ignored modules since their introduction since I was already using Namespace_Command() as well. So it's all new and fun for me.

If we can get interfaces and structures as return types then there should be a lot more excitement over modules. But I agree that right now they're not all that useful.

[#NULL]

I like the idea we had here. I have a couple of small files containing testcases mostly using the global scope and maybe I'm able to create one file which includes each test file within its own 'temporay' module block, i.e. 'Module x : IncludeFile "test_x.pb" : EndModule', so I can run them all at once and their definitions don't collide.