Newsgroup: it.comp.os.dibattiti
Titolo: Ancora su COM

Girovagando per la rete in cerca di altre informazioni, mi sono 
imbattuto in questa pagina, che spiega in un linguaggio semplice cosa è 
e cosa fa COM: se non sbaglio la questione era rimasta un po' in "sospeso".
http://www.puremeta.com/ole/OLEPaper.html
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 
http://www.puremeta.com/ole/OLEPaper.html
Utile link, direi.
Questa riga e` interessante:
"COM objects are programming language neutral, and thus can
be accessed from any development tool that supports COM"
Cioe` COM non dipende dal linguaggio, ma deve essere
supportato dal tool (compilatore? Linker?).
Il resto, direi, e` abbastanza chiaro: hanno messo assieme
server e DLL per trasparenza e prestazioni.
Il concetto e` meno nebuloso adesso, ma e` anche evidente che
non si puo` parlare di innovazione, ma di ottimizzazione.
Sia come praticita`, che come prestazioni.
Introducono l'idea di server, che pero` puo` essere
*locale* all'applicativo, cioe` una DLL.
Se ho capito bene... :-)
bye,
-- 
  Piergiorgio Sartor

 
http://www.puremeta.com/ole/OLEPaper.html
Si cmq le COM son cosi' belle che la M$ ha fatto .NET ... 
/me e i litigi coi componenti registrati che si autoupgradano
Ciao!
-- 
il Vide - ICQ# 5301833
Togli OE per rispondermi
IAMM - it.arti.musica.metal 
IAMMol webzine: 
http://www.iammol.com

 Si cmq le COM son cosi' belle che la M$ ha fatto .NET ... 
Tutto si può migliorare...


 Tutto si può migliorare...
Migliorare e' un conto, spazzare via e' un altro..
Dai, COM e DCOM sono implementate coi piedi..x ogni cosa che semplificano 
te ne complicano 2


 Si cmq le COM son cosi' belle che la M$ ha fatto .NET ...
COM e DCOM sono troppo dipendenti da Windows.
.NET è un puro caso che sia stato rilasciato per primo in ambiente Windows.
Saluti.

 
http://www.puremeta.com/ole/OLEPaper.html
Che lo stesso genere di cose si faceva nel 1987 su NeXTApp col suo runtime
delle classi (derivato da quello dell'Objective-C).
"Cocoa is the descendant of NeXTStep and has a rich design history
reaching back to 1987. Cocoa is implemented in Objective-C, an ANSI C
compatible language with dynamic object-oriented extensions modeled on
Smalltalk. It has been tailored for efficient development and runtime
performance. Cocoa applications can make use of core functionality
contained in traditional C and C++ libraries brought forward from legacy
application environments. It also provides Java interfaces to permit a
high performance, full featured Java development environment tailored to
Mac OS X specifically"
http://developer.apple.com/cocoa/index.html
E in piu', quello che adesso si chiama Cocoa, supporta tutte le tecniche
di OOP che gli ingegneri di MS hanno schifato.
-- 
):E...

 Windows. 
Infatti! Xo' .NET spazza via COM e DCOM, questo e' un dato di fatto.


> x ogni cosa che semplificano te ne complicano 2
la piu bella definizione che io abbia mai sentito di *COM.

 la piu bella definizione che io abbia mai sentito di *COM.
Peccato che la stessa cosa valga per EJB o tutto il resto del mondo
"dall'altra parte", che forse è anche peggio.
Saluti
Massimo

.NET è un puro caso che sia stato rilasciato per primo in ambiente Windows.
Dato che la M$ sviluppa per Windows è ovvio che rilasci la
sua piattaforma per il suo sistema operativo
--
Lawrence Oluyede
rhy...@myself.com

 Se ho capito bene... :-)
è-satto. Li chiamano server in-process. Al contrario di CORBA che 
ottimizza piuttosto la comunicazione con server remoti (per quel 
pochissimo che so di CORBA)
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

 
rhy...@myself.com

 di OOP che gli ingegneri di MS hanno schifato.
E che i nuovi profeti GNU/GPL schifano ancora di più. O sbaglio?
Che forse Esopo aveva ragione?
Saluti.

 pochissimo che so di CORBA)
Senza voler far polemica, se la mia semplificazione
e` corretta, direi che l'innovazione tecnica sta
nella (possibile) ottimizzazione dovuta alla scelta
del contesto specifico (DLL, IPC, server) caso per
caso. Pero` non vedo una innovazione concettuale.
Forse lo e` per i programmatori che non sono
abituati ad usare i meccanismi client-server,
i quali sicuramente si trovano con uno strumento
potente (il client-sever, appunto) senza doverci
pensare, o senza dover pensare ai dettagli.
Puo` essere una questione di punti di vista.
bye,
-- 
piergiorgio

