Decorators

Bebop provides a metadata mechanism in the form of decorators. Decorators are placed on definitions, fields, and methods to modify the behavior of generated code.

The compiler provides some built-in decorators, and through the extension framework, you can add your own.

Built-in decorators

@deprecated

You use the deprecated decorator to mark a definition, field, or method as deprecated. The compiler will emit generated code with deprecation warnings / documentation so it is picked up by your IDE.

Further, when placed on a message field, during encoding that field will be skipped.

message Song {
    @deprecated("We no longer use this")
    1 -> string title;
    2 -> uint16 year;
}

Note

The deprecated decorator cannot be used on the fields of a struct, but only on the struct itself.

@opcode

Use the opcode decorator before a record definition to associate an identifying “opcode” with it. You can either specify a 32-bit unsigned integer:

@opcode(0x12345678)
message Song {
    1 -> string title;
    2 -> uint16 year;
}

Or a FourCC string:

@opcode("SONG")
message Song {
    1 -> string title;
    2 -> uint16 year;
}

Strictly speaking, Bebop is not opinionated about what you do with these opcodes. You can roll your own bespoke RPC or dispatcher (see Bebop Mirrors), however, we recommend using Tempo (our offical RPC framework).

To compiler verifies that within the context of all the schemas in your project that no opcode is used twice. This is to prevent collisions.

@flags

See Flags in the enum reference.

Contributed Decorators

Extensions can contribute their own decorators. See the Extensions section for more information.