Forum: Italian Ruby user group evitare acesso classe nested

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
C7126eaf62118bb5f1d04f7f419f7896?d=identicon&s=25 [L]ash (Guest)
on 2007-06-04 23:14
(Received via mailing list)
ho una classe

class A
  class B
  end
end

volendo evitare che si possa fare
a = A::B.new

ho aggiunto la direttiva private
class A
  private
  class B
  end
end

ma a = A::B.new continua ad essere valido.

come faccio a renderlo inaccessibile??

mi scuso se la domanda è banale o mal posta ma è da poco che mi sono
avvicinato a ruby :)

Grazie
652a08873b41cf44e456b54927c097a5?d=identicon&s=25 Giovanni Corriga (Guest)
on 2007-06-05 09:12
(Received via mailing list)
Il giorno lun, 04/06/2007 alle 22.58 +0200, [L]ash ha scritto:
> ho aggiunto la direttiva private
> mi scuso se la domanda è banale o mal posta ma è da poco che mi sono
> avvicinato a ruby :)

Non ho neanche idea se si possa rendere una classe privata; non mi è mai
capitata la necessità di farlo. Sei sicuro che rendere la classe privata
sia la soluzione migliore al problema che vuoi risolvere? Cosa vuoi
ottenere rendendola privata?

  Giovanni
Aea9ee14e387a68f5cd63048a0ba9266?d=identicon&s=25 David Palm (Guest)
on 2007-06-05 10:44
(Received via mailing list)
Non ne ho mai avuto bisogno, ma potresti forse provare a fare:

class A
    class B
    private
        def initialize
        end
        def metodo1
        end
        def metodo2
        end
    end
end

Così avresti tutti i *metodi* di B privati, e anche se B stessa non è
privata il risultato pratico è uguale (o quanto meno molto simile).
Sinceramente non so cosa succede se hai 'initialize' come private e
cerchi di creare un'istanza di B...
C7126eaf62118bb5f1d04f7f419f7896?d=identicon&s=25 [L]ash (Guest)
on 2007-06-05 13:15
(Received via mailing list)
Il giorno Tue, 05 Jun 2007 08:52:14 +0200
Giovanni Corriga <giovanni@corriga.net> ha scritto:

> Cosa vuoi ottenere rendendola privata?

semplice incapsulazione.

Ciao
C7126eaf62118bb5f1d04f7f419f7896?d=identicon&s=25 [L]ash (Guest)
on 2007-06-05 13:24
(Received via mailing list)
Il giorno Tue, 05 Jun 2007 10:26:21 +0200
David Palm <david.palm@iperbole.bologna.it> ha scritto:

>         end
>     end
> end
>

solo che se è tutto privato è poco utile :)
c'è una notazione simile al C++ in modo da poter dichiarare A friend di
B ?

Ciao
D8fb06dfc08a477ecb0a76ffdbff3475?d=identicon&s=25 Chiaro Scuro (chiaroscuro)
on 2007-06-05 13:35
(Received via mailing list)
On 6/5/07, [L]ash <lash@semailer.com> wrote:
>
> Il giorno Tue, 05 Jun 2007 08:52:14 +0200
> Giovanni Corriga <giovanni@corriga.net> ha scritto:
>
> > Cosa vuoi ottenere rendendola privata?
>
> semplice incapsulazione.
>
>
mi chiedo.. in un linguaggio così basato sulle convenzioni come ruby,
possiamo ancora pensare all'encapsulation alla vecchia maniera? vi siete
mai
ritrovati a chiedervelo?
C7126eaf62118bb5f1d04f7f419f7896?d=identicon&s=25 [L]ash (Guest)
on 2007-06-05 14:05
(Received via mailing list)
Il giorno Tue, 5 Jun 2007 13:20:37 +0200
"chiaro scuro" <kiaroskuro@gmail.com> ha scritto:

> mi chiedo.. in un linguaggio così basato sulle convenzioni come ruby,
> possiamo ancora pensare all'encapsulation alla vecchia maniera? vi
> siete mai ritrovati a chiedervelo?

non vedo come possano centrare le convenzioni con l'incapsulamento,
sarà che sono nuovo al ruby e mi sfugge qualcosa

Ciao
652a08873b41cf44e456b54927c097a5?d=identicon&s=25 Giovanni Corriga (Guest)
on 2007-06-05 15:10
(Received via mailing list)
Il giorno mar, 05/06/2007 alle 13.20 +0200, chiaro scuro ha scritto:
> mi chiedo.. in un linguaggio così basato sulle convenzioni come ruby,
> possiamo ancora pensare all'encapsulation alla vecchia maniera? vi siete mai
> ritrovati a chiedervelo?

Scusa, quale sarebbe l'incapsulamento alla vecchia maniera?

  Giovanni
