[PHP] Guestbook

[orakool]

io, per quel che ho visto del ruby, lo giudico essenzialmente un buon linguaggio OOP, struttura sostanzialemnte bene, ma a mio parere è alla pari con altri come interpretazione della filosofia OOP. Questa probabilmente è una mia idea che verrà ampiamente criticata, ma così la penso.

Cmq certo, sono OT, ma meglio questo ot dialettico che gli ot-cazzata che ci sono in certi post seri.

Evidentemente non l'hai conosciuto abbastanza. O non hai conosciuto abbastanza la programmazione orientata agli oggetti.

La questione è semplice, moltissimi linguaggi sono ANCHE oo (vedi python, perl, lo stesso C++), ruby è SOLO oo, ma nemmeno come il java, in quanto in un vero linguaggio orientato agli oggetti la tipizzazione delle variabili non dovrebbe esistere, un oggetto deve poter rappresentare qualsiasi tipo di dato.
Aggiungo, che anche se il java ha i suoi pregi, il ruby è di una snellezza disarmante, ti fa ricredere sul fatto che sia più facile programmare procedurale che ad oggetti.

 

[fojeaf]

ok, aggiungo una cosa però: in python un programmatore può scrivere seguendo vari paradigmi, ma sotto, python è tutto ad oggetti: le funzioni sono oggetti, i moduli importati sono oggetti, etc. l'ANCHE sta in come deve/può scrivere il programmatore, ma per come è in realtà, python è OO

cmq, anche senza imparare il ruby, io sono convinto che la programmazione OO sia, oltre che + efficacie, anche + semplice della procedurale, funzionale, ad eventi etc

 

[imported_ShuraBozz]

Tutto è facile, il difficile è mettersi d'impegno, vi fate paranoie inutili.

 

[meh.]

in un vero linguaggio orientato agli oggetti la tipizzazione delle variabili non dovrebbe esistere, un oggetto deve poter rappresentare qualsiasi tipo di dato.

No.

E comunque, informati (sempre se intendi quello che ho capito):
Java: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html
C++: void*

Se non intendi quello, spiegati meglio

 

[orakool]

Quel "deve" ci stava male, la mia è un'opinione, non stavo facendo presente una regola

Criticavo per lo più il funzionamento del C++, che per quanto supporta il paradigma ad oggetti, non lo definisco un linguaggio totalmente orientato agli oggetti, in quanto "l'oggetto" non è nient'altro che un altro tipo definito dall'utente. E, in sostanza, che la programmazione ad oggetti si addice di più ai linguaggi non fortemente tipizzati, caratteristica tipica dei linguaggi di scripting.

 

[meh.]

Linguaggi che portano ad ambiguita' ed errori, un oggetto e' un oggetto, ovvero un tipo, e' una cosa normalissima, e ti ricordo che non e' il linguaggio orientato agli oggetti ma il tipo di programmazione, al massimo il linguaggio puo' implementare (o non implementare proprio) in maniera diversa features che aiutano la programmazione ad oggetti ma non ha alcun senso dire:

"Per me questo linguaggio e' orientato agli oggetti e questo no.", e' una visione delle cose la programmazione ad oggetti, che sia object oriented od object based.

Se proprio devi limitati ad un HURR mi piace il ruby DURR e non sparare sentenze insensate come "il C++ non e' totalmente orientato agli oggetti" che non vuol dir nulla. Ruby implementa tutte le features dell'OOP come fa il C++.

E per la cronaca, i linguaggi tipizzati sono meno ambigui e piu' chiari ed alla fine delle cose, migliori

 

[orakool]

Quella è un'idea tua, i linguaggi possono implementare meglio o peggio i paradigmi, non stiamo parlando del programmatore, stiamo parlando del linguaggio, stessa cosa per il concetto della tipizzazione, anche se andiamo off topic sull'off topic, che sia migliore o peggiore a questo punto _dipende_, ma non c'entra niente con il paradigma ad oggetti e la nostra discussione.

 

[meh.]

La questione è semplice, moltissimi linguaggi sono ANCHE oo (vedi python, perl, lo stesso C++), ruby è SOLO oo, ma nemmeno come il java, in quanto in un vero linguaggio orientato agli oggetti la tipizzazione delle variabili non dovrebbe esistere, un oggetto deve poter rappresentare qualsiasi tipo di dato.

Tu hai tirato in ballo la cosa.

Criticavo per lo più il funzionamento del C++, che per quanto supporta il paradigma ad oggetti, non lo definisco un linguaggio totalmente orientato agli oggetti, in quanto "l'oggetto" non è nient'altro che un altro tipo definito dall'utente. E, in sostanza, che la programmazione ad oggetti si addice di più ai linguaggi non fortemente tipizzati, caratteristica tipica dei linguaggi di scripting.

