Herança e composição

Os módulos se apoiam uns nos outros, e nada disso é criar subclasses. Não existe um módulo base do qual derivar nem uma hierarquia para estender: os módulos formam um grafo. Esta página explica o que “herança” quer dizer aqui e apresenta os seis mecanismos que fazem esse trabalho no lugar dela.

O que “herança” quer dizer aqui

A palavra cobre quatro mecanismos diferentes:

Os RPCs de uma entidade fazem parte da entidade. Eles não existem em nenhum outro lugar: nem numa classe pai, nem num registro compartilhado. Veja Entity.
Um preset é um pacote com nome, e não uma classe base. Stats, habilidades, projéteis, geradores de drops e objetos do mundo são presets de entity — pacotes de aspectos que uma visão de entidade aplica. Por isso eles ficam juntos em uma única página, Entity Presets, em vez de virarem cinco módulos. Aplicar um preset adiciona aspectos, mas não coloca o seu tipo embaixo de nada.
Para sobrescrever uma etapa da plataforma, basta um atributo na versão que a substitui. Você não cria uma subclasse da nossa: declara a sua. A versão é escolhida por condição e, quando nenhuma se aplica, vale o padrão da plataforma. Veja Extensibility.
Um módulo toma outro emprestado por meio de um decorator, que restringe ou enriquece a interface emprestada, e a implementação por trás dela pode ser trocada. O exemplo completo, um chat dentro de uma sala (room), está em Groups.

Não existe uma hierarquia de classes de módulos, porque uma árvore só admite galhos, e os recursos de um jogo de verdade cruzam esses galhos. O matchmaking reserva vagas (seat) nas salas. Os drops posicionam itens por meio do mapa. Um ranking é alimentado por um hook que dispara quando uma sala fecha.

Os seis mecanismos

Cada um é declarado com um atributo ao lado daquilo que compõe — a mesma regra declarativa que vale para todo o resto do SDK.

Pontos de montagem, como num sistema de arquivos. Um módulo é montado na raiz — juntando várias interfaces em uma só — ou dentro de um namespace. Um segundo módulo que tenta ocupar um ponto de montagem já ocupado é rejeitado no momento da montagem, nunca na primeira chamada. O mecanismo está em Por baixo dos panos.

Visibilidade léxica. A visibilidade dos nomes segue o aninhamento: uma declaração global é visível dentro de um módulo, e uma local nunca vaza para cima. O que um módulo emite é outra questão, declarada no próprio contrato dele — um módulo conhece apenas os eventos que declarou ou que foram registrados nele.

Encapsulamento como contrato. Um módulo nunca sabe quem o chama nem por quê. O que ele expõe e o que ele emite formam todo o seu contrato público, e nada em quem chama muda o comportamento dele, a não ser as permissões concedidas a quem chama.

Reuso por decorator e inversão de controle. Um módulo se refere a outro por meio de um decorator, sem mexer no interior dele, e a implementação por trás da interface pode ser trocada. É esse mecanismo que permite substituir um dos nossos módulos pelo seu sem que os módulos que dependem dele percebam.

As declarações fazem a API crescer. Declare um evento em um grupo, e group.Send.ChatMessage(…) aparece com o seu contrato. Declare os dados members, e aparece um getter tipado. A declaração é a entrada da geração de código — e é também por isso que você versiona a declaração, e não o código gerado.

Três eixos de endereçamento a partir de um só módulo. Todas as instâncias, uma instância e o administrador de uma instância são três APIs distintas, e não uma API com uma flag. A descrição completa está em Groups.

Argumentos implícitos

Dentro de uma entidade, você nunca passa a própria entidade. O receptor, quem chama e o contexto em volta são vinculados automaticamente, porque os três já estão determinados pelo lugar de onde a chamada foi feita e por quem a fez. O mecanismo está em RPC.