risposta finale
Combinando le ripuliture codice spiegato nel La tua risposta ripulito sezione sottostante con i miglioramenti di Pepe Schwarz citati nel Expectation avviso la seguente sezione si ottiene:
use java::util::zip::CRC32:from<Java>;
my $crc = CRC32.new();
for 'Hello, Java'.encode('utf-8').list {
$crc.update($_);
}
say $crc.getValue();
La tua risposta ripulito
use v6;
use java::util::zip::CRC32:from<Java>;
my $crc = CRC32.new();
for 'Hello, Java'.encode('utf-8').list { # Appended `.list`
$crc.'method/update/(I)V'($_);
}
say $crc.getValue();
Un importante po 'cambiato è l'aggiunto .list
.
Il frammento 'Hello, Java'.encode('utf-8')
restituisce un oggetto, un utf8
. Quell'oggetto restituisce un solo valore (stesso) all'istruzione for
. Quindi lo for
itera solo una volta, passando l'oggetto al blocco di codice con la riga update
al suo interno.
Iterando sola volta potrebbe senso se la linea update
era .'method/update/([B)V'
, che associa ad un metodo Java che prevede un buffer di 8 bit interi, che è essenzialmente quello di Perl 6 è utf8
.Tuttavia, ciò richiederebbe un certo supporto del codice Perl 6 (presumibilmente nel compilatore principale) per effettuare il marshalling (automagicamente convertito) del Perl 6 utf8
in un Java buf[]
e se quel codice è mai esistito/funzionato sicuramente non funziona quando eseguo il test con il ultimo Rakudo.
Ma se si aggiunge un giudizioso .list
come mostrato sopra e si modifica il blocco di codice in modo che corrisponda, le cose si risolvono.
Innanzitutto, il .list
genera la dichiarazione for
che itera su una serie di numeri interi.
In secondo luogo, come te, ho chiamato la versione di Integer arg del metodo Java (.'method/update/(I)V'
) invece della versione di arg buffer originale e il codice funzionava correttamente. (Ciò significa che la rappresentazione binaria dei unsigned 8 bit interi restituito dall'oggetto Perl 6 utf8
o è già esattamente ciò che il metodo di Java si aspetta o si automagicamente marshalling per voi.)
Un altro cambiamento richiesto è che il from<java>
esigenze a essere from<Java>
per il tuo commento qui sotto - grazie.
Expectation avviso
A partire dal gennaio 2015:
Semplicemente utilizzando il backend JVM per Rakudo/NQP (vale a dire l'esecuzione di codice P6 puro su una JVM) ha ancora bisogno di più indurimento prima che possa essere ufficialmente dichiarato pronto per l'uso produttivo. (Questo è in aggiunta alla tempra a tutto tondo che l'intero ecosistema P6 dovrebbe subire quest'anno.) Il back-end JVM si spera che ci arrivi nel 2015 - si spera che faccia parte del lancio ufficiale iniziale di Perl 6 pronto per produzione utilizzata quest'anno, ma ciò dipenderà in larga misura dalla domanda e da un maggior numero di sviluppatori che lo utilizzano e contribuiscono con le patch.
codice P6 che chiama codice Java è un progetto aggiuntivo. Pepe Schwarz ha compiuto grandi progressi negli ultimi due mesi per imparare a usare il codebase e lo landing commits. Ha già implementato la chiamata di shortname ovviamente più bella mostrata all'inizio di questa risposta e completato molto più logiche di marshalling per la conversione tra tipi P6 e Java e sta sollecitando attivamente feedback e richieste di miglioramenti specifici.
FWIW, [recente discussione Java interoperabilità sul canale IRC freenode # perl6] (http://irclog.perlgeek.de/perl6/2014-11-28#i_9733083). – raiph
Fwiw, nel calendario dell'avvento di quest'anno c'è [Towards cleaner JVM interop] (http://perl6advent.wordpress.com/2014/12/12/day-12-towards-cleaner-jvm-interoperability/). – raiph