Newsgroup: it.comp.lang.javascript
Titolo: Opera 7.11

Ho finalmente installato Opera, se non altro per provarlo.
Ho fatto un breve giro per i miei sitarelli.. ok! Ma poi ho notato una
cosa scioccante: Opera NON MANTIENE L'ORDINAMENTO!! :(((
Ho un po' di menu creati a partire da letterali Object, e sono tutti
stravolti! Ma come? Perche'? ^^;;;;;

ignora opera, tanto una piccolissima percentuale degli utente di internet
usa opera.
Ciao
Marco

usa opera.
Ma che razza di suggerimento č? 
Se uno lavora con un minimo di professionalitą testa i propri lavori
con quanti + browser gli capitano sotto tiro, anche con Opera, anche
solo per vedere in che maniera il browser male interpreti eventuali js
e css.

 e css.
il problema e' che viene stravolto l'ordinamento dei campi degli
Object, e non e' una cosa da poco.
se io dichiaro
var myObj = { x: 100, y: 200, z: 300 };
e poi ciclo
for (var i in myObj)
   alert(i);
in IE, NN e Mozillla rispondono: x, y, z
Opera risponde: x, z, y (!)
dichiaro invece
var myObj = { z: 100, x: 200, y: 300 };
e risponde ancora: x, z, y (!!)
il problema e' che il tutto e' non deterministico! sembra che Opera
imponga un ordinamento proprio ai membri degli oggetti, ma non riesco
ad intuirne la regola (sicuramente non alfabetica!)
a parte ZER0, che mi pare abbia detto di ignorare Opera, come e'
possibile aggirare la cosa? Per non abbandonare gli Object in favore
degli Array che sono ordinali e riprogettare tutto daccapo, la cosa
piu' immediata che mi viene in mente e' di attribuire una proprieta'
aggiuntiva ai mebri con un indice e ordinarli da me in fase di
inizializzazione (pazzesco! ^^;;)
-- 
artemis.alpeia
http://spazioinwind.libero.it/artemis

 Object, e non e' una cosa da poco.
In realtà Opera lavora correttamente, il ciclo for/in non ti garantisce nulla  
riguardo l'ordine delle proprietà enumerabili presenti nell'oggetto, ti 
garantisce unicamente di ciclarle tutte prima di uscire.
E' facoltà delle diverse implementazioni darti in output un'ordine  
corrispondente a quello che tu hai seguito quando hai creato l'oggetto 
(che non è comunque un array...), certo sarebbe meglio se Opera si 
armonizzasse con IE e Gecko anche se non è richiesto dalle specifiche 
ecmascript.
Ti accorgi poi che basta poco per far divergere anche il comportamento 
di IE e Mozilla:
var myobj={a:100,b:200,c:300,d:400,e:500};
delete myobj.d;
myobj.d=400;
for(var i in myobj)document.write(i);
Comunque siccome più le implementazioni convergono e meno rogne vi 
sono per gli sviluppatori ho provveduto a inoltrare una segnalazione ad 
OperaSoftware per la prossima 7.20...
bye
armaged

 
per me il problema sta tutto in questo ciclo. (a me ha dato problemi 
anche con altri linguaggi di scripting)
per me ti va tutto se converti i tuoi script con il classico:
var i;
for (i=0; i < l; i++)

 for(var i in myobj)document.write(i);
Gia', tra l'altro il delete ha cmq avuto sempre comportamenti diversi 
da browser a browser.
-- 
C'ya,
  ZER0 :: coder.gfxer.webDesigner();
"When you have eliminated the impossible, whatever remains,
however improbable, must be the truth." (S.H.)

 possibile aggirare la cosa? 