per BSD e MacOSX, oltre al progetto Mono
non lo metto in dubbio (mi riferisco a Mono che è quello
allo stato + avanzato), ma non scommetterei su Mono...almeno
per ora
--
Lawrence Oluyede
rhy...@myself.com

 caso. Pero` non vedo una innovazione concettuale.
non lo so. Prima di COM cosa c'era? a me comunque COM piace perchè è 
scalabile e position-independent (o come si dice)


 scalabile e position-independent (o come si dice)
Position-independent? Che vuoi dire?
Saluti.

 scalabile e position-independent (o come si dice)
Beh, c'erano i server e le DLL, no?
In principio molte cose, forse quasi tutte
quelle utili, possono essere fatte tramite
server, che forse e` un metodo piu` robusto,
anche se piu lento.
Cioe`, cosa succede a COM se un componente
di tipo "interno" ha un bug o viene male
utilizzato e crasha?
bye,
-- 
piergiorgio

 utilizzato e crasha?
Crasha l'applicazione che lo usa, semplice.


 Infatti! Xo' .NET spazza via COM e DCOM, questo e' un dato di fatto.
Vedi che COM e DCOM non sono proprio la stessa cosa. Ciň che viene spazzato 
via da .NET č solo una implementazione sgraziata di COM: DCOM appunto.
COM insieme alle idee di base (le interfaccie ad esempio), sono alla base 
della nuova piattaforma.

 utilizzato e crasha?
Essendo in-process lascio a te la conclusione :-)
Saluti.


gia... L'idea delle COM e' bella ma il modo come sono stati implementati
mi lascia perplesso.
-- 
Sidewinder  
---------------------------------------------------------------------
Don't sweat it -- it's only ones and zeros.
		-- P. Skelly
---------------------------------------------------------------------

 Che forse Esopo aveva ragione?
A che ti riferisci? Io so che c'e' una certa ostilita' da parte di alcuni
verso il C++. Ti riferisci a questo?
-- 
):E...

 "dall'altra parte", che forse è anche peggio.
mah, non ne faccio una questione di parti,
idee belle vengono rovinate da implementazioni
non altrettanto belle.
ma una azienda di un certo calibro non potrebbe permettersi
implementazioni schifose di alcunche'.
nella aziendina dove lavoro la retrocompatibilita'
e' un dovere , morale innanzitutto verso chi usa
il software o meglio i "sistemi".
la microsoft, abusando del monopolio,
sbeffeggia allegramente e aggravia di costi gli sviluppatori
con la mancanza di compatibilita'.
con i mezzi di cui disponde, non *dovrebbe* comportarsi cosi'.
ciao.

 verso il C++. Ti riferisci a questo?
Ma va?
Saluti.

 Ma va?
Beh, anche se continuo ad apprezzare molte delle caratteristiche di questo
linguaggio, devo ammettere che il suo runtime lascia piuttosto a
desiderare, soprattutto dopo aver visto altri linguaggi tipo, ad esempio,
l'Objective-C.
-- 
):E...

 aver visto altri linguaggi tipo, ad esempio, l'Objective-C.
Cosa ti lascerebbe a desiderare del runtime?
Ciao.
-- 
BSD is for UNIX-lovers -- linux is for Windows-haters.

 con la mancanza di compatibilita'.
Ci credo fino ad un certo punto. Ovvero: perchè portarsi dietro 200 layer di
compatibilità che appesantiscono, incasinano e fanno del danno quando
lavorando da zero si potrebbe fare meglio??? Cui prodest??? Siamo poi sicuri
che facendo le cose "compatibili" alla fine i costi siano più bassi ed i
risultati migliori? O è la pigrizia di non voler cambiare a far sì che si
pensi questo?
Questa favola della "necessità di compatibilità all'indietro" che fino a
qualche tempo ha sempre orbato qualunque scelta progettuale inizia ad essere
messa in discussione anche dai guru e da chi si occupa professionalmente ed
ad altissimo livello di questi concetti. Attivita' "nuove" come Extreme
Programming o l'approcio Fortress Based al software di impresa vanno proprio
in questo senso.
Ho lavorato per anni con Microsoft (VB, ASP e COM), adesso lavoro con .Net
ed Ejb/Java/JSP e devo dire che la cosa che più mi piace di .Net rispetto
alla controparte Java è proprio questo suo stacco radicale (almeno a livello
di impressione, poi sotto le cose sono realizzate sempre con gli stessi
mattoncini) con il passato, stacco che con Java secondo me manca (e, per
come viene portato avanti il modello di sviluppo, è quasi impossibile si
faccia, carenza lamentata dallo stesso Scott McNealy in uno dei Keynote alla
Java One di S.Francisco di qualche settimana fa, mica una mia idea e
basta!). Se questo stacco lo prevedi e te lo aspetti e progetti in partenza
per fare in modo che ti pesi poco vedrai che la retrocompatibilità non è
così importante.
Saluti
Massimo

 Cosa ti lascerebbe a desiderare del runtime?
