Ruby e Overloading

Rigiro su questa lista una discussione filosofica tra me ed un’altro mio
amico rubysta salentino:

In ruby non e’ possibile effettuare un overloading sullo stile di C++ o
Java (etc.):

class Prova
def pippo(primo)
end

def pippo(primo,secondo)
end

end

Perche’? come si risolve?
La spiegazione che al momento sono riuscito a darmi e’ la seguente:
ruby e’ un linguaggio dinamicamente tipizzato, di conseguenza non
dichiariamo il tipo dei parametri;
un eventuale overloading dovrebbe quindi tenere conto soltanto del
numero dei parametri… questo
gia’ ne limita’ notevolmente l’utilita’.

Inoltre esistono i parametri di lunghezza variabile:

def pippo(*primo)
puts primo
end

pippo(“prova”)
pippo(“prova”,2)

Quindi a mio avviso la soluzione in ruby dovrebbe essere qualcosa del
tipo:

class Prova
def pippo(*ciccio)
case ciccio.length
when 1: pippo_1 ciccio[0]
when 2: pippo_2 ciccio[0], ciccio[1]
end
end

private
def pippo_1(ciccio)
  puts ciccio
end

def pippo_2(ciccio1, ciccio2)
  puts ciccio1
  puts ciccio2
end

end

p = Prova.new

p.pippo(“prova”)
p.pippo(“pluto”,“ciccio”)

Potremmo addirittura pensare di metaprogrammare il concetto in qualcosa
del tipo:

class Prova
overload :pippo, :pippo_1, :par_length => ‘==1’
overload :pippo, :pippo_2, :par_length => ‘==2’
overload :pippo, :pippo_2, :par_length => ‘==2’, :par_types =>
Fixnum

def pippo_1(ciccio)
   puts ciccio
end

def pippo_2(ciccio1, ciccio2)
   puts ciccio1
   puts ciccio2
end

def pippo_2int(ciccio1, ciccio2)
    puts "la somma e' : #{ciccio1+ciccio2}
end

end

Cosa ne pensate?
Riguardo alle motivazioni e alle soluzioni alternative?


rpl

In Rails sfruttano un’Hash per risolvere il tuo problema e rendere le
chiamate + idiomatiche. Una specie di oveloading del metodo render viene
fatto grossomodo
così:

Faccio l’overloading marcando i differenti parametri con un simbolo

non
per tipo

Es di utilizzo

render :text => ‘mytext’
render :file => File.new(…)

implementazione

reindirizza il render ai metodi specifici…

def render (options = {})
if text = options[:text]
render_text …
elsif file = options[:file]
render_file …
else

end
end

Mi pare una soluzione abbastanza carina perchè sai anche che significato
ha
quello che passi, cioè puoi fare degli overloading dove passi sempre un
parametro dello stesso tipo ma collegandolo ad un simbolo diverso fai
fare
al metodo qualcos’altro.

Paolo

— Ripley [email protected] ha scritto:

end

dichiariamo il tipo dei parametri;
le due cose non sono del tutto interdipendenti, alcuni
linguaggi sono dinamicamente tipati ma ti permettono
di dichiarare opzionalmente il tipo dei parametri (il
che porta anche a cose migliori dell’overloading
c+±like).
Direi che in ruby è impossibile perché non si può
dichiarare il tipo degli argomenti, e basta.

un eventuale overloading dovrebbe quindi tenere
conto soltanto del
numero dei parametri… questo
gia’ ne limita’ notevolmente l’utilita’.

non direi, gli argomenti opzionali, che sono la cosa
che hai appena descritto, sono utilissimi :slight_smile:

essere qualcosa del tipo:
def pippo_1(ciccio)

p.pippo(“prova”)
p.pippo(“pluto”,“ciccio”)

attenzione, case è per certi versi cattivo… se vuoi
aggiungere un nuovo oggetto devi sempre andare a
modificare pippo, Spesso puoi scrivere una cosa
così:
def foo(a)
case a
when A fai_roba
when B fai_altro
end
end
spostando la logica nelle classi A e B, così poi #foo
diventa solo

def foo(a)
a.fai_roba
end

Questo vale anche in C++/Java, ovviamente, ma in ruby
hai il vantaggio di poter aggiungere queste cose ai
tipi bultin.

