Newsgroup: it.comp.os.dibattiti
Titolo: Esistono shell Object Oriented

Vorrei sapere se esistono shell Testuali Object Oriented, cioè shell che
implementano al loro interno il paradigma dell'object Oriented
Un esempio puo essere:
File.mp3 play
play è un messaggio inviato all'oggetto file  mp3 che gli dice suona....
oppure:
file.txt edit
abbia al suo interno un linguaggio di scripting ad oggetti, cioè una
sintassi smalltalk like, e via dicendo...
Sto cercando documentazione in giro su anche la teoria alla base di queste
shell (se esiste) e vederne il codice per studio.
-- 
E-Mail: 
risi...@libero.it
Sito Web: 
risitano.altervista.org
Gruppo: 
it.groups.yahoo.com/group/decomunistizziamo-internet/
"Noi vogliamo glorificare la guerra - sola igiene del mondo
il militarismo, il patriottismo, il gesto distruttore del liberatori, 
le belle idee per cui si muore."   F.T. Marinetti

implementano al loro interno il paradigma dell'object Oriented
mah, la prossima CLI di microsft dovrebbe essere così.. 
sennò puoi sempre usare l'interprete python in maniera interattiva o 
Interactive ruby (IRB) o gst..

Nicolò Risitano scrive :

Non è propio quello che intendo io....
Io dico una shell in cui l'operazione che bisogna fare sia fatta sensa
sapere il comando per farla, in modo intuitivo, io non voglio sapere che
per suonare un file mp3 ci vuole xmms winamp wmp e via dicendo, io voglio
solo che suoni, poi il resto non sono cose che mi riguardano...
quelli che tu dici sono un altra cosa, non sono shell, ma intrerpreti, che è
cosa ben diversa...
Ps gst: non lo consiglierei nemmeno al mio peggior nemico.


 solo che suoni, poi il resto non sono cose che mi riguardano...
Coma fa a sapere che vuoi suonarlo o, per esempio, copiarlo
(o comprimerlo ulteriormente), senza usare comandi?
bye,
-- 
   Piergiorgio Sartor

Nicolò Risitano scrive :

lo detto, tramite messaggi mandati agli oggetti, tipo
come ho fatto prima...
- file.mp3 play
gli dice che vuoi suonarlo
poi quale sia l'applicazione da utilizzare , come avviarla e via dicendo ci
pensa la shell
- file1 copy dest
dice di copiare il file1 in dest
un po come nella sintassi smalltalk..
questo tipo di tecnica aumenterebbe notevolmente la semplicità del sistema,
fino ad ora solo nelle gui a quanto ne so è stata implementata questa 
idea...
Per me sarebbe molto più intuitiva come shell... e forse anche più potente,
visto che per esempio i file avi potrebbero avere delle operazione che i
file di testo non hanno, esempio:
- file.avi comprimi: 2000
dice al file avi di comprimersi con bitrate 2000 e tutto sensa minimamente
sapere quale applicazione andare ad usare per farlo... questo sarà il
sistema che sceglierà in base a delle preferenze impostate una volta per
tutto (poi modificabili).
- file.txt print
lo stampa, che senso ha la stampa su un file avi???
Le Cartelle potrebbero ad esempio avere degli attributi particolari a
seconda del file che contengono, in modo che a stretto contatto col sistema
possano ottimizzare l'accesso alla stessa in caso di file particolari che
abbiano bisogno di più attenzione in fase di lettura... (idea ma non penso
realizzabile)...
Sono stato chiaro...
Ciao
Nicolò Risitano


 gli dice che vuoi suonarlo