Che sia un tuo parere o meno, sono affermazioni errate. Ed il ruby permette anche programmazione funzionale se e' per questo, e allora?

Stavo semplicemente puntualizzando che hai sparato cazzate.

E per la cronaca non sono i linguaggi ad implementare i paradigmi, al massimo implementano funzioni per aiutare la programmazione in un certo paradigma ma e' il programmatore che scrive in quel paradigma Non ha senso parlare del linguaggio in questi termini.

Quella è un'idea tua

Non e' un'idea mia, e' cosi' che si definiscono le cose

L'idea mia al massimo e' che sia migliore una forte tipizzazione, ma a casa mia meno ambiguita' significa piu' mantenibilita' e chiarezza di conseguenza che la cosa e' migiore.

 

[orakool]

Per la precisione tu ti stai attacando a dei termini specifici per trollare, se ho scritto "implementa il paradigma" è per sbrigarmi, non perché un paradigma si possa implementare.
Usando i tuoi termini, quindi, ci sono linguaggi che "implementano più o più correttamente funzioni per aiutare la programmazione in un certo paradigma" o linguaggi che *stessa cosa, ma meno*. Vedi, non è puntualizzando che fai prevalere la tua idea.

C'è altro da dire? Andiamo pure avanti quanto vuoi

 

[meh.]

Impuntandoti sui termini come ho fatto anche io hai evitato di rispondere ad altre mie affermazioni, fallo.

La questione è semplice, moltissimi linguaggi sono ANCHE oo (vedi python, perl, lo stesso C++), ruby è SOLO oo, ma nemmeno come il java, in quanto in un vero linguaggio orientato agli oggetti la tipizzazione delle variabili non dovrebbe esistere, un oggetto deve poter rappresentare qualsiasi tipo di dato.

Questa, spiegamela un po', perche' non ha senso

 

[orakool]

uffa... allora, prendi il C++. E' nato come un adattamento, contiene tutti i concetti che fanno parte del C, cosa che un linguaggio ad oggetti non dovrebbe. Prendi invece il ruby, nato per essere ad oggetti, tutto è un oggetto, non hai alternative, DEVI usare gli oggetti, così è previsto.

La seconda parte te l'ho spiegata sopra, il ravanamento della tipizzazione.

 

[meh.]

In realta' e' una feature in PIU', basta non usare gli header del C ed usare un framework decente come Boost (che nel nuovo standard sara' accorpato), la tua tesi non sta in piedi piu' di tanto.

Ruby non e' solo OO, come ti ho detto, il fatto che tutto sia un oggetto si puo' scrivere codice procedurale o funzionale, anche in Python tutto e' un oggetto, eppure lo vedi come non del "tutto" OO. Ed in realta' sono piu' OO Java e C# visto che persino il main e' una classe (cosa orrenda).

 

[fojeaf]

il fatto che il main sia una classe a mio parere è un obrobrio, preferisco l'approccio di python e ruby, in cui tutto è+ un oggetto, ma si può scrivere senza usarli direttamente

 

[imported_sydarex]

Di sicuro sydra non hai ragione, in via teoria appoggio completamente stoner, e secondo me non ci sarebbe nemmeno da discuterne. Nell'OOP, generalmente parlando, è così che si fa, non è nessuna idea inculcata da nessun linguaggio.

E' totalmente falso. La definizione di OOP nuda e cruda non definisce alcun modificatore di accesso, semplicemente perché non riguarda l'implementazione ma i concetti.

La questione è semplice, moltissimi linguaggi sono ANCHE oo (vedi python, perl, lo stesso C++), ruby è SOLO oo, ma nemmeno come il java, in quanto in un vero linguaggio orientato agli oggetti la tipizzazione delle variabili non dovrebbe esistere, un oggetto deve poter rappresentare qualsiasi tipo di dato.

Ma non è vero. In Python TUTTO è un oggetto; e li usi per forza. Le funzioni builtin sono metodi del modulo (oggetto di tipo modulo) __builtins__, and so on. Lo script che tu scrivi è un oggetto di tipo modulo.

Ruby non e' solo OO, come ti ho detto, il fatto che tutto sia un oggetto si puo' scrivere codice procedurale o funzionale, anche in Python tutto e' un oggetto, eppure lo vedi come non del "tutto" OO. Ed in realta' sono piu' OO Java e C# visto che persino il main e' una classe (cosa orrenda).