Giusto per fare un piccolo test, ho provato con Opera 7.0.
Sul tuo esempio, funziona correttamente. Ovvero, mi visualizza in 
ordine x,y,z.
Cambiando l'ordine nel codice, il ciclo pero' continua a 
visualizzarmeli nello stesso medesimo ordine (prima x, poi y e poi z).
Sembrerebbe quindi che Opera 7.0 esegua un ordinamento alfabetico, 
invece non e' cosi'. Su un oggetto con proprieta' a, b, c l'ordine di 
visualizzazione e' c,a,b.
Veramente interessante. Forse dipende dal come esegue una malloc. O 
chissa' cos'altro. Bisognerebbe vedere se, specifiche alla mano, esiste 
quantomeno un discriminante "logico", se non "trappabile".
Il punto e' che, almeno ai tempi in cui cercavo di interessarmi anche 
al coding su Opera, non ho mai trovato documentazione specifica a 
riguardo. Gli sviluppatori demandavano tutto "agli standard", poco 
importa poi se in realta' c'erano bug conosciuti o meno, o le 
implementazioni dei suddetti standard erano un po' ballerine.
Questa e' una cosa che non mi e' mai piaciuta. Magari, adesso la 
situazione e' cambiata, chi segue Opera sa dove trovare materiale di 
riferimento, e una lista completa dei bug conosciuti o meno (un po' 
come bugzilla).


 e css.
Dipende che ci devi fare. Io per il coding ormai Opera lo ignoro a 
prescindere perche' non e' che, a differenza magari di altri browser, 
non implementa alcune feature, ma "millanta" ti implementarle. E 
questo, considerando il supporto un po' farlocco dello script engine, 
non contribuisce certo a fare del sano coding.
Ovviamente, e' una scelta mia.
Ma - come ho gia' detto - questo non ha nulla a che vedere con 
l'accessibilita' e usabilita' di un sito, che deve essere mantenuta 
indipendentemente dal dispositivo usato per navigare.
Il fatto di ignorare per determinati script Opera, non vuol dire che 
neghi a chi lo usa la possibilita' di accedere al sito e navigarci 
correttamente.
Opera puo' essere un ottimo browser per la visualizzazione di pagine 
(X)HTML, ma cade sul lato di scripting.


 come bugzilla).
se fosse open source sarebbe di certo cosi'
-- 
artemis.alpeia
http://spazioinwind.libero.it/artemis

 quanto Javascript.
Ecmascript è stato ratificato proprio con l'obiettivo di costituire uno 
standard internazionale di riferimento per i linguaggi di scripting.
Il linguaggio Javascript di Netscape fin dalla versione 1.3 si dichiara  
"fully compliant" con ecmascript (ecma-262), dunque devi fare 
riferimento ad ecmascript per capire se l'implementazione di javascript è 
standard o meno.
Ecmascript (e quindi javascript1.3+) non ti garantisce uno specifico 
ordine delle proprietà di un oggetto ciclato con una for-in, ma lascia 
all'implementatore la facoltà di scegliere l'ordine che ritiene più 
opportuno per un determinato oggetto, leggiti le specifiche.
Ciò non toglie che una convergenza nelle varie implementazioni di 
javascript (ecmascript compliant) è qualcosa di auspicabile e sarebbe 
cosa sana per Opera allinearsi...
bye
armaged   

 cosa sana per Opera allinearsi...
Non solo. Se non vuole allinearsi, okay, lo faccia pure. Ma almeno 
scriva da qualche parte il CRITERIO con cui ha implementato certe cose.
E' a discrezione dell'implementatore definire il criterio di 
enumerazione delle proprieta' di un oggetto? Perfetto.
Non e' quello che il senso comune suggerisce, e che viene generalmente 
implementato? Benissimo.
Che ci facciano sapere qual'e', questo criterio, almeno. Uno straccio 
di paginetta web con luna manciata di reference sul loro sito, per 
esempio. Non mi pare di chiedere tanto, in fondo.
Visto che io ho smesso di seguire Opera, che tu sappia c'e' qualcosa 
del genere sul loro sito?


 del genere sul loro sito?
