[C] Domanda su OOP

[Felixfree]

Originariamente inviato da Fox82
Forse non ho capito bene il discorso ma mi sembra che confusione la stai facendo tu:

gli ordmbs sono dbms che gestiscono oggetti nel senso vero e proprio della oop. Sono in grado cioè di serializzare su hd istanze di classi e deserializzarle all'occorrenza

http://it.wikipedia.org/wiki/DBMS#DBMS_ad_oggetti

Non avendoli mai usati e non conoscendo postgressql non ti so dire di più, ma il principio è quello

...ritorniamo quindi al punto di partenza se le cose stanno così: come fà un ORDBMS a utilizzare classi e oggetti se è scritto in C, linguaggio che per le informazioni in mio possesso non permette la definizione di una classe (infatti per questo è nato il C++)?

[Fox82]

Non è così sconvolgente, alla fine tutte le operazioni che la macchina fa si riducono a segnali elettrici...

Come fa a supportare gli oggetti se la macchina gestisce solo segnali elettrici?

Semplice: ci sono sopra parecchi livelli di astrazione

[Felixfree]

Originariamente inviato da Fox82
Non è così sconvolgente, alla fine tutte le operazioni che la macchina fa si riducono a segnali elettrici...

Come fa a supportare gli oggetti se la macchina gestisce solo segnali elettrici?

Semplice: ci sono sopra parecchi livelli di astrazione

Niente da eccepire su questo... ma la tua risposta non ha apportato nessun incremento alle mie conoscenze!

Il paradigma della OOP è stato inventato per modellare i problemi nel modo più vicino possibile a come la mente umana è abituata a risolverli (più tutta una serie di innumerevoli altre cose) ed essa al momento è probabilmente il più alto livello di astrazione implementabile e ciò significa che se siamo arrivati fino a qui con quello che c'era prima certe cose non si potevano fare... ragion per cui capisco il discorso dei livelli di astrazione, ma a me serve capire esattamente a quale livello si colloca la situazione con la quale ho a che fare!

[Ikitt]

Originariamente inviato da Felixfree
Il paradigma della OOP è stato inventato per modellare i problemi nel modo più vicino possibile a come la mente umana è abituata a risolverli (più tutta una serie di innumerevoli altre cose) ed essa al momento è probabilmente il più alto livello di astrazione implementabile e ciò significa che se siamo arrivati fino a qui con quello che c'era prima certe cose non si potevano fare...

No, si potevano fare lo stesso, ma in modo eventualmente piu` goffo, piu` macchinoso, meno elegante etc. etc. Il paradigma OOP in se non aggiunge (non in modo a me noto, almeno) alcuna potenza espressiva rispetto... All'assembler.

ragion per cui capisco il discorso dei livelli di astrazione, ma a me serve capire esattamente a quale livello si colloca la situazione con la quale ho a che fare!

Bah, _se_ ho ben capito la situazione, sinceramente non capisco come il linguaggio con cui e` implementato l'ORDBMS dovrebbe influenzare con la sua potenza espressiva e/o con la sua object orientation.

[oregon]

Originariamente inviato da Fox82
Forse non ho capito bene il discorso ma mi sembra che confusione la stai facendo tu:

gli ordmbs sono dbms che gestiscono oggetti nel senso vero e proprio della oop. Sono in grado cioè di serializzare su hd istanze di classi e deserializzarle all'occorrenza

http://it.wikipedia.org/wiki/DBMS#DBMS_ad_oggetti

Non avendoli mai usati e non conoscendo postgressql non ti so dire di più, ma il principio è quello

La confusione di cui parlavo (e che, non te la prendere, tu accresci ...) era riferita alla "programmazione OOP" in relazione alla "capacità del DBMS di gestire oggetti complessi come suoi dati".

Questa relazione non esiste ... tutto qui.

Ovvero, un DBMS capace di trattare "oggetti" (dati complessi serializzati) non e' *solo per questo* necessariamente realizzato con linguaggi OOP ma puo' essere realizzato con *qualsiasi* linguaggio (e vale anche il viceversa ...).

[Fox82]

Ah ok, scusa, avevo capito che per oggetti intendessi semplicemente dati binari.

Sorry

[Felixfree]

Originariamente inviato da Ikitt
No, si potevano fare lo stesso, ma in modo eventualmente piu` goffo, piu` macchinoso, meno elegante etc. etc. Il paradigma OOP in se non aggiunge (non in modo a me noto, almeno) alcuna potenza espressiva rispetto... All'assembler.

...quindi per te incapsulamento, ereditarietà e polimorfismo non sono caratteristiche che aggiungono potenza espressiva ad un linguaggio? Scusa ma se la tua è una battuta tutto OK... altrimenti interrompiamo qui poichè si va molto OT.

Bah, _se_ ho ben capito la situazione, sinceramente non capisco come il linguaggio con cui e` implementato l'ORDBMS dovrebbe influenzare con la sua potenza espressiva e/o con la sua object orientation.

Come credo sia chiaro a chi ha partecipato a questa discussione io non ho mai scritto il sorgente di un ORDBMS e non ho idea di come poter ampiare gli orizzonti di quest'ultimo... sto cercando informazioni in tal senso e la cosa che dici di non capire è proprio quella che vorrei mi venisse spiegata!