Quindi mentre in java per scrivere un metodo che
trasformi un oggetto in YAML devi avere un pacco di
metodi overloadati, in ruby puoi aggiungere to_yaml
alle classi stesse. Non solo, puoi anche ridefinirlo
per un singolo oggetto. La necessità dell’overloading
è un po’ diminuita anche da questo.

def pippo_1(ciccio)
end

end

Cosa ne pensate?

C’è una differenza grossa tra quel che hai fatto e
quel che sarebbe overloading in java/c++: il tipo
analizzato è dinamico e non statico. Nel momento in
cui utilizzi il tipo dinamico per cercare il metodo
corretto sei arrivato al multiple dispatch (che io
adoro) ma che in ruby non c’è nativamente.

Riguardo alle motivazioni e alle soluzioni
alternative?

Puoi dare un’occhiata ai moduli multi.rb e
StrongTyping (nome errato, purtroppo) per vedere
implementazioni più raffinate.
C’è un certo punto nella carriera di un rubyista in
cui si finisce per implementare certe cose, poi in
generale ci si rende conto che non serve quasi mai ad
un piffero :slight_smile:


icq: #69488917
blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info

Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

— Paolo Donà [email protected] ha scritto:

In Rails sfruttano un’Hash per risolvere il tuo
problema e rendere le
chiamate + idiomatiche. Una specie di oveloading del
metodo render viene
fatto grossomodo così:

siccome sono quello che ha più scazzi con rails al
mondo, mi permetto di protestare su questa cosa, che
ho sempre ritenuto sbagliata:

Faccio l’overloading marcando i differenti

parametri con un simbolo non
per tipo

Es di utilizzo

render :text => ‘mytext’
render :file => File.new(…)

scrivere questo è più lungo che scrivere
render_text ‘mytext’
render_file File.new

Inoltre, rende sostanzialmente impossibile aggiungere
un nuovo elemento alla scelta. Mentre se ci fossero
normali metodi potrei aggiungere il mio
render_yaml obj.to_yaml

allo stato attuale il dispatch avviene sulla base di
un pacco di switch cablati nel codice e devo
ridefinire #render oppure mi trovo con un metodo
inconsistente con il resto (o peggio devo modificare i
sorgenti).

Infine, mette insieme un pacco di funzionalità
separate, con effetti deleteri sulla pulizia
concettuale e sulla documentazione, che invece di
avere due righe per ogni metodo ne ha duecento per uno
solo.

E #render non è nemmeno pessimo… ma cavolo capire ad
occhio la differenza tra Model.find(1,2,3)
Model.find([1,2,3]) Model.find(1) e Model.find([1]) è
una follia.
Abbasso i condizionali! :slight_smile:

PS
si, in verità per me è sbagliato pure l’overloading in
C++ e java


icq: #69488917
blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info

Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

ringrazio sia gabriele che paolo per le ottime oltre che celeri risposte
:slight_smile:

gabriele renzi wrote:

le due cose non sono del tutto interdipendenti, alcuni
linguaggi sono dinamicamente tipati ma ti permettono
di dichiarare opzionalmente il tipo dei parametri (il
che porta anche a cose migliori dell’overloading
c+±like).
Direi che in ruby è impossibile perché non si può
dichiarare il tipo degli argomenti, e basta.

giusta osservazione

non direi, gli argomenti opzionali, che sono la cosa
che hai appena descritto, sono utilissimi :slight_smile:

sono daccordo :slight_smile:
intendevo dire (e mi sono espresso male) l’utilita’
di inserirlo nella sintassi del linguaggio.

diventa solo
trasformi un oggetto in YAML devi avere un pacco di
metodi overloadati, in ruby puoi aggiungere to_yaml
alle classi stesse. Non solo, puoi anche ridefinirlo
per un singolo oggetto. La necessità dell’overloading
è un po’ diminuita anche da questo.

Qui mi hai aperto gli occhi :slight_smile:
Effettivamente le classi aperte consentono di rovesciare
il problema nella maggior parte dei casi.

C’è una differenza grossa tra quel che hai fatto e
quel che sarebbe overloading in java/c++: il tipo
analizzato è dinamico e non statico. Nel momento in
cui utilizzi il tipo dinamico per cercare il metodo
corretto sei arrivato al multiple dispatch (che io
adoro) ma che in ruby non c’è nativamente.

potresti dettagliare meglio cosa intendi?