Beh, oddio, dipende da come la vedi. A livello strettamente implementativo, addirittura uno script Python è un oggetto di tipo modulo, come detto rispondendo a orakool. In effetti, è totalmente a oggetti.

Il problema sta nella confusione tra supporto al paradigma e struttura del linguaggio.
Il supporto al paradigma, come ha giustamente detto meh, è l'insieme delle funzionalità che il linguaggio offre a supporto di un paradigma di programmazione.
La struttura del linguaggio è come il linguaggio è strutturato, appunto, nella sua implementazione. Che è ciò di cui si è preso a parlare da qualche post a ora e che non c'entra na sega con il discorso che stavo facendo con stoner.

Ciò di cui parlavo era la filosofia con cui è implementato il supporto al paradigma nel C++ e nei linguaggi che hanno preso spunto da esso. Che è un discorso di opinioni personali, in cui non esistono verità assolute (e l'ho specificato; invece mi sono sentito dire che *ho torto*, mah), e perfettamente valido e interessante (seppur strettamente accademico) se si è in grado di non prendere per oro colato ciò che i linguaggi ci propinano.

Non so perché continuo a rispondere, da giorni scrivo sempre le stesse cose e nessuno afferra ciò che dico. :°D

 

[meh.]

sydarex: http://en.wikipedia.org/wiki/Information_hiding

Se il programmatore e' incapace, non usi la sua libreria. Tu _HAI_ torto su quel fronte.

 

[imported_sydarex]

sydarex: http://en.wikipedia.org/wiki/Information_hiding

Mmh, beh?

Se il programmatore e' incapace, non usi la sua libreria. Tu _HAI_ torto su quel fronte.

Scusa meh, ma non capisco cosa vuoi dire. A cosa ti riferisci esattamente con "Se il programmatore e' incapace, non usi la sua libreria"?

 

[stoner]

A quello che ti sto dicendo da 3 pagine e che ancora non hai capito. Se il programmatore fa un'incapsulamento sbagliato rendendo privato un'attributo che potrebbe servire all'esterno è uno sbaglio del programmatore non un problema dato dal fatto che il C++ (o il linguaggio in questione) prevede specificatori d'accesso diversi da public.

 

[imported_sydarex]

A quello che ti sto dicendo da 3 pagine e che ancora non hai capito. Se il programmatore fa un'incapsulamento sbagliato rendendo privato un'attributo che potrebbe servire all'esterno è uno sbaglio del programmatore non un problema dato dal fatto che il C++ (o il linguaggio in questione) prevede specificatori d'accesso diversi da public.

Oh, stoner, sei tu che non hai capito.
Fin dal primo messaggio ti ho detto che non-ho-negato-questo.

Quello che ho detto è: "questo tipo di incapsulamento lo ritengo sbagliato, perchè x e y". Tu mi stai dicendo che "non porta a scrivere cattive librerie". Non ho detto che incapsulamento-con-private -> librerie-di-merd*, ho detto che non-mi-piace e ho argomentato il perché.

Se poi mi si viene a dire che si-fa-così-e-basta-perché-lo-dice-cpiùpiù-punto, allora è inutile continuare a parlare da soli, scusa.

 

[stoner]

A cosa ti riferisci esattamente con "Se il programmatore e' incapace, non usi la sua libreria"?

Calmati, rispondevo solo a questa domanda, mi sembra che sia stato tu a porla.

 

[meh.]

Se poi mi si viene a dire che si-fa-così-e-basta-perché-lo-dice-cpiùpiù-punto, allora è inutile continuare a parlare da soli, scusa.

Si fa cosi' perche' usando da esterno attributi che dovrebbero essere private ad un aggiornamento della libreria potrebbe andare tutto a puttane, ma tanto in python va a puttane anche l'ABI ogni aggiornamento

Edit: Quello che voglio dire e' che seguire gli standard del Python che praticamente impedisce una corretta information hiding dove e' possibile applicarla come si deve e' una grandissima cazzata.

 

[imported_sydarex]

Calmati, rispondevo solo a questa domanda, mi sembra che sia stato tu a porla.

Sono calmissimo, cercavo solo di farmi capire visto che sono pagine che non lo facciamo.

Si fa cosi' perche' usando da esterno attributi che dovrebbero essere private ad un aggiornamento della libreria potrebbe andare tutto a puttane, ma tanto in python va a puttane anche l'ABI ogni aggiornamento

Si, ma io non ho mai detto che bisogna *sempre* usarlo direttamente, ho semplicemente detto che l'impedimento coatto d'accesso non mi pare la scelta migliore. Forse la più sicura, non la migliore. =)