E che differenza c'e` tra:
file.mp3 play
e
play file.mp3
???
Dove "play" e` un link al tuo player preferito,
per esempio...
Per "copy" si potrebbe discutere.
Nel senso che:
src -> dest
con "->" cambiato in "copy", potrebbe avere un senso.
Anche se non mi pare tanto lontano da:
copy src dest
bye,
-- 
   Piergiorgio Sartor

Nicolò Risitano scrive :
La differenza è più concettuale che di fatto, la shell classica io direi che
è orientata ai comandi, la shell (che io chiamo ad ogetti visto che tutto
può essere visto come un oggetto) è orientato alle idee, cioè l'idea di
copiare, l'idea di suonare un file, ecc ecc...
Il fatto è che play nel 1° caso non è un programma ma un messaggio, che
viene inviato all'ogetto File.mp3 tu non devi sapere se una certa
applicazione per fare tale cosa c'è o non c'è ha e come si chiama, a te
interessa sapere che vuoi copiare/suonare/editare/stampare/eccecc un file,
poi ci pensa il sistema a fartelo fare.....
 

-- 


 poi ci pensa il sistema a fartelo fare.....
Questo e` quello che succede gia` adesso.
Se tu dai: "play file", cosa ne sai che "play"
e un comando esterno od interno alla shell?
Cosa ne sai cosa fa la shell per eseguire cio`
che tu gli chiedi?
Tu devi comunque sapere se puoi eseguire l'operazione
che vuoi e devi sapere che comando dare.
Devi sapere che "play" suona e non "sound" (per dire).
Quindi non capisco che problemi risolveresti, in ogni
caso devi sapere come fare.
bye,
-- 
   Piergiorgio Sartor

 <icq:241572242>
The optimist thinks this is the best of all possible worlds.
The pessimist fears it is true. [J. Robert Oppenheimer]

 dispendiosa di risorse? E non devi sapere il programma associato.
Si...
Ma mi da spesso mal di testa.
Soprattutto quando devi rinominare un file...
...cambiando il suffisso...
bye,
-- 
   Piergiorgio Sartor

 poi ci pensa il sistema a fartelo fare.....
 >
Non so se ho capito cosa vuoi fare, proviamo:
Vuoi dare comandi al computer con la sintassi che usi parlando?
Cose tipo "riproduci 5° sinfonia di Behetoven" o "visualizza Divina 
Commedia"?
Và, diciamo allora che vogliamo solo accedere al contenuto di un file (e 
scusa la semplificazione, ma è quello che fai quando vuoi ascoltare un 
mp3, leggere un testo o vedere un avi), allora la semplificazione 
semantica massima che possiamo applicare sarebbe dire alla shell:
$accedi miofile.ext
oppure
$lancia miofile.ext
oppure ancora
 >start miofile.ext
E, grazie alla parola magica "start", per esempio, la shell cercherebbe 
il programma giusto, lo lancerebbe, e accederebbe al file, mostrandotelo 
o riproducendotelo... giusto?
Tutto questo senza che tu ti curi che programma usare, che sintassi 
specifica applicare etc.
Allora guarda, apri Windows, prendi un bel 
command.com
 o cmd.exe, prova 
a digitare
 >start miofile.ext
E poi raccontami che succede, e se ti sembra troppo complicato!
Ovviamente questa non è una specialità di Windows, anzi, secondo me 
riesce MOOOOLTO meglio con Linux, usando un po' di scipting di bash e 
l'utilità file, ma te lo devi creare tu.
Ma poi perchè non dovrei curarmi di che programma viene usato per 
accedere a un file?
Io oggi voglio usare un programma perchè ha certe feature, domani un 
altro perchè ha feature diverse che ora mi servono...
La classica situazione di usare cat o less per vedere un file di testo: 
se so che è breve uso cat che faccio prima, ma se è lungo o voglio fare 
ricerch nel testo uso less e sono soddisfatto.
Non sempre le idee coomplicate pagano.
Ciao
Gerry

 caso devi sapere come fare.
Beh magari aggiungendo un sistema che prova a capire la lingua dell'utente 
(in base a un dizionario)
qualcosa tipo
suonami smoke on the water
e questo fa partire XMMS con in playlist la celeberrima canzone dei Deep 
Purple :) (magari dopo averla cercata su un peer-2-peer...ops, no RIAA! 
scherzavo! non volevo!! dai, scusate!!)
-- 
il Vide - ICQ# 5301833
IAMM - it.arti.musica.metal 
http://www.heavy-metal.it
"There is no stronger drug than reality"

 ...cambiando il suffisso...