Puoi dare un’occhiata ai moduli multi.rb e
StrongTyping (nome errato, purtroppo) per vedere
implementazioni più raffinate.
C’è un certo punto nella carriera di un rubyista in
cui si finisce per implementare certe cose, poi in
generale ci si rende conto che non serve quasi mai ad
un piffero :slight_smile:

Come ho scritto sopra: “mi hai aperto gli occhi”.

Ho gia’ sperimentato diverse volte come le abitudini ereditate
dagli altri linguaggi che ho usato o uso mi portino a scrivere
del codice non propriamente ruby :frowning:

Credo faccia parte della fase di apprendimento :slight_smile:
e quando scopro come andrebbero realmente fatte le cose in ruby rimango
sempre piacevolmente sorpreso.


rpl

gabriele renzi wrote:

un pacco di switch cablati nel codice e devo
ridefinire #render oppure mi trovo con un metodo
inconsistente con il resto (o peggio devo modificare i
sorgenti).

Infine, mette insieme un pacco di funzionalità
separate, con effetti deleteri sulla pulizia
concettuale e sulla documentazione, che invece di
avere due righe per ogni metodo ne ha duecento per uno
solo.

Osservazione giustissima :slight_smile:
Qualcuno lo ha fatto notare agli sviluppatori di rails?
cosa ne pensano loro?


rpl

Inoltre, rende sostanzialmente impossibile aggiungere
un nuovo elemento alla scelta. Mentre se ci fossero
normali metodi potrei aggiungere il mio
render_yaml obj.to_yaml

Beh, questo non è vero, si può fare
così:

render :yaml => obj.to_yaml

alias :old_render :render
def render (options ={})
if options[:yaml]
do_wathever_you_want_with options[:yaml]
else
old_render options
end
end

Sul fatto che sia meglio un approccio dell’altro non lo so, non volgio
sbilanciarmi e non voglio dire che Gabriele abbia torto,anzi, forse
dipende
molto dalla psiche dei programmatori.
Nel senso che in rails ci sono già tanti metodi, e aggiungerne altri forse
potrebbe generare confusione. Aggiungere invece un’opzione ad un metodo
esistente da la sensazione di tenere la libreria ‘compatta’ e ti fa
sentire
un pò più a tuo agio come utilizzatore, nel senso che ti pare di avere tutto
sotto controllo.
Ovvio, poi tutto ha un prezzo… pochi metodi te li ricordi, ma sono più
difficili da estendere… chissà dove sta veramente il giusto?

— Paolo Donà r[email protected] ha scritto:

render :yaml => obj.to_yaml

alias :old_render :render
def render (options ={})
if options[:yaml]
do_wathever_you_want_with options[:yaml]
else
old_render options
end
end

si infatti è quello che ho scritto dopo “a meno di
ridefinire il metodo”. Però in questo modo hai un
costo di codice inutile, la documentazione non si può
aggiornare, perdi prestazioni, non hai la reflection
per sapere quali render esistono e sporchi il
namespace (potresti wrapparlo in una proc e mantenere
quest’ultimo pulito,
però).

Sul fatto che sia meglio un approccio dell’altro non
lo so, non volgio
sbilanciarmi e non voglio dire che Gabriele abbia
torto,anzi, forse dipende
molto dalla psiche dei programmatori.

Il fatto è che io lo so che ho torto :frowning:
Sembra che la maggior parte delle persone ami il
consolidamento di molti metodo in uno solo, quindi
concordo che è questione di mentalità. Temo dipenda
dal fatto che ho i capelli ricci.


icq: #69488917
blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info

Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

ho dato una scorsa velocissima, ma ho visto un articolo attinente che
credo
ti possa interessare…
http://www.artima.com/rubycs/articles/patterns_sexp_dsls.html

On 6/16/06, Ripley remov[email protected] wrote:

gia’ ne limita’ notevolmente l’utilita’.
Quindi a mio avviso la soluzione in ruby dovrebbe essere qualcosa del
private
p = Prova.new
overload :pippo, :pippo_2, :par_length => ‘==2’, :par_types => Fixnum
def pippo_2int(ciccio1, ciccio2)
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/

Il giorno ven, 16/06/2006 alle 10.32 -0700, gabriele renzi ha scritto:

— Paolo Donà [email protected] ha scritto:

