См. Ответ jnthn для авторитетного обсуждения того, что именно произошло rebless
и что с этим делать.
это сработало ... Теперь это не так .. Сообщение об ошибке не имеет смысла ... оно должно работать с унаследованными классами ... По крайней мере, так было ... Документация не помогает
Этот (очень длинный!) Ответ может быть полезен для тех, кто заинтересован в дальнейшем обсуждении принципов и практики подхода TDD, который лежит в основе работы над языком программирования Raku и связанными с ним артефактами, такими как компилятор Rakudo и контент docs.raku.org. ,
Этот ответ структурирован как конкретные ответы на конкретные части исходного вопроса Арне и комментариев, которые они написали в ответ на более раннюю версию этого ответа. Мое намерение состояло в том, чтобы сделать это более полезным для Арне, и, надеюсь, все еще быть полезным для других.
Арне: Код, приведенный в этой теме, больше не работает: как я могу перебить объект в Раку?
Я обновил принятый ответ для этого SO, чтобы связать с этим SO.
Арне: Я написал этот кусок кода в прошлом году, и тогда он работал. Теперь это не
Соответствующее изменение обсуждалось в апреле 2019 года, в котором jnthn писал:
В последнее время типы, которые были целью rebless
операции, стали нуждаться в явном создании в качестве целевых типов смешивания, чтобы помочь оптимизации. ...
В комментарии 11 дней назад, закрыв вопрос Rakudo GH «Rebless для нестандартного типа, похоже, больше не работает» , он написал:
Вам нужно будет организовать передачу is_mixin
именованного аргумента в ClassHOW.new_type
... С синтаксисом класса это сделать невозможно, поэтому целевой тип rebless должен быть также собран с использованием MOP.
(Нажмите на ссылку выше для заметок о том, как сделать то, что он предлагает.)
Эта проблема также обсуждается немного дальше, так как она сработала ... она вдруг не ... документация ... должна документировать секцию вызова ниже.
Арне: предполагается работать с унаследованными классами. По крайней мере, так и было.
жаркий - г epository о еЛ.Л. s PEC т ресы - определяетчто Рака код должен делать. (The ул из ROA ул может быть прочитана как с upposed т о с.)
В другом сообщении за апрель 2019 года jnthn написал:
Там не было никаких предыдущих спецификаций для Metamodel::Primitives.rebless
. Я добавил этот тест, так что теперь есть. Это означает, что теперь есть какое-то определение того, что может сработать.
Тот факт, что поведение Rakudo определяется исполняемым набором тестов, является фундаментальной частью подхода @ Larry к обеспечению надежного поведения Raku [1] и имеет серьезные последствия [2] .
Влияние этого изменения на широко используемый модуль
Вот снимок влияния этого изменения на популярный модуль Inline :: Perl5.
В апреле 2019 года Niner открыл вопрос о рахудо GH,Inline::Perl5
и я выделил некоторые основные моменты обмена между Niner и Jnthn ниже.
(Я упустил некоторые вещи, которые были важны в исходном контексте, но отвлекали в контексте этой SO. Пожалуйста, не предполагайте, что у вас есть полное понимание оригинального разговора из этого фрагмента. Если вы сомневаетесь, нажмите на ссылку. )
niner: TBH, что я здесь делаю, вероятно, всегда было немного подозрительно ... Может даже быть так ... Я могу избавиться от [этого] ... Было бы неплохо, хотя бы поддерживать уже развернутые версии Inline :: Perl5 и работать ,
jnthn: не было предыдущей спецификации для Metamodel::Primitives.rebless
. Я добавил [a] spectest, так что теперь есть. Это означает, что теперь есть какое-то определение того, что может работать, и на что может положиться Inline :: Perl5.
Поскольку неизвестные именованные параметры игнорируются, но :mixin
не требовались в предыдущих версиях Rakudo, можно было бы сделать новый выпуск Inline :: Perl5, который может работать как с предыдущими версиями Rakudo, так и с будущими, так что, по крайней мере, может быть обратно-Compat.
Я не думаю, что есть какой-то способ заставить вещи работать для существующих версий Inline :: Perl5 ...
niner: К сожалению :mixin
, в этом случае передача не помогает, так как rebless выполняется для подкласса класса, созданного с помощью Metamodel::Primitives.create_type
. Подкласс использует нормальный Perl6::ClassHOW
.
Я работаю над крупным рефакторингом, чтобы сначала избавиться от взлома. Я снова открываю эту проблему, чтобы менеджер релизов знал, что на кандидате на выпуск rakudo не работает Inline :: Perl5.
jnthn: вы создаете этот класс с помощью MOP? Вы можете перейти :is_mixin
к, Perl6::ClassHOW.new_type
если так.
Нинер: Нет, это для этой ситуации:class Bar is Foo { }
Помощь с документами
В комментарии под этим ответом вы написали:
Я могу помочь с частью документации
Это звучит для меня как очень подходящий и полезный ответ на проблему, лежащую в основе вашего SOQ. Я надеюсь, что нам достаточно повезло, что это происходит.
если это поможет
Мне кажется, ваше техническое сочинение превосходно, поэтому я надеюсь, что конечный результат вашей работы с другими людьми, участвующими в его улучшении, будет замечательным.
Основные ограничения на содержание docs.raku.org
Большая часть причины, по которой я написал остальную часть этого очень обширного ответа на такой, казалось бы, простой вопрос, и восстановила его после первоначального удаления после того, как Джонатан ответил на него, состояла в том, чтобы обсудить принципы и практику подхода TDD , лежащего в основе работы над язык программирования Raku и связанные с ним артефакты, такие как компилятор Rakudo и контент docs.raku.org .
Во-вторых, желаемая связь между тем, как вещи должны работать в Раку, и тем, как они действительно работают в Ракудо, и тем, как вещи должны документироваться на docs.raku.org, сводится к следующему:
Все должны считаться , чтобы всегда быть предметом фундаментального характера проекта волонтеров; и в рамках этого ограничения:
Поведение при жарке ДОЛЖНО быть документировано, а другое поведение НЕ ДОЛЖНО.
(Учитывая доступное время, интерес и согласие добровольцев, иногда делаются исключения для документирования поведения Rakudo с должным качеством, которое не покрыто жареным. В текущей практике это, кажется, означает поведение версии Rakudo в выпущенной Rakudo Star.)
Бесполезная документация
Документация не полезна
Я посчитал это справедливым комментарием. Учитывая все обстоятельства, документация, которая была, когда вы писали свой вопрос, не была полезной.
документация была бесполезной [в 2018 году]
Это совсем другое утверждение.
В то время не было покрытия для жареного мяса rebless
.
Если страница docs.raku.org на rebless
была описана его поведение , как это было в 2018 году, то это было бы хуже , чем бесполезно , потому что это было бы неправильно полагать , что то текущее поведение было поддержано. В действительности у него была возможность сломаться в будущей версии Rakudo без разумной перспективы, что поведение разработчиков в 2018 году будет восстановлено. И действительно, это произошло: его неподдерживаемое поведение с 2018 года сломалось и не было восстановлено.
Итак, учитывая консенсус в отношении того, что принадлежит docs.raku.org, а что нет (см. Выше), наиболее полезная вещь, которую rebless
может сделать его страница, это либо вовсе не документировать документ, rebless
либо, возможно, лучше включить страницу для него, но убедитесь, что оно не описывает его поведение. Какова была ситуация: страница действительно существовала; не был непосредственно полезным; и это было возможно лучше, чем ничего.
(Легко представить, что дела еще лучше. Например, что, если функции страниц, документирующие функции, включают процент, документирующий состояние тестового покрытия, связанного с этой функцией, в версии Rakudo в последней версии Rakudo Star? 0% могли бы сразу подсказать читателю в осознание того, что эта функция не была покрыта жареным. Тем не менее, хотя эту функцию документа легко представить , кто ее реализует? Столь же легко представить, что это может занять календарный год или более усердной работы. и сотрудничество для полезной реализации и развертывания, и что люди думают, что другие вещи более важны.)
это сработало ... вдруг не сработало ... документация ... должен документировать звонок
это сработало
Это была «удача», это сработало.
это внезапно перестало работать
Потому что Ракудо был улучшен.
документация ... должна документировать звонок
Как объяснялось ранее, в настоящее время консенсус и / или рабочая практика сообщества таковы: документация ДОЛЖНА документировать конкретную версию вызова, а именно поведение roast для версии Rakudo в последней версии Rakudo Star; и МОЖЕТ документировать поведение в других версиях.
и не ссылаться на что-то другое
Aiui, текущий консенсус и / или рабочая практика заключается в том, что то, что некоторые могут считать «слабыми» документами, например, кратким, поспешно написанным контентом и / или ссылками за пределами документов, МОЖЕТ быть введено, если добровольцы чувствуют необходимость немедленного изменения, чтобы отразить некоторая обеспокоенность, высказанная пользователем (например, это SO) и то, что делать «слабые» изменения было бы лучше, чем вообще ничего не делать. Конечно, вы можете сделать пиар, чтобы улучшить его (или отменить его, если вы действительно чувствуете, что изменение настолько «слабое», что ухудшает положение).
ссылка на изменения в 2019.11 по моим подсчетам - 7 месяцев
(По моим подсчетам, что-то вроде этого, хотя я видел компилятор, претендующий на 2019.03.1 с таким же перерывом в поведении. [3] )
Я думаю, что Джей Джей внес изменения в документ, и он просто неверно истолковал комментарий Джнтн о том, как адаптироваться к этому изменению. В настоящее время я думаю, что это лучше, чем ничего, но с нетерпением жду вашего обновления. :)
Сноски
[1] Следующее было сказано через несколько минут после того, как Ларри впервые объявил о проекте, который привел к Раку в его речи 2000 года «Состояние лука» :
Вопрос: У [Раку] будут спецификации?
Ларри: то, что мы особенно хотим подчеркнуть ... это, пожалуй, не столько спецификация [языкового дизайна], сколько разработка нашего текущего регрессионного теста ... в проверочный тест того, что на самом деле означает язык, и на самом деле исследовать все уголки мира. и щеки и говорят: «Это [Раку], это не [Раку]», и тогда у нас фактически есть машиночитаемая спецификация. И для меня это на самом деле намного важнее, чем то, что говорит словоблудие в понятной человеку информации.
[2] Конечно, жаркое хорошо работает только для данного пользователя, если его тесты в достаточной степени удовлетворяют потребности пользователя. Проблема Арне демонстрирует, как дыры в освещении могут быть удивительными. Для обсуждения этих дыр, как они стояли в 2018 году, см. О спецификациях, версиях, изменениях и ... поломках . Хорошая новость заключается в том, что roast - это просто множество модульных тестов, написанных на Raku для проверки того, что выражения или конструкции с определенными значениями выполняют определенную функцию. Поэтому отдельным лицам или корпорациям легко вносить новые тесты для улучшения охвата тестов. И все это под контролем версий (git), поэтому пользовательские теги, ветки и ветки ниже по потоку жизнеспособны, устойчивы и управляемы. ( На самом деле, это как новые языковые версии ( Christmas
, Diwali
, Eid
(?), И т.д.) управляются.)
[3] Я видел попытку повторно использовать новый класс, созданный с использованием обычного newclass is oldclass
синтаксиса, который работает (на моем ноутбуке) и не работает (на repl.it) с использованием компиляторов, которые утверждают, что это так 2019.03.1
. (Предположим, repl.it установил версию исходного кода компилятора или скомпилированный из него бинарный файл, взятый из главной главы вскоре после обновления версии компилятора 2019.03.1
, с критическим изменением на месте. Я отмечаю, что repl.it haven ' Я опубликовал их онлайн-реплан Raku - я обнаружил это случайно - так что в этой ситуации нет ничего плохого, но это усилило для меня необходимость в $RAKU.compiler.verbose-config
методе, используемом в обработанных / неработающих выходных данных, которые я только что связал.)