Код, приведенный в этом потоке, больше не работает: как я могу восстановить объект в Perl 6?
Я написал этот кусок кода в прошлом году, и тогда это сработало. Теперь это не так:
class Person { ; }
class Woman is Person { ; }
my $tom = Person.new;
my $lisa = Woman.new;
say $tom.^name; # -> Person
say $lisa.^name; # -> Woman
Metamodel::Primitives.rebless($tom, Woman);
# -> New type Woman for Person is not a mixin type
Сообщение об ошибке не имеет смысла, так как предполагается, что оно работает с унаследованными классами. По крайней мере, так и было.
Документация не полезна; https://docs.raku.org/routine/rebless
Ответы:
Он никогда не должен был быть таким генералом. Я спроектировал этот API и реализовал его в первую очередь, и он когда-либо был задуман только как деталь реализации миксинов.
До недавнего времени он не был частью набора тестов языковых спецификаций - и когда он стал его частью, он уже имел свою нынешнюю, более ограничивающую семантику. Его ограничения важны с точки зрения производительности: когда мы знаем, что тип не является тем, который может быть целью операции mixin, мы можем JIT-компилировать доступ к атрибуту этого объекта во что-то гораздо более простое (мы заплатили дополнительный условный переход на доступ к каждому атрибуту до изменения, и теперь нужно платить только по мишеневым типам).
Можно изменить исходную программу для работы с помощью MOP для создания класса. На самом деле следующее не совсем оригинальная программа; Я сделал небольшую настройку, чтобы показать, как можно предоставлять методы в подклассе в качестве анонимной роли, чтобы избежать слишком большого количества шаблонов MOP.
Хотя это наиболее семантически прямое исправление исходной программы, есть более короткий путь: используйте
but
оператор дляPerson
объекта типа, чтобы создать смешанный тип и вернуть его, а затем просто настроить его имя по своему вкусу:Который в любом случае на одну строчку больше оригинала.
источник
constant Woman = Person but role …
Не понимал, что это можно сделать. И, таким образом, кромеBEGIN
линии, Raku почти справляется с возможностью создать прототипную парадигму в стиле JS!class
ключевого слова , то, снова заключая в кавычки S12: «по умолчанию объекты, полученные из,Mu
поддерживают довольно стандартную модель на основе классов ...bless
... вызовы ... процедуры BUILD ... семантика BUILD по умолчанию наследуется отMu
". Подводя итог, я бы сказал, что точнее будет сказать, что Raku поддерживает A) «серьезно искажает даже стандартную OO, основанную на классах болота, всего с помощью пары строк кода» и B) «OO, основанную на прототипах».См. Ответ jnthn для авторитетного обсуждения того, что именно произошло
rebless
и что с этим делать.Этот (очень длинный!) Ответ может быть полезен для тех, кто заинтересован в дальнейшем обсуждении принципов и практики подхода TDD, который лежит в основе работы над языком программирования Raku и связанными с ним артефактами, такими как компилятор Rakudo и контент docs.raku.org. ,
Этот ответ структурирован как конкретные ответы на конкретные части исходного вопроса Арне и комментариев, которые они написали в ответ на более раннюю версию этого ответа. Мое намерение состояло в том, чтобы сделать это более полезным для Арне, и, надеюсь, все еще быть полезным для других.
Я обновил принятый ответ для этого SO, чтобы связать с этим SO.
Соответствующее изменение обсуждалось в апреле 2019 года, в котором jnthn писал:
В комментарии 11 дней назад, закрыв вопрос Rakudo GH «Rebless для нестандартного типа, похоже, больше не работает» , он написал:
(Нажмите на ссылку выше для заметок о том, как сделать то, что он предлагает.)
Эта проблема также обсуждается немного дальше, так как она сработала ... она вдруг не ... документация ... должна документировать секцию вызова ниже.
жаркий - г epository о еЛ.Л. s PEC т ресы - определяетчто Рака код должен делать. (The ул из ROA ул может быть прочитана как с upposed т о с.)
В другом сообщении за апрель 2019 года jnthn написал:
Тот факт, что поведение Rakudo определяется исполняемым набором тестов, является фундаментальной частью подхода @ Larry к обеспечению надежного поведения Raku [1] и имеет серьезные последствия [2] .
Влияние этого изменения на широко используемый модуль
Вот снимок влияния этого изменения на популярный модуль Inline :: Perl5.
В апреле 2019 года Niner открыл вопрос о рахудо GH,
Inline::Perl5
и я выделил некоторые основные моменты обмена между Niner и Jnthn ниже.(Я упустил некоторые вещи, которые были важны в исходном контексте, но отвлекали в контексте этой SO. Пожалуйста, не предполагайте, что у вас есть полное понимание оригинального разговора из этого фрагмента. Если вы сомневаетесь, нажмите на ссылку. )
Помощь с документами
В комментарии под этим ответом вы написали:
Это звучит для меня как очень подходящий и полезный ответ на проблему, лежащую в основе вашего SOQ. Я надеюсь, что нам достаточно повезло, что это происходит.
Мне кажется, ваше техническое сочинение превосходно, поэтому я надеюсь, что конечный результат вашей работы с другими людьми, участвующими в его улучшении, будет замечательным.
Основные ограничения на содержание docs.raku.org
Большая часть причины, по которой я написал остальную часть этого очень обширного ответа на такой, казалось бы, простой вопрос, и восстановила его после первоначального удаления после того, как Джонатан ответил на него, состояла в том, чтобы обсудить принципы и практику подхода TDD , лежащего в основе работы над язык программирования Raku и связанные с ним артефакты, такие как компилятор Rakudo и контент docs.raku.org .
Во-вторых, желаемая связь между тем, как вещи должны работать в Раку, и тем, как они действительно работают в Ракудо, и тем, как вещи должны документироваться на docs.raku.org, сводится к следующему:
Все должны считаться , чтобы всегда быть предметом фундаментального характера проекта волонтеров; и в рамках этого ограничения:
Поведение при жарке ДОЛЖНО быть документировано, а другое поведение НЕ ДОЛЖНО.
(Учитывая доступное время, интерес и согласие добровольцев, иногда делаются исключения для документирования поведения Rakudo с должным качеством, которое не покрыто жареным. В текущей практике это, кажется, означает поведение версии Rakudo в выпущенной Rakudo Star.)
Бесполезная документация
Я посчитал это справедливым комментарием. Учитывая все обстоятельства, документация, которая была, когда вы писали свой вопрос, не была полезной.
Это совсем другое утверждение.
В то время не было покрытия для жареного мяса
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.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
методе, используемом в обработанных / неработающих выходных данных, которые я только что связал.)источник
Дополнительный вопрос: см. Раклу Ресселс и несколько классов
источник