si infatti è quello che ho scritto dopo “a meno di
ridefinire il metodo”. Però in questo modo hai un
costo di codice inutile, la documentazione non si può
aggiornare, perdi prestazioni, non hai la reflection
per sapere quali render esistono e sporchi il
namespace (potresti wrapparlo in una proc e mantenere
quest’ultimo pulito, però).

Il fatto è che io lo so che ho torto :frowning:
Sembra che la maggior parte delle persone ami il
consolidamento di molti metodo in uno solo, quindi
concordo che è questione di mentalità . Temo dipenda
dal fatto che ho i capelli ricci.

Il consolidare un metodo in uno solo può essere la soluzione migliore
nell’ottica di un DSL. Ma se questo significa un fottio di switch,
allora qualcuno merita di essere messo al muro quando verrà la
rivoluzione.

Giovanni

— Ripley [email protected] ha scritto:

non direi, gli argomenti opzionali, che sono la
cosa
che hai appena descritto, sono utilissimi :slight_smile:

sono daccordo :slight_smile:
intendevo dire (e mi sono espresso male) l’utilita’
di inserirlo nella sintassi del linguaggio.

no quello che intendevo
è:
def foo(a,b=1,c=2)

end

in moltissimi casi ho visto usare l’overloading per
offire valori di default. Scusa se ho impiegato un’ora
per spiegarmi :frowning:

C’è una differenza grossa tra quel che hai fatto e
quel che sarebbe overloading in java/c++: il tipo
analizzato è dinamico e non statico. Nel momento
in
cui utilizzi il tipo dinamico per cercare il
metodo
corretto sei arrivato al multiple dispatch (che io
adoro) ma che in ruby non c’è nativamente.

potresti dettagliare meglio cosa intendi?

eh, potrei provarci, ma è molto meglio se provi a
leggere questa pagina[1] e le collegate.

Ho gia’ sperimentato diverse volte come le abitudini
ereditate
dagli altri linguaggi che ho usato o uso mi portino
a scrivere
del codice non propriamente ruby :frowning:

Credo faccia parte della fase di apprendimento :slight_smile:
e quando scopro come andrebbero realmente fatte le
cose in ruby rimango
sempre piacevolmente sorpreso.

amen, ma mi è capitato anche il contrario (trovare una
cosa da fare più semplice in altro che in ruby). Ah,
che bella cosa l’apprendimento :slight_smile:

[1] http://c2.com/cgi/wiki?MultipleDispatch


icq: #69488917
blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info

Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

On 6/16/06, Giovanni C. [email protected] wrote:

Il consolidare un metodo in uno solo può essere la soluzione migliore
nell’ottica di un DSL. Ma se questo significa un fottio di switch,
allora qualcuno merita di essere messo al muro quando verrà la
rivoluzione.

Non prendetevela con me! il colpevole si chiama David Heinemeier
Hanssonhttp://www.loudthinking.com/about.htmle va in giro a dire che
tutti se ne devono andare
affanculo http://www.flickr.com/images/spaceball.gif :-D. Hahhaha
wasn’t
me

scusate intendevo
affanculohttp://www.flickr.com/photos/eugevon/130610241/

Per un altro approcio ancora piuevoluto/interessante rispetto all'overloading, il 'pattern matching' di linguaggi come Erlang e da
guardare:

http://tamale.net/erlang/tutorial.html

http://www-128.ibm.com/developerworks/java/library/j-cb04186.html

dove citano come esempio:

fib(1) -> 1;
fib(2) -> 1;
fib(X) -> fib(X-1) + fib(X-2).

