@[Print(scale: 1)]

   property weight : Float32 = 56.789

end

MyClass.new.print

Результатом этого может быть следующее:

---

name: Jim

created_at: 2021-11-16

weight: 56.8

---

Чтобы реализовать это, логика печати должна иметь доступ как к данным аннотации, так и к значению переменной экземпляра, которая должна быть напечатана. В нашем случае модуль Printable позаботится об этом, определяя метод, который обрабатывает итерацию и печатает каждую применимую переменную экземпляра. В конечном итоге это будет выглядеть так:

module Printable

  def print(printer)

    printer.start

      {% for ivar in @type.instance_vars.select(&.annotation Print) %}

        printer.ivar({{ivar.name.stringify}},

        @{{ivar.name.id}},

        {{ivar.annotation(Print).named_args.double_splat}})

      {% end %}

    printer.finish

  end

  def print(io : IO = STDOUT)

    print IOPrinter.new(io)

  end

end

Большая часть логики выполняется в методе #print(printer). Этот метод напечатает начальный шаблон, которым в данном случае являются три тире. Затем он использует макрос цикла for для перебора переменных экземпляра включающего типа. Переменные экземпляра фильтруются таким образом, что включаются только те, у которых есть аннотация Print. Затем для каждой из этих переменных вызывается метод #ivar на принтере с именем и значением переменной экземпляра, а также любых именованных аргументов, определенных в аннотации. Наконец, он печатает конечный образец, который также состоит из трех тире.

Для поддержки предоставления значений из аннотации мы также используем метод NamedTupleLiteral#double_splat вместе с Annotation#named_ args. Эта комбинация предоставит любые пары ключ/значение, определенные в аннотации, в качестве именованных аргументов для вызова метода.

Метод #print(io) служит основной точкой входа для печати экземпляра. Он позволяет предоставить пользовательский I/O, на который должны выводиться данные, но по умолчанию это STDOUT. I/O используется для создания другого типа, который фактически выполняет печать:

struct IOPrinter

  def initialize(@io : IO); end

  def start

    @io.puts "---"

  end

  def finish

    @io.puts "---"

    @io.puts

  end

  def ivar(name : String, value : String)

    @io << name << ": " << value

    @io.puts

  end

  def ivar(name : String, value : Float32, *, scale :

    Int32 = 3)

    @io << name << ": "

    value.format(@io, decimal_places: scale)

    @io.puts

  end

  def ivar(name : String, value : Time, *, format : String

    = "%Y-%m-%d %H:%M:%S %:z")

    @io << name << ": "

    value.to_s(@io, format)

    @io.puts

  end

end

Этот тип определяет начальный и конечный методы, а также перегрузку для каждого из поддерживаемые типы переменных экземпляра, каждый из которых имеет определенные значения и значения по умолчанию, связанные с этим тип. Используя отдельный тип с перегрузками, мы можем раньше отловить по ним ошибки. являются ошибками времени компиляции, например, если вы использовали аннотацию для неподдерживаемого введите или не указал значение в аннотации для обязательного аргумента. Этот пример показывает, насколько гибкими и мощными могут быть аннотации Crystal в сочетании с другими понятиями, такими как композиция и перегрузки. Однако бывают случаи, когда вы можете захотеть отделить логику от самого типа, например, чтобы сохранить вещи слабо связанный.

В следующем разделе мы рассмотрим, как мы можем сделать шаг вперед в том, что мы уже узнали, разрешив использование данных аннотаций/типов во время выполнения, чтобы их можно было использовать по мере необходимости.

Предоставление данных времени компиляции во время выполнения

Как мы закончили в предыдущем разделе, предоставление данных аннотации за пределами самого типа может быть хорошим способом сделать вещи менее связанными. Эта концепция фокусируется на определении структуры, которая представляет параметры связанной аннотации, а также другие метаданные, относящиеся к элементу, к которому была применена аннотация.

Если структура, представляющая данные аннотации, имеет обязательные параметры, которые, как ожидается, будут предоставлены через аннотацию, программа не будет компилироваться, если эти значения не будут предоставлены. Он также обрабатывает случай, когда параметры имеют значение по умолчанию. Кроме того, если в аннотации есть неожиданное поле или аргумент неправильного типа, она также не будет скомпилирована. Это значительно упрощает добавление / удаление свойств из структуры, поскольку все они не должны быть явно заданы в StringLiteral.

В настоящее время существует Crystal RFC, который предлагает сделать этот шаблон более встроенной функцией, сделав аннотацию и структуру одним и тем же. См. https://github.com/crystal-lang/crystal/issues/9802 для получения дополнительной информации.

Есть несколько способов фактически раскрыть структуры:

• Определите метод, который возвращает их массив.

• Определите метод, который возвращает хэш, который предоставляет их по имени переменной экземпляра.

• Определите метод, который принимает имя переменной экземпляра и возвращает его.

У каждого из этих подходов есть свои плюсы и минусы, но все они имеют что-то общее. В самом экземпляре/типе должна быть какая-то точка входа, которая предоставляет данные. Основная причина этого заключается в том, что переменные экземпляра можно повторять только в контексте метода.

Кроме того, существует два основных способа обработки самих структур. Один из вариантов — сделать метод методом экземпляра и включить значение каждой переменной экземпляра в структуру. У этого подхода есть несколько недостатков, например, его сложнее запомнить и он не очень хорошо обрабатывает обновления. Например, вы вызываете метод и получаете структуру для данной переменной экземпляра, но затем значение этой переменной экземпляра изменяется до того, как будет выполнена фактическая логика. Значение в структуре может представлять только значение на момент вызова метода.

Другой подход — сделать метод лениво инициализируемым запоминаемым методом класса. Этот подход идеален, потому что:

1. Он создает хэш/массив только для типов, которые используются вместо каждого типа/экземпляра.

2. Он кэширует структуры, поэтому их нужно создать только один раз.

3. Это имеет больше смысла, поскольку большая часть данных будет относиться к данному типу, а не к экземпляру этого типа.

Для целей этого примера мы собираемся создать модуль, который определяет лениво инициализированный метод класса, который будет возвращать хеш свойств этого типа. Но прежде чем мы это сделаем, давайте подумаем, какие данные мы хотим хранить в нашей структуре. Чаще всего структура представляет переменную экземпляра вместе с данными из примененной к ней аннотации. В этом случае наша структура будет иметь следующие поля:

1. name – название объекта недвижимости.

2. type– тип объекта недвижимости.

3. class – класс, частью