visibility of functions [SOLVED]

[Monsieur OUXX]

Hi, I'd like to do something to make my modules more intuitive for the end-user, but I'm not sure how I should do.

It's a question concerning the declaration of static functions within a struct; i'd like my struct to be visible from the outside of the module (=> declared in the header), with some static functions accessible from the outside, and some other not accessible (so that the user knows what functions he may use, and what functions he may not use). This also means that these functions stay accessible from the module, even outside this struct!

In fact, what i'd like to do is nothing more than public and protected static functions, provided that protected functions can still be used inside the whole package (for example in Java), though not visible by the end-user. Here, the package would be the module.

This is what i'd like to have : (pseudo-AGS code)

HEADER

Code: ags

struct MyPublicStruct {
    import public static void MyPublicStaticFunction();
    import protected static void MyPrivateStaticFunction();
};

struct MyPublicStruct2 {
    import public static void MyPublicStaticFunction2();
};

BODY

Code: ags

static void MyPublicStruct ::MyPublicStaticFunction() {
    ...
}

static void MyPublicStruct ::MyPrivateStaticFunction() {
    ...
}



static void MyPublicStruct2::MyPublicStaticFunction2() {
    MyPublicStruct.MyPublicStaticFunction();
    MyPublicStruct.MyPrivateStaticFunction();
}

How should I do?

[Ashen]

I'm not sure if it's entirely what your after, but there's the $AUTOCOMPLETEIGNORE$ / $AUTOCOMPLETESTATICONLY$, erm, thingies (not really functions or keywords...). They're not in the manual, and the best description I can find at short notice is HERE. Basically, the functions would still be accessable from outside the module but they wouldn't be in the autocomplete, so the user wouldn't automatically know they were there to use them.

Or, could you use the extends keyword to declare the 'private' functions in the module (not the header), so they wouldn't be global? Again, it's not in the manual, so I'm a little unsure exactly how it works.

[Monsieur OUXX]

I'm not sure if it's entirely what your after

Your answers are very interesting. Thank you.

Just to be sure, I'd like to precise again that the functions I'm looking after mustn't be accessible from outside the module, but from within the module, though outside the struct where they are declared..

[Monsieur OUXX]

What if I remove the word "import" in front of the functions that I want to be accessible from the module but not from the outside of the module?

[monkey0506]

If you remove the word "import" you'll get an error saying that it expects a brace to begin definition of the function, but then it won't actually allow you to define the function directly in the struct either.

The extends method probably fits your needs best.

Code: ags

// header

struct MyPublicStruct {
  import static void MyPublicStaticFunction();
  };

struct MyPublicStruct2 {
  import static void MyPublicStaticFunction2();
  };

// body

struct MyInnerStruct extends MyPublicStruct { // provides basic inheritance
  import static void MyPrivateStaticFunction(); // hidden from public access
  };

static void MyPublicStruct::MyPublicStaticFunction() {
  /* do whatever */
  }

static void MyInnerStruct::MyPrivateStaticFunction() {
  /* blah */
  }

static void MyPublicStruct2::MyPublicStaticFunction2() {
  MyPublicStruct.MyPublicStaticFunction();
  // this is the same as:
  // MyInnerStruct.MyPublicStaticFunction();
  MyInnerStruct.MyPrivateStaticFunction();
  }

All $AUTOCOMPLETEIGNORE$ does is tells the script-autocomplete to ignore a line. This doesn't affect the way it is compiled at all; it simply wont' show up in the autocomplete.

$AUTOCOMPLETESTATICONLY$ is useful for static functions if the user is going to be creating instances of your struct. It is only useful inside of structs following a static function (and hopefully static properties soon as well? ), and all it does is prevents the function/property from showing up if the user creates an instance of the struct (i.e., it will only show up if the user is attempting to access it statically).

[Monsieur OUXX]

The extends method probably fits your needs best.

Absolutely. Thank you!
Thanks to Ashen too, who gave me the right answer, but i didn't manage to catch it - he also gave me some new clues to achieve "clean" things.