Beh, piu' che altro ho i seguenti dubbi, che mi puoi aiutare a chiarire:
- quanto si puo' fare affidamento sulla compatibilita' dei runtime dei 
diversi compilatori?
- fino a che punto si puo' modificare una classe base senza esser 
costretti a ricompilare le classi derivate?
- e' possibile estendere una classe senza averne i sorgenti?
- si possono spedire messaggi ad oggetti anonimi, cioe' il cui tipo ci 
e' ignoto, ma di cui si conosce parte dell'interfaccia?
- il runtime quanto e' customizzabile?
- in che modo e' possibile spedire messaggi a oggetti che non sono nello 
stesso spazio di indirizzamento?
- il C++ cosi' com'e' come consentirebbe lo sviluppo di un mercato di 
componenti o framework?
- posso usare il runtime da altri linguaggi?
Grazie

 E che i nuovi profeti GNU/GPL schifano ancora di più. 
Si', e progetti come KDE e Mono non esistono.
-- 
Davide Inglima, limaCAT

 E che i nuovi profeti GNU/GPL schifano ancora di più. O sbaglio?
E quelli di Jakarta/Tomcat NON hanno rotto le palle alla SUN per una
implementazione di J2EE indipendente, nooo...
-- 
Davide Inglima, limaCAT

 a chiarire: 
Posso risponderti in e-mail?


mah, non c'e' dubbio che quando ci si accorge
che un progetto e' fatto male, molte volte conviene
riscriverlo da zero, dopo aver imparato dai propri errori:
una piattaforma ben progettata ed ordinata e' comunque una
buona cosa, direi ottima, specie per gli sviluppatori.
ma qui siamo nel campo della "teoria delle piattaforme".
io volevo porre l'accento sulla questione "commerciale"
e "pratica" intesa come ricavo-costo=profitto.
orbene, la frequenza con cui questa azienda
-che dispone di risorse illimitate - manda sul mercato
nuove rivoluzioni e nuove piattaforme e' quantomeno sconcertante:
anzi eccessiva. e' come se in microsoft lavorassero vari team
e che ognuno vada un po' per conto suo.
poi, quando ottengono qualcosa di vendibile, lo buttano
sul mercato. poco importa se un anno dopo il lavoro di un altro
team mandera' al macero e rendera' obsoleto quanto venduto
l'anno precedente. saranno affari del cliente
(e costi del cliente) migrare alla nuova piattaforma.
certo , si puo' tener duro, usare sempre il vecchio prodotto:
vecchio prodotto che entro un paio d'anni, con la nuova release del
sistema operativo, magari sara' installabile con difficolta'
perche' non piu' supportato.
ci vogliono anche due anni per sviluppare una grossissima applicazione.
magari lo hai fatto con visual c++ + visual basic.
quando hai finito, scopri che arriva .net.
certo, puoi lavorare ancora per 2 anni, forse 3 con visual studio...  ma
poi?
so che il paragone non è azzeccato (trattasi di cose differenti)
ma io lavoro con borland builder ad un grosso lavoro di automazione
industriale iniziato nel '99. allora usavo la versione 1.0.
oggi sono alla 5.0, ho sempre installato la versione nuova e ricompilato
tutto senza _alcuna_ difficolta' e senza _costi imposti_ che avrebbero
oltretutto rallentato, e *non favorito* , lo sviluppo della mio business
-se devo investire risorse per migrare...-
questa e' serieta', secondo me.
serieta' che in regime di monopolio puo' essere omessa.
ciao.

 industriale iniziato nel '99. allora usavo la versione 1.0.
Se è per questo io compilo sorgenti del Visual C++ 1.0 con Visual C++.Net.
Saluti.


perdona la mia ignoranza, ma il c++.net non dovrebbe
esistere, dovrebbe esistere il C#.
o mi sbaglio?

 o mi sbaglio?