D8fb06dfc08a477ecb0a76ffdbff3475?d=identicon&s=25 Chiaro Scuro (chiaroscuro)
on 2007-06-05 15:51
(Received via mailing list)
On 6/5/07, Giovanni Corriga <giovanni@corriga.net> wrote:
>
non mi sono spiegato bene. volevo dire.. con Ruby sei così libero che ogni
encapsulation è in realtà farlocca, quindi anche un private diventa più
un
suggerimento al programmatore dell'intento del coder originario che
qualcosa
che viene forzato.
C7126eaf62118bb5f1d04f7f419f7896?d=identicon&s=25 [L]ash (Guest)
on 2007-06-05 17:38
(Received via mailing list)
Il giorno Tue, 5 Jun 2007 15:32:28 +0200
"chiaro scuro" <kiaroskuro@gmail.com> ha scritto:

> non mi sono spiegato bene. volevo dire.. con Ruby sei così libero che
> ogni encapsulation è in realtà farlocca, quindi anche un private
> diventa più un suggerimento al programmatore dell'intento del coder
> originario che qualcosa che viene forzato.

credo che una buona incapsulazione deve essere fatta a priscindere dal
linguaggio e se questa possa essere mantenuta tale o se il clinet
puo accedervi. L'incapsulazione permette di "nascondere" al client
aspetti che non gli devono interessare e che a cui possibilmente non
deve neanche accedere in quanto dettagli implementativi
dell'interfaccia che sta usando. Se un programmatore usa delle funzioni
marcate come private sicuramente non sta facendo un buon lavoro in
quanto quel codice può essere sottoposto a modifiche senza che gli sia
detto rendendo il suo codice del tutto inutilizzabile (queste
funzioni fanno parte dei dettagli implementativi che non gli devono
interessare); mentre invece l'interfaccia (parte public) viene mantenuta
il più possibile inalterata o cmq viene specificato ad ogni rilascio
quali modifiche sono state apportate alle interfacce pubbliche


Ciao
D8fb06dfc08a477ecb0a76ffdbff3475?d=identicon&s=25 Chiaro Scuro (chiaroscuro)
on 2007-06-05 18:10
(Received via mailing list)
On 6/5/07, [L]ash <lash@semailer.com> wrote:
> linguaggio e se questa possa essere mantenuta tale o se il clinet
> puo accedervi. L'incapsulazione permette di "nascondere" al client
> aspetti che non gli devono interessare e che a cui possibilmente non
>

certo, concordo con te. sottolineavo solo che in ruby l'encapsulation
è più
un accordo amichevole che una regola che viene forzata.
per dirla tutta, se dovessi scrivere #private come commento invece di
private come istruzione mi andrebbe *quasi* bene uguale.
Aea9ee14e387a68f5cd63048a0ba9266?d=identicon&s=25 David Palm (Guest)
on 2007-06-05 23:31
(Received via mailing list)
Ok, abbiamo capito - direi - tutti il concetto e l'utilità
dell'encapsulation, ma mi sfugge un attimo il tuo punto (e sono davvero
interessato a capirne di più! non sto facendo retorica!). Non so se si
possa rendere una classe private in Ruby, ma direi di no. Ok. Ma se
fosse possibile, cosa guadagneresti in termini pratici, nel tuo caso
specifico? Mi puoi aiutare a capire meglio dove sta il rischio che uno
corre scrivendo codice con i soli meccanismi di encapsulation di Ruby?

:-)
652a08873b41cf44e456b54927c097a5?d=identicon&s=25 Giovanni Corriga (Guest)
on 2007-06-06 10:38
(Received via mailing list)
Il giorno mar, 05/06/2007 alle 15.32 +0200, chiaro scuro ha scritto:
> > > > semplice incapsulazione.
> >
>
> non mi sono spiegato bene. volevo dire.. con Ruby sei così libero che ogni
> encapsulation è in realtà farlocca, quindi anche un private diventa più un
> suggerimento al programmatore dell'intento del coder originario che qualcosa
> che viene forzato.

Un attimo: "incapsulamento" è il fatto che lo stato dell'oggetto e la
sua organizzazione interna siano locali e privati dell'oggetto stesso, e
che solo esso possa modificarli. Per ottenere una modifica dello stato
dell'oggetto occorre mandargli dei messaggi che rispettino il protocollo
dell'oggetto stesso.

Da questo punto di vista, l'incapsulamento offerto di default da Ruby
(ovvero che le variabili di istanza non possano che essere private) sta
un gradino sopra rispetto a quello offerto da Java o anche da Python.

Per questo la richiesta di [L]ash di creare una classe privata ad
un'altra classe mi sembra strana: se lo stato dell'oggetto è già
privato, racchiuderlo in un'altra struttura che dovrebbe essere comunque
proprietà privata dell'oggetto stesso mi sembra quantomeno inutile.

Quello di cui parli tu è una cosa diversa, ovvero il controllo di
accesso dei metodi.

  Giovanni
Aea9ee14e387a68f5cd63048a0ba9266?d=identicon&s=25 David Palm (Guest)
on 2007-06-06 10:44
(Received via mailing list)
Ok. Questo risponde alcune domande. Grazie!

:-)

