io non introduco niente ... la libreria lavora in background,
l'introduzione del formato serialize di PHP è lo stesso identico
concetto di JSON, esistono versioni di serialize / unserialize per quasi
lo stesso numero di linguaggi eh ... non è una novità e permetterebbe a
tale libreria di lavorare su più linguggi server invece che su uno solo,
tutto qua
Perchè non usi semplicemente XML-RPC allora se ti interessa il cross language?
e hai detto niente ... visto che lo stato ti permette di ricostruire,
sul client se presente, o sul server, se presente, un'istanza aggiornata
dell'oggetto.
Beh se ti interessa passera dati rilancio xmlrpc che più standard non
si può :-)
Complicato capire cosa vuoi fare :P
> In python pero` gli oggetti non sono altro che dizionari, allora
> perche` complicarsi la vita per scrivere tutto sto popo` di roba
> quando basta saper trasmettere dizionari?
perchè i dizionari non sono istanze di oggetti ma appunto dizionari ?
A me pare che in Python un dizionario sia un oggetto, ignoro cosa sia
in PHP ma ti posso giurare che in Python un dizionario *è* un oggetto.
Ha un tipo (dict), ha una sintassi literal, ha dei metodi, uno stato.
E' un oggetto.
perchè non puoi usare o inviare classi client / server e gestirne lo stato ?
A te interessa solamente spostare informazioni dal pc X al pc Y. Passi
"dati", poi cosa ne fai è affar tuo
significa che ogni client si gestisce la sua istanza delel sue classi,
E questo mi sembra la cosa più normale del mondo dato che gli oggetti
su un client non sono quelli sull'altro.
significa un approccio completamente OO anche sul client, usando anche
classi e non solo {}
Mi sa che non hai approfondito molto Python prima di imbarcarti in
questo progetto perchè è scritto pure nel tutorial che i dizionari
sono oggetti.
prima dici del po po di roba, poi mi parli dell'inutilità di inviare
stati di oggetti, quidi implementeresti un metodo dedicato che a seconda
della classe assegna eventualmente quello o quell'altro parametro
all'istanza dell'oggetto ??? ... io invio istanze, non devo fare altro,
inutile eh ? per me non lo è mai stato, sarò io che ho i paraocchi bucati ?
Ma quanta roba devi passare da un server a un client, si può sapere?
Sembra che tu stia gestendo una foresta di dati supercomplessi di
megabyte di stato.
si, pazienza, tanto dato i tuoi discorsi lavori solo con dizionari,
chissà quali "stratagemmi" per ricreare i metodi, stratagemmi inutili
quando puoi inviare già un oggetto con quel metodo, poi l'invio di più
oggetti non ne parliamo
Sei al corrente vero che non c'è praticamente nessuna differenza tra
passare una oggetto senza metodi (quindi solo lo stato) e il
dizionario del suo stato?
Stessa classe, stesso stato, metodi uguali con o senza lo stesso nome
con possibilità di usare operazionidifferenti a seconda
dell'utilizzatore, client o server.
Mi sfugge perchè il server dovrebbe avere le stesse classi che ci sono
su N client. In tutta questa discussione il vero problema secondo me è
che non si è capito cosa stai realmente cercando di fare, a parte
tutti i termin di passare oggetti in giro. Cosa cerchi di ottenere in
soldoni?
> Perche` e` assurdo che la stringa di byte (ovvero una stringa di testo
> codificata in utf-8) debba ritornare i caratteri e non la lunghezza?
e chi l'ha mai detto ? Io ho solo detto che è una pecurialità di php e
php "soltanto" ed è la causa del rallentamento in serializzazione /
unserializzazione con JS o gli altri linguaggi quando devi interagire
con il formato serializzato di php abilitando il supporto UTF-8
Semplicemente perchè PHP ha un pessimo supporto per ciò che non è ASCII
Il nesso è la portabilità della lib, ma a quanto pare avete già
l'onnipotenza in materia e quindi una lib che con una sola scrittura del
client si porta anche in Python, oltre che PHP e C# non vi interessa.
Non è che non interessa. E' che, almeno io, non vedo il problema che
stai cercando di risolvere. Tutto qui. Non mi sembra di aver detto di
essere onnipotente o cose del genere. Ho tenuto un tono
tranquillissimo proprio perchè mi sembra che tu stia inventando
l'acqua calda e ci sono passato anche io in passato.
Strano, nell' era del "web js & ajax" avere librerie da non dover
riscrivere anche per il client dovrebbe muovere l'interesse collettivo,
proverò con gli altri linguaggi, abbandono il porting per Python ? Visto
che tutto è inutule e che non si capisce niente dell'intento o le
potenzialità della libreria devo proprio aver cannato linguaggio ...
Beh se tu stai reimplementando JSON non capisco perchè dovrebbe
esserci un interesse collettivo per una cosa che è già una RFC tra le
altre cose. Magari proponi a loro di migliorare le cose che non ti
piacciono, no?
Che ne dici di evitare di valutare ancora prima di conoscere ?
Sono tutt'orecchi, cosi finalmente capisco cosa stai realmente
cercando di implementare. Perchè questi ultimi post mi sono sembrati
un pò confusi
si, non è compatibile con le stringhe UTF-8 , invia liste, tuple e dict
e ritorna sempre e solo dict, non invia ne riceve Classi.
Cavoli, i dict SONO classi, almeno in Python. Ma anche in JS
Tra l'altro il tizio della serialize "che esiste già" mi ha già fatto i
complimenti ed ha detto che quanto prima avrebbe aggiornato il suo sito
per segnalare la variante.
Non metto in dubbio che la cosa tu hai implementato abbia un senso e
una ragione di esistere ma mi pare la risoluzione di un problema che
ha PHP, o mi sbaglio?
--
Lawrence
http://www.oluyede.org/blog
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