Per capire il livello di adesione agli standard web da parte di Opera qui 
ci sono i riferimenti integrativi da conoscere: 
http://www.opera.com/docs/specs/
bye
armaged

 
http://www.opera.com/docs/specs/
Quindi non e' cambiato nulla. Come ho scritto in un post precedente, 
gli sviluppatori di Opera demandano tutto alle specifiche che hanno 
implementato. Poco importa che l'abbiano implementate male, o che 
laddove le specifiche lasciano liberta' agli implementatori, non sia 
stata stilata una reference in cui viene detto che tipo di "liberta' " 
hanno usato.
Gran bella roba, gia'.


(X)HTML, ma cade sul lato di scripting.
A sto punto usiamo Firebird che supporta entrambi bene ;-)
Tra l'altro non sapevo che Opera non avesse un motore XSLT...bah
-- 
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com
XmlDesk - 
http://tinyurl.com/fhrz
 - for Xml developers
UGIdotNET - User Group Italiano .NET - 
http://www.ugidotnet.org

 pare sia una cosa nettamente diversa).
---------------------------------------------------------------
ECMAScript is object-based: basic language and host facilities are 
provided by objects, and an ECMAScript program is a cluster of 
communicating objects. An ECMAScript object is an UNORDERED
collection of properties each with zero or more attributes that determine 
how each property can be used?
for example, when the ReadOnly attribute for a property is set to true, 
any attempt by executed ECMAScript code to change the value of the 
property has no effect. Properties are containers that hold
other objects, primitive values,ormethods. A primitive value is a member 
of one of the following built-in types: Undefined, Null, Boolean, 
Number,andString; an object is a member of the remaining built-in
type Object; and a method is a function associated with an object via a 
property.
--------------------------------------------------------------------
vedi un po' tu, è una specie di arrampicata sugli specchi la tua ? Occhio 
però, più in alto ti spingi e più male ti fai quando perdi la presa.....
bye
armaged

 collection of properties each with zero or more attributes that determine 
beh allora e' lo standard che fa acqua. Mi definisce una sintassi per
l'accesso alle proprieta' degli oggetti (operatore in) e ne lascia
indeterminato il comportamento. E poi, il fatto che la collection (o
array associativo) sia non ordinata, non vieta certo di stabilire un
ordinamento in fase di accesso ai campi.
-- 
artemis.alpeia
http://spazioinwind.libero.it/artemis

 ordinamento in fase di accesso ai campi.
Ecco il punto è tutto qua, non si può accusare Opera di violare gli 
standard, semmai ci si può chiedere il motivo per cui in fase di 
definizione dello standard ecmascript si è preferito non vincolare ad un 
preciso ordine le proprietà contenute in un oggetto.  
Questa è la definizione di oggetto che dà lo standard:
-----------------------------------------------------
4.3.3 Object
An object is a member of the type Object. It is an unordered collection 
of properties each of which contains a primitive value, object, or 
function. A function stored in a property of an object is called a
method.
------------------------------------------------------
E questa stessa definizione la ritrovi anche sui manuali Javascript più 
blasonati come il David Flanagan fin dalla versione 1.3 di javascript, 
molto Netscape oriented.
Il semplice esempio di codice che ti ho mostrato ti fa intuire che non 
basterebbe obbligare a listare le proprietà seguendo l'ordine iniziale ma 
bisognerebbe anche definire un preciso algoritmo nel caso di 
eliminazioni/aggiunte di una o più proprietà all'oggetto per non trovarsi 
con comportamenti imprevedibili.  
E guarda caso IE e Mozilla hanno comportamenti diversi dopo un 
semplice delete...
Il ciclo for-in è pensato evidentemente per fornirti tutte le proprietà 
enumerabili contenute nell'oggetto, poi sta a te ordinarle come più ti 
pare, in ordine alfabetico, alfabetico inverso, ecc..   in funzione 
dell'output che hai bisogno di fornire.
bye
armaged

 Tra l'altro non sapevo che Opera non avesse un motore XSLT...bah