Puoi farlo anche con liste. Per certi tipi di programmi, e` molto
carino.


David N. Welton

Linux, Open Source Consulting

— chiaro scuro [email protected] ha scritto:

ho dato una scorsa velocissima, ma ho visto un
articolo attinente che credo
ti possa interessare…

http://www.artima.com/rubycs/articles/patterns_sexp_dsls.html

è un articolo interessante, e tra l’altro l’autore è
quello che a scritto una delle librerie che
consigliavo prima.
Però è impreciso, per approfondimenti:
http://lambda-the-ultimate.org/node/1509


icq: #69488917
blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info

Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

On Fri, 16 Jun 2006 21:53:32 +0200, Paolo Donà wrote:

scusate intendevo affanculohttp://www.flickr.com/photos/eugevon/130610241/

Standing ovation :))

On Fri, 16 Jun 2006 18:32:05 +0200, Paolo Donà wrote:

Nel senso che in rails ci sono già tanti metodi, e aggiungerne altri forse
potrebbe generare confusione. Aggiungere invece un’opzione ad un metodo
esistente da la sensazione di tenere la libreria ‘compatta’ e ti fa sentire
un pò più a tuo agio come utilizzatore, nel senso che ti pare di avere tutto
sotto controllo.

Credo che avere diversi metodi render_text etc etc non sia bellissimo
da vedere (per dirla brutalmente è più figo come hanno fatto, sembra
più “magico” e anche molto comodo). Ciononostante le obiezioni di
Gabriele hanno senso.
Effettivamente fare tutti gli aliasing è una soluzione molto “hackish”.
Voglio dire, posso aggiungerla per un mio progetto, ma è qualcosa di
infattibile per una libreria. Nel senso che un’altra libreria dovrebbe
rifare l’hack e così via, e non so quanto tutte ste indirezioni su
quello che potrebbe essere il metodo più chiamato di Rails non
impattino “gratis” sulla performance.

Io con il senno del poi avrei fatto una soluzione ad oggetti. Un
oggetto (eventualmente factory) Render che dentro se la spupazza lui.
Maggiori dettagli non saprei darli… Tenendo conto del dinamismo di
Ruby sarebbe possibile fare un oggetto

Renderer.render :text, ‘ciao’

che prende il primo argomento, e va a cercare dinamicamente la classe
TextRenderer di cui chiama render con altri parametri. Piccola
violazione all’OC-principle, scavalcata facilmente tenendo conto del
dinamismo di Ruby.
A questo punto basterebbe creare una classe YamlRenderer che
Render.render :yaml funzionerebbe correttamente.

Addirittura forse Render potrebbe essere un modulo e quindi
reintrodurre render e basta che sotto il cofano funziona in tal modo.
Questo solo un po’ di brainstorming.

o se non vogliamo tirarci dietro gli oggetti (sempre per ragioni di
performance) immagino che non dovrebbe essere un problema avere il
modulo Renderer che contiene “render” che automaticamente dispatcha il
tutto ai vari metodi render_text e compagnia, con il meccanismo
automatico di cui sopra.

A questo punto per estendere render basterebbe aggiungere i metodi
opportuni al modulo.

Tuttavia mi sembrano soluzioni talmente banali che se non le hanno
adottate avranno avuto i loro buoni motivi.

Già che ci sono… c’è modo di fare renderizzare un rjs tramite render?
Ho già il codice in tale rjs e non vorrei passare a

render :update do |p|
bla bla
end

On Sat, 17 Jun 2006 13:57:42 +0200, David W. wrote:

Puoi farlo anche con liste. Per certi tipi di programmi, e` molto carino.

Vero. [ Haskell ]

quicksort :: Ord a => [a] -> [a]

quicksort [] = []
quicksort (pivot:tail) = quicksort [y | y <- tail, y < pivot]
++ [pivot]
++ quicksort [y | y <- tail, y >= pivot]

Ma anche e soprattutto (Prolog):

quicksort([], []).
[ SNIP ] (non è tanto interessante :)) )
partition(Pivot, Tail, Smaller, Greater).

Ora lasciando stare la versione in Prolog e passando a quella in Ruby

def qsort(list)
return [] if list.empty?

qsort( list.select {|a| a < list[0]} ) +
list.select {|a| a == list[0]} +
qsort( list.select {|a| a > list[0]} )
end

in pratica l’unica vera differenza è che Ruby usa un if all’inizio. E
se avesse il pattern-matching sono d’accordo, sarebbe estremamente più
figo. Peccato che non mi vengono in mente sintassi a sboccio… il
metodo “classico” non funzionerebbe perchè sarebbe molto difficile non
andare fra i denti della ridefinizione di metodo

def qsort([])
[]
end

def qsort(list)
return [] if list.empty?

qsort( list.select {|a| a < list[0]} ) +
list.select {|a| a == list[0]} +
qsort( list.select {|a| a > list[0]} )
end

Immagino che il meglio che si potrebbe fare sarebbe un:

func qsort, [] { [] }
func qsort do | list |
qsort( list.select {|a| a < list[0]} ) +
list.select {|a| a == list[0]} +
qsort( list.select {|a| a > list[0]} )
end

