Why can't a helper method in an EK9 service be marked 'protected'?

← Web Services · Ref: Q1316

A non-web method inside a 'defines service' construct cannot be marked 'protected'. Services are entry points, not extensible classes, so the 'protected' concept (granting access to subclasses) has no meaning for them and EK9 raises E07240. Use 'private' for an internal helper that should not be exposed as a route, or leave the method public (the default) if it is a web endpoint. Web methods carry an HTTP mapping such as 'as GET for :/path'; plain helper methods do not and so must be 'private' or public, never 'protected'.

See Q199 for REST GET endpoints. See Q201 for HTTP responses.

Example

defines module qa.web.serviceprotected

  defines service

    Greeting :/greeting open

      hello() as GET for :/hello
        <- response as HTTPResponse?

        message <- buildMessage()
        response: (message) with trait HTTPResponse
          override content()
            <- rtn as String: message
          override status() as pure
            <- rtn as Integer: 200
          override contentType() as pure
            <- rtn as String: "text/plain"
          override cacheControl() as pure
            <- rtn as String: "no-store"
          override contentLanguage() as pure
            <- rtn as String: "en"
          default operator ?

      //CORRECT: an internal helper uses 'private', never 'protected'.
      //'protected' on a non-web service method raises E07240.
      private buildMessage()
        <- rtn as String: "Hello from the EK9 service"

  defines application

    GreetingApp
      register Greeting()

  defines program

    ServiceProtectedDemo()
      stdout <- Stdout()

      stdout.println("Service registered with application")
      stdout.println("GET /greeting/hello returns a greeting")
      stdout.println("Internal helper is private, not protected")

Common mistakes

E07240 — Marking a non-web service method 'protected' triggers E07240, because a service is an entry point - not an extensible class - so subclass-oriented 'protected' visibility is meaningless. Use 'private' for an internal helper (or leave it public). See ek9 -h E07240 for details.

Incorrect:

protected buildMessage()
  <- rtn as String: "internal"

Correct:

      private buildMessage()
        <- rtn as String: "Hello from the EK9 service"

Coming from another language?

Java (JAX-RS/Spring): a resource class is a normal class, so 'protected' helper methods compile fine and are governed only by inheritance. Kotlin/C#: same - controllers are ordinary classes with full visibility ranges. EK9: services are dedicated entry-point constructs, not inheritable classes, so 'protected' is rejected at compile time (E07240); internal helpers use 'private' instead.

Keywords: method, web, service, protected, visibility, helper, rest, modifier, private, E07240