Edit: Quello che voglio dire e' che seguire gli standard del Python che praticamente impedisce una corretta information hiding dove e' possibile applicarla come si deve e' una grandissima cazzata.

Beh, tua opinione. La mia esperienza è che porta solo vantaggi, prché si seguano le convenzioni.

 

[meh.]

Edit: Quello che voglio dire e' che seguire gli standard del Python che praticamente impedisce una corretta information hiding dove e' possibile applicarla come si deve e' una grandissima cazzata.

Beh, tua opinione. La mia esperienza è che porta solo vantaggi, prché si seguano le convenzioni.

Ma hai capito a cosa serve l'information hiding o fai finta?

E la tua esperienza quale sarebbe? {Non intendo HURR chi sei DURR, intendo librerie reali o programmi che non fanno incazzare un mucchio di gente perche' cambiano ABI/API al cambio di versione (vedi Python )}

 

[imported_sydarex]

E la tua esperienza quale sarebbe? {Non intendo HURR chi sei DURR, intendo librerie reali o programmi che non fanno incazzare un mucchio di gente perche' cambiano ABI/API al cambio di versione (vedi Python )}

Faccio il programmatore Python (e PHP e tuttociòchechiedono, ma va beh), e l'utilizzo di convenzioni al posto di rigide restrizioni d'accesso ha sempre e solo giovato alla flessibilità e semplicità di manuntenzione.

Vabbé, lasciando stare la migrazione a Python 3 che in primis è un discorso a parte, e in secondo luogo non c'entra nulla con il discorso che stiamo facendo (cioè, non ha cambiato nulla riguardo l'oop). Comunque Python 2.X non è dimesso, è ancora supportato.

Non è che se *posso* (nota, "posso" e non "devo") usare Foo.Bar invece di Foo.setBar() mi salta tutto all'istante, eh.
In primo luogo va visto SE ho avuto bisogno di farlo, e poi *come* l'ho fatto.

 

[stoner]

Non è che se *posso* (nota, "posso" e non "devo") usare Foo.Bar invece di Foo.setBar() mi salta tutto all'istante, eh.
In primo luogo va visto SE ho avuto bisogno di farlo, e poi *come* l'ho fatto.

Visto che stai dicendo che fare così è meglio, implica che quello è il tuo modo di ragionare. Se tanto mi da tanto tu fai così e basta, ad un aggiornamento di libreria se si decide di cambiare l'implementazione interna della classe il tuo codice non funziona più (questa cosa ho dimenticato di dirla prima).

 

[meh.]

E la tua esperienza quale sarebbe? {Non intendo HURR chi sei DURR, intendo librerie reali o programmi che non fanno incazzare un mucchio di gente perche' cambiano ABI/API al cambio di versione (vedi Python )}

Faccio il programmatore Python (e PHP e tuttociòchechiedono, ma va beh), e l'utilizzo di convenzioni al posto di rigide restrizioni d'accesso ha sempre e solo giovato alla flessibilità e semplicità di manuntenzione.

Vabbé, lasciando stare la migrazione a Python 3 che in primis è un discorso a parte, e in secondo luogo non c'entra nulla con il discorso che stiamo facendo (cioè, non ha cambiato nulla riguardo l'oop). Comunque Python 2.X non è dimesso, è ancora supportato.

Non è che se *posso* (nota, "posso" e non "devo") usare Foo.Bar invece di Foo.setBar() mi salta tutto all'istante, eh.
In primo luogo va visto SE ho avuto bisogno di farlo, e poi *come* l'ho fatto.

Non hai risposto alla mia domanda, non parlo di mantenibilita' da parte tua, mi riferisco a librerie non fatte da te e magari usate da un user base > 3 persone.

La differenza tra Foo.Bar e Foo.setBar() e' _MOLTA_, ad esempio se per qualche ragione devi aggiungere qualche controllo obbligatorio o fare dell'elaborazione col primo obblighi i programmatori o ad usare la libreria vecchia o a modificare tutti i sorgenti in cui e' presente nel secondo il programmatore che usa la libreria non si accorgera' di nulla e sara' contento, poi va beh che io odio (get|set)* preferisco fare tutto con lo stesso nome ed overloaddare

Il discorso e' diverso ovvio ma io non sto parlando delle features dell'OOP in Python, io parlo per quel che riguarda lo sviluppatore che usa embeddare python in suo programma o che usa un certo script che al cambio di versione va tutto a farsi inculare perche' gli sviluppatori del python non sono capaci a mantenere un ABI stabile.

Edit: Ecco mentre scrivevo aveva gia' detto stoner in maniera piu' breve e semplice.