Per questo io non prediligo il suffisso ma i magic numbers (il comando 
``file'')... almeno si sa cosa c'è dentro...


 suonami smoke on the water
S: Computer! Computer? Computer!!!!
B: Forse questo...
S: Computer? Hello computer...!
B: Provi la tastiera.
S: Tastiera? Bahhhh....
bye,
-- 
   Piergiorgio Sartor

 ``file'')... almeno si sa cosa c'è dentro...
Infatti, sembra anche a me la soluzione piu` accettabile...
bye,
-- 
   Piergiorgio Sartor

 copiare, l'idea di suonare un file, ecc ecc...
Nella sostanza nella tua shell ogni tipo di file dovrebbe aver associata una
classe che oltre ad ereditare da una base (che da le funzioni standard tipo
la copy) implementa le funzioni sue (la play). L'unico problema è
distinguere quando vuoi avere N classi registrate per ogni tipo file, per
cui poter fare la Play con WinAmp o con iTunes.
Secondo me è intuitiva solo per i programmatori, ma non è che sia una brutta
idea...
Saluti
Massimo

> Non sempre le idee coomplicate pagano.
Non è che sia un'idea "complicata" (forse qualcuno ha definito "complicata"
anche la prima interfaccia windows fatta a Palo Alto), è solo un'idea.
A me non dispiace, ribadisco che è intuitiva se sei un programmatore e
controintuitiva per tutti gli altri, ma avere un linguaggio di script con
cui fare
foreach(File f in Folder.Files)
    File.Play
next
ed in automatico ti suona o ti fa vedere tutti i file in una directory senza
pensare a che file sono non è che sia una cosa così orripilante. So che si
fa benissimo con qualunque altro linguaggio di script, ma dato che astraiamo
dappertutto perchè non farlo anche a livello di FS???
Saluti
Massimo

 dispendiosa di risorse? E non devi sapere il programma associato.
L'associazione su suffisso è una delle mostruosità peggio concepite e
peggio realizzate della storia dell'informatica.
Per sapere *cosa* è un file esiste da tempo la soluzione, e si chiama
MIME[1]. Dal MIME-type ad una serie di azioni predefinite il passo è
decisamente breve.
+++
[1] Non che non sia un accrocchio, alle volte.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 S: Tastiera? Bahhhh....
Piombo trasparente???


 decisamente breve.
E' una associazione, non è quello che volevi tu però. Ritorno ai 
resource fork del caro vecchio mac?


 Piombo trasparente???
Argh!
Alluminio, era alluminio trasparente!
bye,
-- 
   Piergiorgio Sartor

 Alluminio, era alluminio trasparente!
Porc!! Memoria fallace!!


 resource fork del caro vecchio mac?
Il metodo che mi aveva esaltato di piu' erano i datatypes dell'Amiga. Si 
scriveva un prg che supportasse i datatypes e quando c'era un nuovo tipo 
di file bastava aggiungere il datatype adeguato, e tutti i programmi 
potevano leggere quel file...

il Thu, 04 Dec 2003 08:12:44 GMT, Nicolò Risitano
<risi...@liberoNOSPAM.it> ha scritto::
beh.. se parti da gst e fai si che la prima parola venga
automaticamente caricata come oggetto di tipo QualcheFile
 poi funziona :)
Certo devi implementare tutti i VariFile..

next
non c'è un f di troppo? (o un File di troppo e un f in meno :)

Nicolò Risitano scrive :

Stessa idea che avevo avuto pure i, un file system in cui non c'è
distinzione fisica tra file e cartelle, tutto è un oggetto con particolari
caratteristiche, quindi ad esempio si potrebbe realizzare un cartella che
contiene solo file avi in cui il sistema saprebbe che per accedere ai file
in quella cartella deve usare un sistema particolare di accesso al disco in
cui tutto viene ottimizzato....
L'idea comunque è molto simile a quello che hai detto tu, non è più un
comando che dice come eseguire un file, ma è il file stesso...
Quindi il tuo esempio è pertinente... 


Nicolò Risitano scrive :

Si tu sei uno che ci è arrivato molto vicino....
Basterebbe passare un parametro a play
file.mp3:play iTunes
Potrebbe suonare l'mp3 usando iTunes invece di quello predefinito, 


 
dimmi una cosa, come apri tu i file mp3 da shell es bash
mpg123 filemp3
link simbolico a mpg123 chiamato play
play filemp3
be, questo sempre un comando è, non è un operazione attribuita al file, io
potrei avere un play per i file avi, gli mp3, i wav, che ne so, una certa
applicazione segnata come gioco da un particolare tag me lo avvia, oppure
nella massima delle assurdità, voglio che un file di testo risponda al
comando play facendomi vedere una riga per volta...., io avrei un singolo
modo per interfacciarmi a più operazioni, sensa sapere minimamente come il
sistema le fa... all'utente se per arire un file di testo ci vuole ms word
o OpenOffice Writer non gliene frega niente , lui vuole editare il file,
del programma da usare ci pensa il sistema, come avviarlo, i parametri e
tutte le altre cose che all'utente non importano, e sacrosanto che
all'utente non venfgano fatte pesare.


 dispendiosa di risorse? E non devi sapere il programma associato.
L'associazione col suffisso è una cafonata abbissale, chi l'ha inventata non
sapeva propio come rimbambire l'utente di un pc....
il modo migliore sono i magic number dei file, modo veloce e semplice per
riconoscere un file senza doversi preoccupare del nome...


Nicolò Risitano scrive :

Come ho già detto gst non lo consiglierei nemmeno al mio peggior nemico.
Però, come prova di base potrebbe forse funzionare... ma non è quello che
avevo in mente....


 all'utente non venfgano fatte pesare.
Ma le operazioni da shell, le devi conoscere comunque,
le devi nominare, devi assegnare loro un identificativo.
Quindi non vi e` piu` nessuna differenza tra "comando"
ed "operazione", dato che la relazione resta univoca.
La differenza con la GUI e` che l'operazione, in generale,
e` sempre la stessa, cioe` click o doppio click.
Nel caso della shell, la natura dell'interfaccia ti
costringe ad essere piu` specifico, quindi l'eventuale
oggettivizzazione, come la descrivi tu, non porta reali
benefici, dato che per ogni "operazione" ti serve un
"comando" diverso, non puoi usare lo stesso.
O meglio, potresti anche, ma in maniera molto limitata.
Tu dici che "file.mp3 play" e "file.txt play" dovrebbero
fare cose diverse su file diversi, ma dato che esistono
parecchi modi per visualizzare un file di testo (per riga,
per pagina, continuo), questa "possibile" coincidenza di
operazione e` piu` unica che rara.
Alla fine ti ritroveresti con operazioni diverse per file
uguali, in quantita` uguale agli attuali comandi o forse piu`.
bye,
-- 
piergiorgio

 potevano leggere quel file...
Come succede su GNOME (da un po' di tempo, anche se prima era molto
primitiva la cosa) usando il MIME type.


 resource fork del caro vecchio mac?
Mai avuto il piacere di possedere un vecchio mac (beh, fino a quello che
ho retrorecuperato quest'estate). :-)


 next
Ok, ma non funzionerebbe benissimo anche "play(file)" ?
Oppure "play file" ?
Comunque penso sia una cosa fattibilissima quella che volete fare voi. 
E' come fare il filemanager di una gui (come explorer di windows) che 
per ogni tipo di file permette di fare diverse operazioni.
L'unica differenza e' che qui i comandi sono testuali.
Ovviamente l'explorer di windows distingue i file dall'estensione, ma 
non dev'essere per forza cosi: potete anche fare una shell che usa il MIME.
Solo una domanda mi sorge: il fatto di avere una shell di questo tipo, 
che vantaggi comporta?
Secondo me non molti, difatti, anche se realizzabile, non l'ha ancora 
realizzata nessuno.
Cio' non toglie che dal punto di vista concettuale sia piu' interessante...

 il modo migliore sono i magic number dei file,
palle. Prima che ti salga il sangue alla tastiera: posso dimostrarlo
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.5. C, C++ and ASM developers
                               and beta testers are welcome!

 che vantaggi comporta?
A parte l'eleganza degli script? Poco o niente. Ma pensarci comunque mi
distrae e ciò è bene.
Saluti
Massimo

 input.
Tutto è una associazione. Ma il magic number va a vedere cosa c'è dentro 
al file lasciando perdere il fallace suffisso.
Molto più sicuro.


 palle. Prima che ti salga il sangue alla tastiera: posso dimostrarlo
Fallo.


 non c'è un f di troppo? (o un File di troppo e un f in meno :)
f.Play


 Il metodo che mi aveva esaltato di piu' erano i datatypes dell'Amiga. 
Perché, adesso non ti "esalta" più? :-)
Cmq, anche BeOS ha una cosa simile.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                 |     Bertrand Russell
falemagn (AT) aros (DOT) org    |     The Philosophy of Logical Atomism

 una operazione, importa cosa fa.
Quello che lui sta cercando di dirti, e che con il tuo metodo non è 
possibile implementare [*] è che "play" deve poter "playare" qualsiasi 
cosa, sia che sia un file audio, sia che sia un file video, sia che sia 
un file di testo (qualunque cosa voglia dire "play" associata ad un file 
di testo). Poi, ovviamente, se l'operazione non ha significato per 
l'oggetto in esame, il comando semplicemente fallisce ritornando un 
errore appropriato.
Fabio Alemagna
[*] Il link simbolico da te proposto ovviamente non funziona... quello
     che potrebbe funzionare sarebbe uno script che si prendesse la briga
     di analizzare il file e capire quale comando reale invocare, ma va
     se che questa soluzione è pessima, confrontata a quella in cui è il
     sistema stesso che capisce cosa fare con quel file.


     sistema stesso che capisce cosa fare con quel file.
Sarebbe esattamente la stessa cosa, dato che lo script
farebbe parte del sistema.
Il problema e` che, in shell, dato un file, si possono
fare diverse cose (ed il sistema non puo` sapere cosa
l'utente voglia realmente fare).
Per esempio nessuno vieta (e funziona) di fare un grep
su di un mp3. Oppure split, oppure tar, etc.
Per ogni azione possibile, serve un "nome", quindi l'utente
deve comunque ricordarsi il "nome", in funzione di cosa
vuole fare.
In questo senso la GUI e` diversa, sicuramente piu`
object oriented e, di conseguenza, piu` facile, ma
anche piu` limitata.
Tra l'altro, se facessi "play" di uno zip, cosa dovrei
aspettarmi? Un unzip oppure il play del contenuto?
Oppure la lista del contenuto?
Una GUI aprirebbe lo zip dandomi la possibilita` di fare
il play, ma questo sarebbe un po' difficile in una shell
che non fosse semi-grafica e quindi si torna alla GUI.
bye,
-- 
   Piergiorgio Sartor

 permette tutti i concetti proprio della Object Orientation.
Non è detto che "play file" sia meno OO di "File.play", è tutta una 
questione di sintassi, non di semantica, la quale è identica in entrambi 
i casi.
Detto questo, è da tempo che sto lavorando "in background" a qualcosa 
che fa tutto quello che Nicolò ha ipotizzato ed anche molto di più. In 
"background" perché come sempre il tempo è tiranno e ci sono tante altre 
cose da fare. Il sistema si chiama "CABOOM", che sta per "Component 
Architecture Based upon an Object Oriented Model", che in pratica è un 
sistema a componenti principalmente sviluppato per AROS 
(
http://www.aros.org/
), ma scritto in modo che sia portabile.
Le specifiche del sistema prevedono solo 3 cose: un ABI, che definisce 
il modo in cui le classi sono rappresentate in memoria; un'API molto 
basilare, che definisce le semantiche relative alle poche classi base 
del sistema; ed infine la CLI, che è intesa essere il più possibile 
retrocompatibile con la CLI attuale di AROS/AmigaOS mentre al contempo 
introduce nuove semantiche che si vanno ad inserire in maniera indolore 
all'interno di quelle già esistenti.
Non scendo nei dettagli del sistema, ma do qualche esempio del suo 
utilizzo;
suonare un file audio:
     play audio.wav
oppure
     audio.wav\play
visualizzare un video:
     play video.mov
oppure
     video.mov\play
convertire un file wav in un mp3 (la sintassi qui è ancora da definire 
al meglio):
     copy MP3:audio.wav audio.mp3
listare il contenuto di un archivio:
     dir archive.tar
oppure
     archive.tar\dir
eseguire il metodo Quit dell'applicazione Player:
     Quit Applications:Player
oppure
     Applications:Player\Quit
E' anche possibile creare nuovi oggetti al volo, la programmazione 
strutturata non fa uso di keyword, perché le keyword sono in realtà dei 
normali comandi (in puro stile AmigaOS), e così via.
Il concetto fondamentale è che ogni oggetto appartiene ad una 
determinata classe che espone una o più determinate interfaccie. La CLI 
  svolge il suo lavoro sfruttando la reflection, quindi non ha bisogno 
di sapere quali metodi un particolare oggetto ha, sarà l'oggetto stesso 
ad esportli. Questo fa anche sì che la CLI stessa ammonti ad una piccola 
manciata di kilobytes di codice del tutto generico.
Uno dei concetti fondamentali di CABOOM, inoltre, è che ogni oggetto è 
in realtà un contenitore, un "namespace". Anzi, è DUE namespace insieme, 
uno accessibile tramite il backlash '\' e l'altro accssibile tramite lo 
slash normale '/'. Quello accessibile tramite il backslash, è il 
namespace contenente i nomi dei metodi e degli attributi relativi a 
quell'oggetto, mentre il namespace accessibile tramite lo slash normale 
è il namespace degli altri oggetti che, eventualmente, l'oggetto contiene.
Ad esempio, potrei benissimo estrarre i frame da 1 a 100 di un filmato 
in questo modo (di nuovo, la sintassi è da definite, ma le funzionalità 
che tale sintassi espone sono indipendenti dalla sintassi stessa):
     For n in sequence:1-100
     {
         copy video.avi/Frames/$n frame_$n


 che non fosse semi-grafica e quindi si torna alla GUI.
Per nulla, con CABOOM (vedi l'altro mio post) io semplicemente faccio 
questo:
     play archive.zip/file.wav


 
butto lì un'idea:
file.mp3[TAB]
->Play
->Edit
->Copy
cioè quando il filename è completo, la tab-completion mostra l'elenco
dei messaggi (o, se vogliamo, operazioni) che si possono mandare
all'oggetto indicato dal nome del file.
Marcello
-- 
"Linux is built to be used, Windows is built to be sold" (seen in COLAdv)
Visit 
http://www.geocities.com/match_97
marcello (dot) romani (at) libero (dot) it

     play archive.zip/file.wav
Anche se hai molti "wav"? Come decidi quale suonare?
E se l'archivio contiene anche jpeg? Cosa succede?
Tra l'altro ancora peggio con l'operazione di transcodifica.
Se implementi un "copy wav mp3" dovresti essere in grado
di controllare tutti parametri dell'encoder (ed anche di
scegliere l'encoder), la complessita` diventa cosi` elevata
che il paradigma OO viene dominato dal metodo stesso.
bye,
-- 
   Piergiorgio Sartor

 all'oggetto indicato dal nome del file.
Hai fatto una GUI... :-)
bye,
-- 
   Piergiorgio Sartor

 Cmq, anche BeOS ha una cosa simile.
Beh, c'e' da ricordare che il CEO di Be era Gassé (se ricordo bene), un 
grande fan dell'amiga...

+++++++++[<++++++++>-]<----.>+++++[<+>-]<.>++++[<-->-]<.>+++++[<++++>-]<.

 Molto piů sicuro.
che bello, cosě i file di openoffice mi verranno aperti solo piů dallo
zip, i file del windows installer con il word e quando con un filemanager
si apre una directory con 2000 file dovranno essere aperti e controllati
2000 file... 


 che il paradigma OO viene dominato dal metodo stesso.
Non vedo perché. basta decidere bene che tipo di sintassi adottare in 
questi casi. Per quanto riguarda la scelta dell'encoder, ad esempio, 
basta usare il nome dell'interfaccia propria della classe che lo 
rappresenta, anziché dell'interfaccia che implementa (ogni classe 
automaticamente definisce un'interfaccia, con lo stesso nome della 
classe, ed al contempo ogni classe implementa una o più interfacce.)


 2000 file... 
Guarda che l'associazione con il suffisso è più una cagata che altro. Il 
magic ti da il contenuto del file. I file di openoffice sono si, zip. Il 
file 
win.com
 non è un file COM ma un EXE. Ma lasciamo perdere queste 
``sottigliezze''.
Hai mai usato konqueror? Se lasci il mouse sopra l'iconcina ti dice che 
file è, mentre con intèrnetteccsplòrer no.
Un suffisso è fallace. Punto.


 Un suffisso è fallace. Punto.
E la motivazione di questo è, invero, molto semplice: il nome di un file 
non è una caratteristica intrinseca del file stesso, in quanto cose 
uguali possono avere nomi diversi e cose diverse possono avere lo stesso 
nome, senza che questo intacchi minimamente l'essenza di queste cose, 
che sono e rimangono quello che erano prima che qualcono gli desse un nome.
Si potrebbe controbattere che così come il suffisso si può camhiare, per 
sbaglio o volontariamente, la stessa cosa può succedere al cosiddetto 
"magic number", (che spesso e volentieri numero non è, ma lasciamo 
stare), ma il punto è che il cosiddetto "magic number" fa parte delle 
specifiche di quel tipo di dato, ovvero se viene cambiato allora a 
tuttio gli effetti quel dato non è più ciò che era prima che fosse 
cambiato, mentre il nome del file non fa parte, spesso e volentieri, 
delle specifiche del tipo di dato di quel file, per cui cambiare nome 
non comporta alcun cambiamento del tipo di file.
Mi spiego con un esempio: gli eseguibili in formato ELF devono sempre, 
per specifica, cominciare con 4 byte che sono '\x7F', 'E', 'L', 'F'. Se 
per qualche motivo tale intestazione viene cambiata, ad esempio in 'E', 
'L','F','\x7F', allora tale file NON è più un file ELF.
Se però il mio sistema operativo decidesse di capire se un file è di tip 
ELF o no a seconda del fatto che ha estensione .elf oppure no, va da se 
che è un sistema fallace, perché NON si basa su nessuna delle specifiche 
del tipo di dato ELF per decidere se è di tipo ELF oppure no.
Quindi, non è il fatto in sé di usare il suffisso del nome per 
determinare il tipo di file che è errato, quello che è errato è il fatto 
che tale sistema è usato quando NON c'è nessuna garanzia che funzioni, e 
ciò accade nel 99% dei casi.


 classe, ed al contempo ogni classe implementa una o più interfacce.)
