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
– название объекта недвижимости.