State and Getters

Object state can be exposed as a Dagger Function, without having to create a getter function explicitly. Depending on the language used, this state is exposed using struct fields (Go), object attributes (Python) or object properties (TypeScript).

:::warning Dagger only exposes a struct's public fields; private fields will not be exposed. :::

Here's an example where one struct field is exposed as a Dagger Function, while the other is not:

</TabItem> <TabItem value="python" label="Python"> The [`dagger.field`](https://dagger-io.readthedocs.io/en/latest/module.html#dagger.field) descriptor is a wrapper of [`dataclasses.field`](https://docs.python.org/3/library/dataclasses.html#mutable-default-values). It creates a getter function for the attribute as well so that it's accessible from the Dagger API.

Here's an example where one attribute is exposed as a Dagger Function, while the other is not:

python

Notice that compared to dataclasses.field, the dagger.field wrapper only supports setting init: bool, and both default and default_factory in the same default parameter.

:::note In a future version of the Python SDK, the dagger.function decorator will be used as a descriptor in place of dagger.field to make the distinction clearer. :::

</TabItem> <TabItem value="typescript" label="TypeScript"> TypeScript already offers `private`, `protected` and `public` keywords to handle member visibility in a class. However, Dagger will only expose those members of a Dagger module that are explicitly decorated with the `@func()` decorator. Others will remain private.

Here's an example where one field is exposed as a Dagger Function, while the other is not:

typescript

</TabItem> <TabItem value="php" label="PHP"> The PHP SDK only exposes `public` fields decorated by the `#[DaggerFunction]` attribute. This behaviour is consistent with how functions are exposed.

Here's an example where one field is exposed as a Dagger Function, while the other is not:

php

</TabItem> <TabItem value="java" label="Java"> Dagger will automatically expose all public fields of a class as Dagger Functions. It's also possible to expose a package, `protected` or `private` field by annotating it with the `@Function` annotation.

In case of a field that shouldn't be serialized at all, this can be achieved by marking it as transient in Java.

Here's an example where one field is exposed as a Dagger Function, while the other is not:

java

</TabItem> </Tabs>

Confirm with dagger call --help or .help my-module that only the greeting function was created, with name remaining only a constructor argument:

FUNCTIONS
  greeting      The greeting to use
  message       Return the greeting message

ARGUMENTS
      --greeting string   The greeting to use (default "Hello")
      --name string       Who to greet (default "World")