Opera ha smesso di "stupirmi" da quel di'.


 però, più in alto ti spingi e più male ti fai quando perdi la presa.....
Non capisco perche' tu abbia questo atteggiamento ostile nei miei 
confronti, sinceramente, ma se tu leggessi piu' accuratamente sia i 
miei post (e forse, allora, capiresti cosa c'e' scritto), SIA le 
specifiche, eviteresti figure barbine.
Il contesto era il ciclo for..in o no?
Il come mai Opera restituisse le proprieta' secondo un criterio a prima 
vista casuale; tu affermavi che nonostante tutto era conforme perche' 
cosi' dicevano le specifiche ECMAScript alle quali Opera si atteneva.
Ebbene, come ti ho gia' scritto e postato, le specifiche alle quali il 
tuo caro Opera dovrebbe attenersi, dicono testualmente, in riferimento 
all'iterazione di un oggetto col ciclo for..in:
--------------------------------------------------------------------
The mechanics of enumerating the properties (step 5 in the first 
algorithm, step 6 in the second) is
implementation dependent. *The order of enumeration is defined by the 
object.*
--------------------------------------------------------------------
Potrei citarti, dicendo:
"vedi un po' tu, è una specie di arrampicata sugli specchi la tua ? 
Occhio però, più in alto ti spingi e più male ti fai quando perdi la 
presa....."
Ma credo che il problema sia un altro.


 dell'output che hai bisogno di fornire.
Affatto. Il for..in ti fornisce le proprieta' enumerabile contenute in 
un oggetto, nell'ordine fornito da quest'ultimo. Interroga un 
interfaccia. E questo, da specifiche ECMAScript.
Ma probabilmente gli sviluppatori di Opera hanno saltato questo 
passaggio come hai fatto tu, fermandosi alle prime pagine delle 
specifiche in cui viene dichiarata la struttura di un oggetto.


, 
it.i...@alpeia.artemis says...
E meno male che in parte ho qualcuno che capisce quel dico, stavo 
incominciando a dubitare di scrivere in modo intellegibile :)


 
Qui la figura barbina la stai facendo tu Zero, e il bello è che ti sei 
attaccato con i denti e con le unghie alle tue personalissime 
interpretazioni cercando di spacciarle per verità rivelata, molto 
divertente.  
Ti cito un manuale a caso, il David Flanagan, Javascript The Guide, Ed. 
O'Reilly, uno dei migliori testi di riferimento per i programmatori 
Javascript che tu sicuramente possiedi e che ti invito caldamente a 
ripassare:
-----------------------------------------------------------------
David Flanagan, Javascript The Guide, Ed. O'Reilly:
Pag 100:
"Il ciclo for-in non specifica l'ordine in cui le proprietà di un oggetto 
vengono assegnate alla variabile. Non vi è modo di saperlo in anticipo e 
il funzionamento può variare a seconda delle implementazioni o delle 
versioni di javascript."
Pag 132:
"Il ciclo for-in non enumera le proprietà in un ordine particolare e, pur 
enumerando tutte le proprietà definite dall'utente, non considera 
determinate proprietà predefinite e determinati metodi."
----------------------------------------------------------------------------
Te l'avevo detto Zero di non spingerti troppo in alto sugli specchi, stai 
per spiaccicarti al suolo.....
 
Ma per dimostrarti che non serbo rancore ho già predisposto un grosso 
materasso per limitare i danni....
bye
armaged
 

 materasso per limitare i danni....
Rancore? Per cosa? Questi tuoi post sono estremamente divertenti.
Anche se dimostrano quanta poca attenzione dai al contenuto dei 
messaggi a cui fai il reply, per la fretta di allestire scenette, 
teatrini, specchi e materassi.
Se ci sono fraintendimenti, sono poco chiaro a spiegare le cose (e sono 
il primo ad ammetterlo), o qualsiasi altra cosa in merito, si dovrebbe 
avere la buona educazione di chiarirsi, invece che mettersi a fare 
l'attore consumato. Ne guadagnano l'interlocutori e la discussione, e 
quindi l'NG.
Senza "rancore", se te ne serbi per queste cose.


 Rancore? Per cosa? Questi tuoi post sono estremamente divertenti.
