Newsgroup: it.comp.lang.perl
Titolo: scalar() e ${}

Ma scrivendo scalar(@array) o ${@array} si ottiene la stessa cosa, ossia 
il numero degli elementi dell'array @array?
ciao,
ilp

 il numero degli elementi dell'array @array?
Se l'array viene valutato in contesto scalare, allora tutto va come se 
all'array fosse stata applicata la funzione scalar(), esattamente come 
ti ha detto Marco (rendendo quindi superfluo l'uso esplicito di scalar).
Ma attenzione, scalar(@array) e ${@array} *non* sono per niente la 
stessa cosa.
Il costrutto ${ $var } ha tutt'altro uso: serve a dereferenziare un 
reference ad uno scalare.
Quindi se scrivi:
${ @array }
l'array viene valutato in contesto scalare (come diceva appunto Marco), 
dal momento che il nostro costrutto si aspetta un reference tra le 
parentesi graffe (e un reference è sempre uno scalare, ovviamente).
Pertanto @array valutato in contesto scalare restituisce la sua 
dimensione, la quale non è certo un reference, e quindi viene generato 
un errore (se sei sotto strict refs):
use strict;
my @array = 11..20;
print ${ @array };
Can't use string ("10") as a SCALAR ref while "strict refs" in use...
Se non fossimo sotto strict, cosa da non fare *mai* o quasi (ma per 
adesso dimentica il "quasi"), perl interpreterebbe il valore restituito 
da @array (ovvero la sua dimensione) come un reference simbolico (i 
symbolic reference sono un'altra cosa largamente deprecata), e quindi 
non darebbe errori (ma nel nostro caso genererebbe un warning).
Se può servire a chiarire il concetto, si ha invece che i seguenti due 
costrutti sono semanticamente quivalenti:
${ @array };
${ scalar @array };
(ed entrambi, sotto strict, generano l'errore di cui sopra).
In conclusione, quelli che sono equivalenti sono i due costrutti 
scalar(@array) e @array, se ci si trova in contesto scalare, come 
spiegato da Marco.
Ciao,
Emanuele.

 e ora sono uno splendido quarantenne."
Ciao,
   ho notato che tutti i tuoi post hanno l'indicazione:
Note: The author of this message requested that it not be archived.
This message will be removed from Groups in  X days (...).
almeno quando visti da Google Groups. Visto che le risposte che dai
sono utili anche dopo la scadenza... non si può evitare? :D
Ciao,
   Flavio.

 spiegato da Marco.
Secondo me, anche se sono equivalenti, conviene usare 
la versione in cui scalar viene esplicitamente indicato:
si vede a colpo d'occhio quello che l'autore intendeva, e 
non si devono esaminare i contorni del pezzo di codice
per valutarne il tipo di contesto. Che ne pensate ?
S.
-- 
Stefano Rodighiero      |  
http://larsen.perlmonk.org
mailto:
lar...@perl.it
   |  Italian Perl Mongers: 
http://www.perl.it

 di codice per valutarne il tipo di contesto. Che ne pensate ?
Sono d'accordo: uso sempre scalar() per rendere il codice piu' leggibile.
 Raffaello

il Pigro ha scritto:

Ma voi come la scrivereste la funzione scalar? Basta che essa valuti 
l'array passatole in contesto scalare, e ritorni ciò, no?
ciao,
ilp

 rispondevo come voleva lui, ho deciso che era meglio così.
[snip]
Peccato, dovrebbero fare un tag X-anonymize che dopo tot giorni
elimina
indirizzo e nome del mittente... Buono a sapersi, comunque, anche se
non
credo che arriveranno mai a subissare *me* :D

 per valutarne il tipo di contesto. Che ne pensate ?
Dunque, benché nel mio messaggio non intendessi avanzare consigli 
stilistici (tentavo solo di spiegare in quali casi i due costrutti 
risultavano equivalenti), in effetti propendo (blandamente) per 
l'omissione di scalar(), almeno nei casi più semplici, perché mi sembra 
che costrutti tipo:
my $num_elementi  = @array;
my $ultimo_indice = @array - 1;   # o $#array;
siano più concisi, naturali e leggibili per chi sia fluente in Perl, 
essendo la determinazione del contesto assolutamente chiara, immediata e 
priva di ambiguità.
Certo, potrebbero richiedere qualche supplemento di attenzione a chi sta 
imparando, ma quella del discente è una condizione transitoria.
Tali costrutti mi sembrano anche più vicini al linguaggio naturale, e 
benché legga del tuo dissenso su questo punto (nel thread con Flavio), a 
mio avviso si tratta di una metafora calzante.
Nel corso degli anni i linguaggi di programmazione si sono evoluti verso 
la leggibilità, tentando di avvicinarsi al linguaggio naturale, in 
ragione del fatto che *spessissimo* un listato costituisce una 
comunicazione tra esseri umani (scambio di specifiche, descrizione 
formale di un algoritmo, sviluppo di codice in forma collaborativa etc.)
Poi non so se le tue obiezioni vertessero proprio su questo...
Un saluto,
Emanuele.