Objeto clonado Raku no hundido
class A {
has $.n; # If this method is uncommented then the clone won't be sunk # method clone { # my $clone = callwith(|%_);
# return $clone; # } method sink(-->Nil) { say "sinking...$!n" }
}
sub ccc(A:D $a) { $a.clone(n=>2) }
ccc(A.new(n=>1));
say 'Done';
Impresiones arriba:
sinking...2
Done
Sin embargo, si clonese usa el método personalizado , el clon devuelto de cccno se hundirá por alguna razón. Funciona si lo hago sinkexplícitamente en el sitio de llamada o si cambio la my $clone = callwith(|%_)línea a my $clone := callwith(|%_). ¿Es esto esperado? ¿Cuál es la razón por la que funciona de esta manera?
¡Gracias!
Respuestas
Hay muchos errores de sumidero archivados y todavía abiertos años después (y, sospecho, cargas que no se han archivado).
Como se mencionó en mi respuesta al Último elemento de un bloque lanzado en el contexto del sumidero :
alguien necesita limpiar el fregadero de la cocina, es decir, retomar donde lo dejó Zoffix con sus defectos en el hundimiento implícito y el problema del ayudante no deseado .
La conclusión de Zoffix fue:
Entonces, dado que hay tantos problemas con el sistema, me pregunto si no hay uno mejor que pueda usarse para indicar si se desea algo o no.
Avance rápido 2 años y, con suerte, un sistema mejor va a aterrizar. En un informe de subvención reciente, jnthn escribe:
El código actual que hace este trabajo en Rakudo es difícil de seguir y no es terriblemente eficiente. ... Dado que RakuAST modela el lenguaje a un nivel superior y pospone la producción de QAST hasta mucho más tarde, es posible una solución mucho más limpia al problema del análisis de sumideros. ... Soy optimista de que el modelo que he creado será lo suficientemente flexible para manejar todos los requisitos relacionados con el hundimiento
No estoy seguro de lo que está sucediendo todavía, pero eliminar la returndeclaración hace que el objeto clonado llame al sinkmétodo correcto .
He creado un problema para ello: https://github.com/rakudo/rakudo/issues/3855