Bè, il dubbio l'hai avuto tu non io, (Zero: ".....atteggiamento ostile nei 
miei confronti..."), anzi ti assicuro che vederti scalare a mani nude il 
grattacielo è molto divertente...
Quindi concludendo David Flanagan ha torto marcio ?
bye
armaged
 

 Quindi concludendo David Flanagan ha torto marcio ?
Leggi su (e magari rileggiti tutto il thread che male non ti farebbe).


Scusa se mi intrometto, ma ... state dicendo la stessa cosa, perché continui
a ripetere?
Zer0, in più di te, dice semplicemente che sarebbe bello che ogni browser
specifichi, da qualche parte, che tipo di ordinamento ha utilizzato (e mi
pare sensata come richiesta, almeno nella reference)


Il punto non è questo.  Siamo tutti d'accordo sul fatto che "sarebbe bello 
se.....".
La cosa che Zero cerca di far passare per "ratificata" è che lo 
sviluppatore dell'implementazione _debba_ specificare da qualche parte 
il criterio con cui le proprietà sono inserite nell'oggetto.
E questo non è scritto da nessuna parte anche se piacerebbe a tutti che 
lo fosse.
Anzi, le proprietà degli oggetti di default sono già dotate di un preciso 
criterio di ordinamento secondo ecmascript: la casualità (unordered).
Poi, se uno sviluppatore vuole aggiungere un criterio deterministico è 
sua facoltà, così come hanno fatto IE e Mozilla ma non è assolutamente 
richiesto dalle specifiche Ecmascript.
Per questo motivo Opera non è attaccabile su questo punto riguardo gli 
standard, nonostante le farneticazioni di Zero.
bye
armaged

 
Continui a svicolare Zero, Flanagan scrive chiaramente:
"Non vi è modo di saperlo in anticipo e
il funzionamento può variare a seconda delle implementazioni o delle
versioni di javascript."
L'implementatore non ti deve fornire nessun criterio per poter riuscire a 
capire come alloca le proprietà di un oggetto, lo fa come gli pare e 
piace senza dover rendere conto con delle specifiche di allocazione e tu 
devi assumere sempre un ordine casuale per definizione (unordered).
Ci sei arrivato adesso?
armaged

Beh, ma un criterio lo avranno usato ben, qualunque esso sia, no? E allora
perché non dirlo agli sviluppatori?
Io ho un sito di e-commerce; dico "ma mettere la lista dei desideri non è
mica obbligatorio"...se però tutti gli altri la mettono e io non la metto mi
dovrò anche aspettare che una fetta più o meno consistente di persone usino
gli altri siti perché ce l'hanno...o no?
Visto che è uno degli ultimi arrivati, visto che almeno in passato ha
peccato parecchio sullo standard ecma (anch'io avevo provato e cestinato
Opera qualche tempo fa, non ricordo la versione; vista la mia reazione,
simile a un gatto quando gli pesti la coda, con pelo dritto e gobba, poi non
mi sono mai più avvicinato), visto che ha di fronte almeno 1 colosso come
competitor, visto che ... etc etc, mi sembra anche a me stupido non fornire
queste informazioni, quanto meno come mossa "commerciale" per ingraziarsi
gli sviluppatori...
Certo che poi faccio un po' di test e probabilmente lo capisco da solo che
logica sta usando, però però...
Vabbé, torno al mio lavoro
Ciao a tutti
Cristiano

