[Gfoss] traduzione terminologia

[a.furieri a lqt.it]

On Wed, 10 Nov 2010 09:21:27 +0100, Luca Delucchi wrote
> > ??? service shared object ????
> > sia l'una che l'altra cosa sono essenzialmente
> > delle banali librerie a caricamento dinamico.
> > nel caso dei moduli Python accompagnate da
> > qualche meta-file (egg).
> >
> 
> ok...
> 
> > non divertiamoci ad inventare termini
> > nuovi ad ogni passo per definire roba
> > nota e stranota sotto altri nomi più
> > comuni.
> >
> 
> non ho capito bene a cosa ti riferisci, io l'ho solo trovata non me 
> la sono inventata io :-P
> 

Luca, lo so bene che non te la sei inventata tu ...
giusto per capirci fino in fondo e per avere
un quadro più organico e completo:

- nella notte dei tempi esisteva solo lo static 
  linkage: cioè il software era già organizzato in moduli 
  distinti (librerie), ma era obbligatorio "cucire" 
  (link) tutti i moduli necessari dentro all'eseguibile 
  al momento della build: dopo di che non era più possibile 
  nessuna modifica (appunto: statico)

- in tempi successivi (anni '80) è stato introdotto
  il dynamic linkage: ora i moduli sono completamente
  esterni all'eseguibile, e verranno collegati solo
  al momento dell'esecuzione (run time).
  insomma, le benedette DLL aka shared libraries

- una ulteriore evoluzione di questa architettura
  dinamica consente addirittura di collegare in run 
  time anche moduli niente affatto previsti in fase di 
  progettazione iniziale (a patto che questi moduli
  implementino un'interfaccia standard e ben nota).
  ed ecco che nascono così le architture "a plugin".

in fondo Python (come tantissimi altri SW) lavora
semplicemente così quando richiami una IMPORT FROM:
va a cercarsi in una directory nota un EGG-file
di configurazione per quel package, dopo di che
si carica la DLL aka shared library relativa.

quindi possiamo divertici a chiamarli in mille
modi: moduli, estensioni, espansioni, plug-in ...

ma in fondo al meccanismo ci trovi sempre e
comunque le librerie a caricamento dinamico

ciao Sandro