Non solo esiste C++.NET (chiamato managed C++), ma esiste anche,
ovviamente, il "normale" C++.


 Posso risponderti in e-mail?
si

ovviamente, il "normale" C++.
E per la "gioia" di quelli che speravano che Visual Basic avesse fatto
il suo tempo, c'e' anche (pare molto cambiato, controllero' prima o
poi...) 
VB.NET
 :(
[ero tra quelli che sperava nella fine del VB anche se l'ho usato per
4 lunghi anni...]
-- 
           ~~ ICQ#: 8761263 ~~ 
http://www.delymyth.net/
 ~~
            E-Mail Addy: DElyMyth [at] delymyth [dot] net
           => FREE! Hardware Anti-Virus!!! - /dev/brain <=
=> Warning: Mail Filter on: HTML-Mail, hotmail/msn/yahoo accounts. <=

 (pare molto cambiato, controllero' prima o poi...) 
VB.NET
 :(
L'hanno reso un po' più serio...


> L'hanno reso un po' più serio...
il fatto è che (quello che dico
e' tratto liberamente dalle riviste infomedia)
non esisono piu' vb o c++ o pascal,
o meglio, esistono solo per i gonzi (per i quali
sentirsi dire che non esiste piu' vb sarebbe stato un trauma).
esiste un nuovo linguaggio senza nome (che e' definito
dal bytecode -che è un formato binario-) e tutto quello che
e' stato deciso che deve essere implementato (ereditarieta',
niente ereditarieta' multipla etchetera) e' definito in questo modo.
poi, hanno esteso i linguaggi a cui mancava qualcosa (vb)
hanno ridotto quelli che erano piu' estesi (c++ ed hanno ottenuto C#)
praticamente cambia solo la sintassi, cioe' posso scrivere
un ciclo for in vb e un ciclo for in C# per dare l'illusione
al coder di aver mantenuto il proprio linguaggio -la propria
*sintassi*, a questo punto- preferita.
ma per esempio non posso avere l'ereditarieta' multipla
o le RTTI o qualunque altra peculiarita' del c++
che non è entrata a far parte della piattaforma
(quindi il C# non è c++, e' un'altra cosa:
dire che si riesce a compilare un sorgente c++
con c# e' vero, basta limitarsi a hello.cpp)
quello che ignoro e che vorrei sapere
e' se hanno incluso comunque un "vero" compilatore
c++, messo li' apposta, in visual studio .net.

 c++, messo li' apposta, in visual studio .net.
Certamente. Ne hai due di compilatori C++. Uno per il managed C++
che compila in IL (il bytecode di .NET) ed uno per il "normale" C++
che (ovviamente) compila in codice nativo.


 linguaggi.
Su OSX, ma anche altrove, si puo'. Puoi avere parti scritte in C o C++, 
parti scritte in java, parti in python, parti in AppleScript, parti in 
Objective-C, parti in TCL, parti nel linguaggio della shell; tutto 
all'interno dello stesso bundle.

 dello stesso bundle.
Cosa intendi? Spiega meglio, perché la cosa non mi è chiara. Quello
che è certo è che il SO, in questo caso, non c'entra nulla.


 linguaggi.
no, no. intendevo dire che puoi scrivere,
in due diverse applicazioni (una vb e una c#)
un ciclo for con ,evidentemente, due sintassi diverse.
la sua traduzione in bytecode .net sara' la stessa.

 la sua traduzione in bytecode .net sara' la stessa.
Sì, sì, non solo un ciclo for. Anche grandi parti di codice
equivalente in 
VB.NET
 ed in C# vengono compilate nel medesimo codice
IL.


 per 4 lunghi anni...]
Dely, VB *è* morto. 
VB.NET
 è tutto un altro linguaggio
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

Dely, VB *è* morto. 
VB.NET
 è tutto un altro linguaggio
Speriamo...
che VB sinceramente mi aveva stufato :)


 Dely, VB *č* morto. 
VB.NET
 č tutto un altro linguaggio
E viene pure distribuito in taglia XML.
(Scusami ma non riesco a rimanere serio dopo quel video)
-- 
Davide Inglima, limaCAT
che soffre di CLAUSTROFOBIA INFORMATICA!


gia. Ho smesso di sviluppare in VB gia da 2 anni..
E non mi pento. 
-- 
Sidewinder  
---------------------------------------------------------------------
The more data I punch in this card, the lighter it becomes, and the
lower the mailing cost.
		-- S. Kelly-Bootle, "The Devil's DP Dictionary"
---------------------------------------------------------------------