>> Beh, ma un criterio lo avranno usato ben, qualunque esso sia, no? E 
allora perché non dirlo agli sviluppatori?
L'insinuazione di Zero è che Opera viola gli standard ecmascript, 
insinuazione confutata ormai spero in modo chiaro e definitivo.
La tua questione è diversa e può essere interessante, ma allora ti 
chiedo:
dove sono i documenti di IE che specificano il criterio di allocazione 
delle proprietà di un oggetto dopo la sua creazione e manipolazione 
(aggiunta e delete di proprietà) per poter prevedere in modo 
deterministico come si comporterà la for-in dopo n manipolazioni 
dell'oggetto ?
L'esempio del delete già ti suggerisce che i criteri cambiano da IE a 
Mozilla.
Una risposta possibile alla tua domanda può essere: siccome 
l'allocazione delle proprietà di un oggetto avviene con criteri di 
ottimizzazione della memoria e delle performance che possono variare 
di volta in volta, per preservare questa ottimizzazione ufficialmente le 
proprietà di un oggetto non sono ordinate in modo tale che tu non possa 
assumere niente sull'output di una for-in.
In questo modo mi paro il culo io sviluppatore non dovendomi vincolare 
ad un preciso schema di ordinamento/gestione interna che potrei voler 
migliorare di release in release e ti fornisco un metodo generico che ti 
permette comunque di recuperare _tutte_ le proprietà in modo non 
ordinato, oltre che per nome specifico. 
La forzatura che vedo nel voler sapere a tutti costi come sono 
organizzate internamente le proprietà di un oggetto è simile al voler 
assimilare un oggetto ad un array, entità concettualmente molto diverse 
fra loro.
bye
armaged

 devi assumere sempre un ordine casuale per definizione (unordered).