Tutto chiaro, ma che vantaggio avrei tra questo e
chiamare "transcode" o "mencoder" o "ffmpeg" da linea
di comando con i nomi dei file?
Voglio dire, se implemento "copy" con possibilita` di
specifica dell'encoder, cosa mi cambia a chiamare
direttamente l'encoder.
Il problema non e` l'implementazione, che e` comunque
possibile, ma bensi` il vantaggio.
Io non sto dicendo che non sia fattibile, bensi` che
la complessita` totale non diminuirebbe, anzi.
Fare "copy file.dv file.mp4:transcode/yuv12/weave..." non e`
piu semplice di "transcode file.dv -o file.mp4 -yuv123 -d weave ...".
bye,
-- 
   Piergiorgio Sartor

 ciò accade nel 99% dei casi.
???
Il suffisso può anche non esistere. Uno script non deve avere suffisso 
``.sh''. Un file di testo ascii, perchè vincolarlo a ``.txt''? C'è 
qualche specifica in merito? E ``.ascii'' oppure ``.text''?
Il magic number (si è un numero --- che ne so, a 80 bit --- o stringa 
che dir si voglia) è più sicuro di un pattern matching su un nome.


 piu semplice di "transcode file.dv -o file.mp4 -yuv123 -d weave ...".
come divevo sopra: la differenza sta nell'uniformità dell'interfaccia.


 qualche specifica in merito? E ``.ascii'' oppure ``.text''?