[Felixfree]

Originariamente inviato da oregon
La confusione di cui parlavo (e che, non te la prendere, tu accresci ...) era riferita alla "programmazione OOP" in relazione alla "capacità del DBMS di gestire oggetti complessi come suoi dati".

Questa relazione non esiste ... tutto qui.

Ovvero, un DBMS capace di trattare "oggetti" (dati complessi serializzati) non e' *solo per questo* necessariamente realizzato con linguaggi OOP ma puo' essere realizzato con *qualsiasi* linguaggio (e vale anche il viceversa ...).

Scusate ma così non mi state aiutando se la volontà di aiutarmi c'è: cosa significa "dati complessi serializzati"? Partendo dal presupposto che io per convenzione chiamo oggetto solo l'istanza di una classe (e solo nel caso in cui mi stia riferendo alla OOP, altrimenti non uso mai il termine oggetto), mentre qualsiasi altra cosa come array, record, ecc. la considero un dato strutturato... potete precisare meglio quanto avete affermato nelle ultime risposte? (Tu e FOx82)

[Ikitt]

Originariamente inviato da Felixfree
...quindi per te incapsulamento, ereditarietà e polimorfismo non sono caratteristiche che aggiungono potenza espressiva ad un linguaggio? Scusa ma se la tua è una battuta tutto OK... altrimenti interrompiamo qui poichè si va molto OT.

Interrompiamo pure, a meno che tu non mi indichi un programma che e` impossibile da realizzare mancando incapsulamento, ereditarieta` e polimorfismo (Si noti peraltro che l'incapsulamento si puo` ottenere bene o male con molti altri linguaggi di programmazione, anche non dichiaratamente OOP).

In questo senso intendo potenza espressiva: si puo` far fare alla macchina in Java qualcosa che in ASM non si puo` fare?
No.

Poi e` chiaro che il Java (restando nell'esempio), dal punto di vista dell'utente, non della macchina, aggiunge eccome potenza espressiva al linguaggio. Non c'e` neppure paragone.

Ma esprimo 'meglio', non 'di piu`'.

Se tutto questo fa ridere o meno lo lascio decidere al lettore

Come credo sia chiaro a chi ha partecipato a questa discussione io non ho mai scritto il sorgente di un ORDBMS e non ho idea di come poter ampiare gli orizzonti di quest'ultimo... sto cercando informazioni in tal senso e la cosa che dici di non capire è proprio quella che vorrei mi venisse spiegata!

Il punto e` il seguente: il linguaggio con cui e` scritto l'ORDBMS non pone alcun vincolo sostanziale sulla potenza espressiva dello stesso. Che PostgreSQL sia scritto in C o in C++ (a condizione che sia ben fatto, chiaramente), non cambia nulla per l'utente.

O per meglio dire, non capisco come il detto linguaggio usato per la realizzazione possa interferire con la potenza espressiva, perche` non conosco alcun modo tale per cui questo possa accadere.

[Felixfree]

Originariamente inviato da Ikitt
Interrompiamo pure, a meno che tu non mi indichi un programma che e` impossibile da realizzare mancando incapsulamento, ereditarieta` e polimorfismo (Si noti peraltro che l'incapsulamento si puo` ottenere bene o male con molti altri linguaggi di programmazione, anche non dichiaratamente OOP).

In questo senso intendo potenza espressiva: si puo` far fare alla macchina in Java qualcosa che in ASM non si puo` fare?
No.

Poi e` chiaro che il Java (restando nell'esempio), dal punto di vista dell'utente, non della macchina, aggiunge eccome potenza espressiva al linguaggio. Non c'e` neppure paragone.

Ma esprimo 'meglio', non 'di piu`'.

...infatti tu nella prima citazione hai detto "potenza espressiva" da non confondere con "funzionalità aggiuntive"... siamo d'accordo che non esistono cose fattibili in Java e non fattibili in assembler: sarebbe un assurdo poichè l'assembler è il linguaggio con cui si indica effettivamente alla macchina cosa fare!

Se tutto questo fa ridere o meno lo lascio decidere al lettore

...non volevo dirlo in quel senso: non era mia intenzione fare dell'ironia!

Il punto e` il seguente: il linguaggio con cui e` scritto l'ORDBMS non pone alcun vincolo sostanziale sulla potenza espressiva dello stesso. Che PostgreSQL sia scritto in C o in C++ (a condizione che sia ben fatto, chiaramente), non cambia nulla per l'utente.

O per meglio dire, non capisco come il detto linguaggio usato per la realizzazione possa interferire con la potenza espressiva, perche` non conosco alcun modo tale per cui questo possa accadere.

Diciamo che a me manca questo legame: "caratteristiche ORDBMS - codice sorgente". Quando vado a fare una qualche operazione con PostgreSQL questa verrà svolta secondo i passi indicati dal suo codice... giusto? Il fatto che in un ORDBMS ogni tabella definisca una classe e PostgreSQL implementi l'ereditarietà tra tabelle e funzioni e operatori siano polimorfici mi pone nella condizione di chiedermi come avvengono questa successioni di eventi e come io posso fare a modificare il codice sorgente affinchè sia possibile fare determinate operazioni che adesso PostgreSQL non ammette!