Continuiamo a non capirci. L'oggetto e' una collezione di metodi e 
proprieta' non ordinate; MA il for..in te le restituisce in un DATO 
ordine, specificato dall'implementatore.
Questo e' chiaro, palese, lo dicono le specifiche ed e' cio' che dico 
dall'inizio del thread, ma che tu hai incominciato a prendere in 
considerazione solo ora.
Ora, a meno che non abbia letto male io, nelle specifiche 
dell'ecmascript non vi e' scritto affatto che il for..in restituisce in 
ordine casuale, come invece vorresti supporre tu. Ora, se cosi' non e', 
forniscimi il passaggio nella reference, visto che tra quelli letti 
fin'ora si afferma il contrario.
Ora, io posso anche assumere, dato che Opera enumera senza alcun 
criterio rintracciabile le proprieta' di un oggetto, un ordine 
"casuale", ma e' concettualmente errato. Un ordine ci deve essere, 
perche' cosi' definiscono le specifiche dell'ECMAScript.
Che sia anche un "ordine" casuale, a me sta bene (come ho detto GIORNI 
FA), ma visto che e' a cura dell'implementatore fornire a sua 
discrezione tale ordine all'engine, e visto che gli sviluppatori di 
Opera hanno deciso di non allinearsi con un ordine "logico" 
(alfabetico, o di apparizione proprieta'), allora invece di mettere 
solamente un link come rimando alle specifiche ecmascript, potrebbero 
inserire delle "appendici" in cui notificano "le scelte lasciate dallo 
standard ecmascript a discrezione degli sviluppatori".
.. E' tanto difficile, per te, da capire questo concetto?
Parrebbe di si, visto che tutto l'NG ci e' arrivato almeno da un paio 
di giorni, mentre tu stai qui a sfiancarmi a ripetere le stesse cose.


 standard, nonostante le farneticazioni di Zero.
Fortunatamente, ho avuto conferma che chi farnetica qui sei tu.


 La tua questione è diversa e può essere interessante
La "sua questione" e' uguale a quella che dico io, dato che LUI STESSO 
LO DICE, e sei l'unico che non l'ha capito.
Se vuoi continuare il thread, cerca di prendere un atteggiamento piu' 
civile e consono alla nettiquette. Altrimenti credo che tu possa fare 
un favore a tutti evitando di continuare con un comportamento alla 
stregua del flaming, se solo ti avessi dato davvero spago.


 standard,
Zero: Rileggiti meglio le specifiche dell'ECMAScript, e poi ne riparliamo.
--------------------------------------------------------------------------
Adesso prova a chiedere al newsgroup che tu tanto invochi per darti 
manforte e protezione che cosa si dovrebbe dedurre da una risposta del 
genere.
Non la pensi piů cosě?  Alla fine abbozzi e ti rimangi le tue insinuazioni ?
Mi sta benissimo, in questo caso allora siamo perfettamente allineati ma 
vorrei che tu lo dicessi chiaramente:
---------------------------------------------------------------------------
Opera viola o non viola le specifiche ecmascript ????????????
---------------------------------------------------------------------------
Un semplice SI od un NO sono graditi per amor di definitiva chiarezza.  
 
Tutto il resto viene di conseguenza a questa semplice risposta, se non la 
fornisci il loop č senza via uscita.
bye
armaged

 fornisci il loop è senza via uscita.
Il loop l'hai creato tu, sei l'unico che c'e' entrato.


 Fico, eh?
scusa, ma stavolta dissento :-)
Con gli hash array non e` garantito l'ordinamento in nessun linguaggio
che io conosca, che sia javascript o java o perl o altro.
Anzi: il ciclo stesso che lui ha usato (for su un hash) non ha proprio
senso di suo, IMHO.
Esempio veloce, cambiando linguaggio riscrivo il suo ciclo:
my %myObj = { x=>100, y=>200, z=>300 };
foreach $i (@myObj) { print "$i\n" };
Innanzi tutto nota che per ciclare devo passare da %n (hash array) alla
forma @n (vettore), in quanto i cicli si possono effettuare solo su un
vettore. Infine l'outut del codice sopra e`
x
100
y
200
z
300
Tutto, sia le chiavi che i valori, e senza alcuna garanzia di
ordinamento per le coppie chiave/valore (ma il valore seguira` sempre la
sua chiave).
La rappresentazione interna di un hash array non sono fatti tuoi, ma di
chi fornisce il supporto delle strutture dati al linguaggio. Quindi se
per il tokenizzatore Perl un Hash e` rappresentato internamente da un
vettore composto da un numero pari di elementi (chiave/valore), la
stessa cosa non e` affatto detto che debba accadere altrove.
Lui sta definendo un hash array, e dell'hash sa che potra` usarne le
proprieta` e l'associazione chiave/valore. Punto.
Non ci sono criteri di ordinamento da dover considerare garantiti, e
trovo sbagliato anche ciclare in quel modo e pensare di poter rispettare
qualche ordinamento.
-- 
begin  .signature-anti-MSOE
Oramai che i baci tuoi piu` non mi sazian
cerchero` un'altra donna dentro ai sogni di Tarzan
end

 proprieta` e l'associazione chiave/valore. Punto.
Vero, infatti anche secondo me basare il funzionamento di un codice 
sull'ordinamento dato dall'iterazione di un object tramite ciclo 
for..in non e' formalmente corretto; ma parecchio empirico.


 Io no :-)
Credo che la frase fosse essenzialmente riferita al fatto che "sarebbe 
bello se i browser avessero lo stesso comportamento", fossero allineati 
insomma. Frase al quale appunto mi accodo anche io :)


... A te che sembra?
Dimmelo tu con un semplice monosillabo se Opera ha violato o no le 
specifiche Ecmascript, il tuo giochetto dialettico è abbastanza palese 
ormai.
Su Zero, dopo tutto il tuo pseudo-ragionamento concettuale la tua 
risposta finale è SI' o NO ?
Immagino già l'enfasi retorica della tua risposta, anzi no, sicuramente 
assumerai un atteggiamento indignato arringando il newsgroup e la 
eviterai completamente pur di non rispondere nero su bianco senza 
scappatoie... 
bye
armaged

 dovrebbe essere ordinato a differenza degli altri linguaggi.