Mah... ma tu hai letto bene quello che ho scritto? Da come rispondi mi 
sembra di capire che tu hai capito che io "parteggio" per il suffisso, 
quando invece è vero il contrario!
Io ho semplicemente ribadito che, SICCOME il nome del file NON fa parte 
delle specifiche di un formato nel 995 dei casi, basare il 
riconoscimento di un file sul se ha una particolare estensione oppure no 
è un sistema prono al fallimento, e pertanto è Male.


 come divevo sopra: la differenza sta nell'uniformità dell'interfaccia.
Ma la complessita` resta uguale.
bye,
-- 
   Piergiorgio Sartor

 è un sistema prono al fallimento, e pertanto è Male.
Misunderstanding :)


 
-- 
E-Mail: 
risi...@libero.it
Sito Web: 
risitano.altervista.org
Gruppo: 
it.groups.yahoo.com/group/decomunistizziamo-internet/
"Noi vogliamo glorificare la guerra - sola igiene del mondo
il militarismo, il patriottismo, il gesto distruttore del liberatori, 
le belle idee per cui si muore."   F.T. Marinetti

file è, mentre con intèrnetteccsplòrer no.
lo adoro. tuttavia mi è un po' venuto da ridere quando mi ha fatto vedere
un file di windows installer con l'icona di una macchina da scrivere :-)


 Fallo.
adesso č tardi. Domani ti mando un po' di file, e tu devi identificarli
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.5. C, C++ and ASM developers
                               and beta testers are welcome!

 adesso č tardi. Domani ti mando un po' di file, e tu devi identificarli
                                                     ^^^^^^^
Sei tu che lo devi fare perň. Io non posso affermare l'invariaza del 
cobordo rispetto ad una operazione f e dire ``mo te manno un esempio, 
poi fatte la dimostrazione''.
Comunque, meglio di nulla... con codice alla mano naturalmente.


 adesso è tardi. Domani ti mando un po' di file, e tu devi identificarli
Rotfl.
-- 
  _|O|_ Davide Silvio Inglima-Modica     | "Mana is rapidly disappearing from"
  _|_|O mailto:
hades...@despammed.com
 | "the Earth, even the mana tree has"
  O|O|O 
http://limacat.blogspot.com
      | "begun to wither" Seiken Densetsu 3
Posted from X-Privat Free NNTP server - 
www.x-privat.org

 riconoscere un file senza doversi preoccupare del nome...
Affidare il riconoscimento dei file a un'euristica? Mi chiedo come faccia
ad essere il metodo preferito da tante persone.
Siamo d'accordo che il metodo basato sul suffisso sia inadeguato, ma
l'euristica è inadeguata per gli stessi motivi. E sappiamo tutti anche
qual è l'alternativa: tipi di file direttamente supportati nel file
system. Ciò comporta però il problema di capire come il file system
identifica i tipi:
- Il metodo perfetto: authority globale per l'assegnamento di
identificatori di tipo!!! (Con tutti i problemi che ciò comporta)
- Un metodo accettabile: utilizzare dei GUID...
Saluti.
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)

 Sei tu che lo devi fare però
Sensei, ti c'hanno mai mandato? chè credo non lo facciano abbastanza


 <icq:241572242>
But still I fear, and still I dare not
Laugh at the mad man (The Prophet's song)

 - Un metodo accettabile: utilizzare dei GUID...
Intendi metadati sul FS?


 Intendi metadati sul FS?
Ovvio.