So, [L]ash, ci dici un po' delle tue perplessità/esigenze? Perché una
classe privata dentro un'altra?
C7126eaf62118bb5f1d04f7f419f7896?d=identicon&s=25 [L]ash (Guest)
on 2007-06-06 14:16
(Received via mailing list)
Il giorno Wed, 06 Jun 2007 10:43:44 +0200
David Palm <david.palm@iperbole.bologna.it> ha scritto:

> So, [L]ash, ci dici un po' delle tue perplessità/esigenze? Perché una
> classe privata dentro un'altra?

perchè, nel mio caso, B è una classe ausiliaria di A che serve solo e
soltanto nei dettagli implementativi di A e non viene passata all
esterno di essa; quindi mi viene naturale porla all interno di A.
Il fatto che si possa istanziare una variabile di quella classe non crea
particolari problemi in se (potrebbe farlo se fosse una classe
singleton) ma mi da fastidio che sia possibile accedere ai dettagli.
C01072ccffb1f2d23f8b5f686e5b106a?d=identicon&s=25 gabriele renzi (Guest)
on 2007-06-06 15:39
(Received via mailing list)
--- "[L]ash" <lash@semailer.com> wrote:


> Il fatto che si possa istanziare una variabile di
> quella classe non crea
> particolari problemi in se (potrebbe farlo se fosse
> una classe
> singleton) ma mi da fastidio che sia possibile
> accedere ai dettagli.

e' una cosa abbastanza comune per chi passa a
ruby/python da java/c++ in genere, preoccuparsi della
visibilità.
In generale in ruby è possibile accedere a _tutto_
tramite reflection, quindi pui solo rendere la cosa
meno ovvia.
Nel tuo caso il trucco c'è: usa una variabile invece
di una costante:

@@Klasse = Class.new(SuperClasse) do
 def metodo... end
end

ma anche questo può essere scavalcato grazie alla
reflection.

In generale la soluzione migliore è semplicemente di
mettere un commento :nodoc: in modo da non documentare
l'esistenza della tua classe, e far capire a chi
guarda i sorgenti che quella classe è solo per uso interno.


      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try
it
now.
http://uk.answers.yahoo.com/
C7126eaf62118bb5f1d04f7f419f7896?d=identicon&s=25 [L]ash (Guest)
on 2007-06-06 20:31
(Received via mailing list)
Il giorno Wed, 6 Jun 2007 14:37:52 +0100 (BST)
gabriele renzi <surrender_it@yahoo.it> ha scritto:

> e' una cosa abbastanza comune per chi passa a
> ruby/python da java/c++ in genere, preoccuparsi della
> visibilità.

infatti vengo da c++ :)

Ciao
652a08873b41cf44e456b54927c097a5?d=identicon&s=25 Giovanni Corriga (Guest)
on 2007-06-07 09:34
(Received via mailing list)
Il giorno mer, 06/06/2007 alle 20.27 +0200, [L]ash ha scritto:
> Il giorno Wed, 6 Jun 2007 14:37:52 +0100 (BST)
> gabriele renzi <surrender_it@yahoo.it> ha scritto:
>
> > e' una cosa abbastanza comune per chi passa a
> > ruby/python da java/c++ in genere, preoccuparsi della
> > visibilità.
>
> infatti vengo da c++ :)

Ok, allora la prima cosa da fare per imparare Ruby è dimenticare tutto
quello che C++ ti ha insegnato nel campo della OOP.

  ;-)

    Giovanni
D8fb06dfc08a477ecb0a76ffdbff3475?d=identicon&s=25 Chiaro Scuro (chiaroscuro)
on 2007-06-07 09:40
(Received via mailing list)
On 6/7/07, Giovanni Corriga <giovanni@corriga.net> wrote:
>
> > infatti vengo da c++ :)
>
> Ok, allora la prima cosa da fare per imparare Ruby è dimenticare tutto
> quello che C++ ti ha insegnato nel campo della OOP.
>
>
esagerato :-)  in generale direi che l'atteggiamento ruby verso l'OOP
rispetto a C++
è:* tutto è un oggetto
* classes are cheap
* più che avere regole, ci si mette d'accordo
652a08873b41cf44e456b54927c097a5?d=identicon&s=25 Giovanni Corriga (Guest)
on 2007-06-07 10:01
(Received via mailing list)
Il giorno gio, 07/06/2007 alle 09.38 +0200, chiaro scuro ha scritto:
> On 6/7/07, Giovanni Corriga <giovanni@corriga.net> wrote:
> >
> > > infatti vengo da c++ :)
> >
> > Ok, allora la prima cosa da fare per imparare Ruby è dimenticare tutto
> > quello che C++ ti ha insegnato nel campo della OOP.
> >
> >
> esagerato :-)

"I invented the term 'Object-Oriented', and I can tell you I did not
have C++ in mind." --AlanKay

;-PPPP

> in generale direi che l'atteggiamento ruby verso l'OOP
> rispetto a C++ è:
> * tutto è un oggetto

e soprattutto gli oggetti interagiscono tramite _messaggi_ . Se c'è una
cosa da portare a casa dopo aver incontrato Ruby o Smalltalk, è
l'interazione tramite messaggi.

  Giovanni
This topic is locked and can not be replied to.