Pare che tecnicamente Opera abbia usato proprio hash array per 
questioni di efficienza nella gastione delle proprietà.
Fare assunzioni extra-specifica è pericoloso ed il rischio di chi si fida 
dell'ordinamento di IE o Gecko consiste nel vedersi una release futura in 
cui l'ordinamento cambia senza violare minimamente le specifiche 
ecma-262.
E' quindi un'assunzione di rischio consapevole da parte dello scripter 
sfruttare l'ordinamento iniziale di IE o Mozilla per avere un output della 
for-in già ordinato, e visto che lo scripter ha già deciso di correre il 
rischio (liberissimo del resto anche se non concettualmente corretto...)
"sarebbe carino"  che anche Opera listasse le proprietà di un oggetto 
custom con la for-in secondo l'ordine di creazione delle sue proprietà.
Giusto per amore di uniformità comportamentale, niente più....
Il "sarebbe bello se" si riferisce esclusivamente a questo dettaglio per 
quanto mi riguarda, comodo se non altro in fase di debug per avere il 
dettaglio di un oggetto con una veloce for-in vedendolo in output 
esattamente come lo hai creato inizialmente.
bye
armaged

 ormai.
Oh, al diavolo :)
Sei uno spasso, ma io mi sono stancato. A te non interessa la reciproca 
conmprensione, o la comunicazione. Affatto.
Un tempo avrei giocato al tuo stesso gioco, ma ho scoperto quanto sia 
sterile anni fa.
Tra l'altro visto che nonostante i miei appelli continui a ignorare la 
netiquette, e che questo thread ha detto tutto quel che aveva da dire, 
se vuoi puoi continuare by mail.
Se invece sei quello che vuole avere l'ultima parola (conoscendoti 
ormai, e' una domanda retorica), se credi scrivi pure sull'NG, ti 
prometto che evitero' di replicare.


 degli oggetti? No, e allora mastica degli unredictable results.
Corretto.
Ma per me il punto era essenzialmente "cavolo, cosa c'e' che non e' 
chiaro in quel che dico?"; mentre lui l'aveva preso come un attacco 
personale a Opera (diamine, gli sviluppatori di un proprio programma 
reagiscono meglio!), mentre non era neanche un "attacco".
Era diventato tutto un sofismo. Era andato perso il "goal", 
trasformando un thread in qualcosa di del tutto inutile per l'NG.


 prometto che evitero' di replicare.
-----------------------------------------------------------------------------------
Immagino già l'enfasi retorica della tua risposta, anzi no, sicuramente
assumerai un atteggiamento indignato arringando il newsgroup e la
eviterai completamente pur di non rispondere nero su bianco senza
scappatoie...
-----------------------------------------------------------------------------------
Come volevasi dimostrare....l'orgoglio è una brutta bestia......
Facciamo come se la risposta secca e chiara me l'avessi data. 
bye
armaged

 inizializzazione (pazzesco! ^^;;)
.. Alla fine per cosa hai optato?
Se le performance non subiscono vistosi cali, anche se forse non e' "la 
cosa piu' immediata", io ti consiglierei un refactoring del codice.
In questo modo anche per problemi futuri, non andrai a toccare 
l'interfaccia.


 Ordini le chiavi in un array, passi all'hash per ripescarne i valori.
la verita' e' che ho fatto sempre affidamento in un comportamento che
vedo essere fuori standard e che per contro penso dovrebbe esserlo
quanto prima
-- 
artemis.alpeia
http://spazioinwind.libero.it/artemis

 quanto prima
In realta' non e' "fuori standard". La verita' e' che non c'e' un vero 
e proprio standard, essendo l'ordine a discrezione dello sviluppatore 
dello script engine; e quindi ognuno e' libero di implementare cio' che 
gli torna piu' o meno comodo, o che reputa piu' o meno giusto.