quasi quasi ci lavoro sopra. Temo comunque che le performances
sarebbero teribbili.

On Jun 16, 2006, at 6:14 PM, gabriele renzi wrote:

render :text => ‘mytext’
render :file => File.new(…)

scrivere questo è più lungo che scrivere
render_text ‘mytext’
render_file File.new

Beh, ci sara’ un motivo per cui inizialmente esistevano i
singoli metodi e poi a un certo punto hanno deciso di
consolidarli in uno solo…

Inoltre, rende sostanzialmente impossibile aggiungere
un nuovo elemento alla scelta. Mentre se ci fossero
normali metodi potrei aggiungere il mio
render_yaml obj.to_yaml

Scusa ma qui non ti seguo (diciamo che l’esempio scelto non
e’ proprio dei piu’ felici…). Cosa dovrebbe fare
“render_yaml”? Ricordati che stai parlando di uno dei metodi
fondamentali (e uno dei piu’ invocati) di un framework.
Un framework non si estende genericamente facendo l’override dei metodi
ma sfruttando i meccanismi che esso stesso ti mette a disposizione (che
in alcuni casi possono coincidere con l’override dei metodi - ma
“render” non rientra tra questi). Il metodo giusto per estender
“render” e’ di integrare il tuo sistema di template (come si fa con
Liquid, Radius,
Amrita etc.)
Oltretutto, cosa ti impedisce di aggiungere a ActionController::Base il
tuo metodo “render_yaml” e poi chiamarlo dai tuoi controller? Questo
e’ il punto che piu’ mi sfugge del tuo scazzo :slight_smile:

def ActionController::Base.render_yaml(object)
render :text => “

#{ object.to_yaml }

end

Infine, mette insieme un pacco di funzionalità
separate, con effetti deleteri sulla pulizia
concettuale e sulla documentazione, che invece di
avere due righe per ogni metodo ne ha duecento per uno
solo.

A me sembra che la documentazione di render sia piu’ chiara
oggi che in passato, proprio perche’ tutte le opzioni sono
riunite insieme.

E #render non è nemmeno pessimo… ma cavolo capire ad
occhio la differenza tra

Model.find(1,2,3)
Model.find([1,2,3])

Uguali :slight_smile:

Model.find(1) e Model.find([1]) è
una follia.

Beh, mi pare molto semplice (e pure intuitivo): se gli chiedi di
trovare UN record, ti
ritorna un record; se gli chiedi di trovare un elenco di record, ti
ritorna un elenco di record.
Io con Rails ci lavoro quasi tutti i giorni (negli altri purtroppo mi
tocca PHP) e devo dire
che “fila” come poche cose al mondo.


Stefano C.
[email protected]

On Jun 23, 2006, at 12:27 PM, Enrico F. wrote:

render in se e per se viola l’OCP. Questo mi pare abbastanza evidente.

OCP = ?
Per caso ti riferisci all’Open-Closed Principle?

Il fatto che poi ci si possa girare attorno, non significhi che ci sia
la violazione. E non mi sembra improbabile ritenere che sia un metodo
che uno possa volere estendere.

Beh, io lo ritengo non solo molto improbabile ma pure parecchio
indesiderabile. Un framework
non e’ una libreria: solo perche’ in teoria qualsiasi metodo si puo’
estendere non vuol
dire che sia la cosa giusta da fare. Se Rails fosse scritto in Java
molto probabilmente
“render” sarebbe dichiarato final: obietteresti anche in questo caso?
Ma le chiacchere stanno a zero: qualcuno e’ in grado di produrre una
caso realistico
in cui la soluzione migliore a un problema richiede di estendere
il metodo
“render”? Cosi’ poi appoggiamo la discussione su qualcosa di concreto
e non sulla teoria :slight_smile:

Ok. Diciamo che Ruby rende facilissimo fare collassare i concetti.
Diciamo che più uno vede “magic” (imho) e più gli viene il dubbio che
una cosa sia non necessariamente figa.

Non sono sicuro di aver capito… sul fatto che Ruby renda facilissimo
“collassare” i concetti, ovvero che renda possibile scrivere codice per
gli esseri umani piu’ che per i compilatori, non ci piove, ma e’ proprio
per questo che Rails e’ cosi’ figo :slight_smile:


Stefano C.
[email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs