C# for Rhino

… Per le liste.
Per altri tipi di oggetti ci sono altri modi.

Quelli sono i dati personali di ogni oggetto di quella classe, diversi per ogni oggetto.
Si scrivono dentro la classe proprio per indicare che gli oggetti di quella classe avranno ognuno un valore cognome, un valore nome e un valore eta.

Se li scrivi fuori dalla classe, come facciamo a capire che appartengono a quella classe ?

C’e’ un motivo per cui vorresti scriverli altrove ?

2 Mi Piace

e che in uno dei videi visti, (se non ricordare male) alcune cose del codice venivano scritte nelle classi esterne, altre invece anche all’interno della classe del void main, quindi avevo provato ma con errore.

forse si trattava di qualcos’altro, magari qualche settaggio. (era per capire quanti modi ci fossero per ciò)

Non mi ricordavo … ho guardato la documentazione.
Quei 3 valori sono chiamati campi o fields in inglese.
E come abbiamo detto sono come delle variabili private di ogni oggetto di quella classe.

Suppongo che il corso che segui ne parli, e suppongo che li chiami campi:confused: :wink:

EDIT:

Altra cosa:

E’ meglio dire “nel Main”
void indica solo che quel metodo non restituisce nessun valore.

1 Mi Piace

infatti la seconda volta sono stato più preciso:

:wink:

si avevo seguito anche quella parte dove parla dei fields (campi)
ma come mai le chiami variabili private. . . mettendo public possono essere richiamate da tutte le classi?

Volevo dire che sono valori che appartengono a quell’oggetto.
Sono relativi all’oggetto, non sono variabili ‘normali’ come quelle che ad esempio dichiari in un metodo.

Per quanto riguarda public hai ragione, significa che sono utilizzabili direttamente anche da metodi di altre classi.

A proposito di campi private, public ecc. … Se ci fai caso, nella documentazione di RhinoCommon, nelle classi non compare nessun campo.
Suppongo significhi che quei campi non sono public .
In ogni caso ai fini pratici non lo sono. :slight_smile:

che sono personali (interni) ok

:thinking: :thinking:

In ogni caso ai fini pratici non lo sono. però intendi che sembrano esserlo?

Non so se i campi nelle classi di RhinoCommon sono public o meno, e in fondo non mi interessa nemmeno. :slight_smile:

Per quanto ne so, RhinoCommon si basa sulle librerie C++ di McNeel, come OpneNurbs, quindi certe classi C# potrebbero anche richiamare direttamente metodi e proprieta’ delle librerie C++, senza avere campi proprii … non ho proprio idea, sono solo ipotesi da ignorante in materia. :confused:

La documentazione di RhinoCommon che utilizziamo e’ generata automaticamente dal codice C#, quindi se non ci mostra nessun campo, forse e’ perche’ i campi non sono public, o forse perche’ e’ stata settata per non mostrare i campi … di nuovo non ne ho la minima idea. :confused:

In ogni caso quello che interessa a noi che utilizziamo RhinoCommon e’ che non abbiamo dei campi a disposizione. Dobbiamo usare metodi e proprieta’ … bene, una cosa in meno da verificare …
:grinning: :wink: :smile:

1 Mi Piace

public class TimePeriod
{
private double _seconds;

public double Hours
{
    get { return _seconds / 3600; }
    set
    {
        if (value < 0 || value > 24)
            throw new ArgumentOutOfRangeException(nameof(value),
                  "The valid range is between 0 and 24.");

        _seconds = value * 3600;
    }
}

}

Ti porto un esempio per capire il perché i campi è bene che restino privati:

In questo modo si evita di scoprire un nervo.
Lasciando privato il campo ti puoi permettere di prendere un dato sporco che arriva dall esterno ed effettuare una serie di operazioni per ripulirlo, controllarlo, modificarlo e poi salvarlo nel campo sicuro che contenga il dato corretto e voluto. Nel caso sopra, dall’esterno mi si passa un tempo in ore tramite una proprietà, ma a me serve in secondi e in quel modo non mi serve a nulla. Allora prima di salvarlo lo converto assicurandomi che il valore sia entro il range 0-24.

1 Mi Piace

Grazie Luca !

Se non sbaglio qui si tratta di encapsulation
Dal famoso mantra della OOP inheritance encapsulation polymorphism :slight_smile:
… Forse … :neutral_face:

1 Mi Piace

Si, o [information hiding](C# - Classi e oggetti: definizioni - Pagina personale di Carlo Vecchio)

1 Mi Piace

per questo tempo fa ebbi dei dubbi sul fatto di iniziare ad imparare C#
confrontando la differenza tra la documentazione di questo linguaggio
e altri tipo “Rstudio” del link postato da Luca si comprende la vastità
del primo, e sono sicuro che in quella documentazione viene riportata
una parte “forse anche piccola” dell’intero potenziale di C#

ma credo che alla fine bisogna imparare (anche di volta in volta)
quello che serve in quel momento, è inutile impararne 10
se poi ne userai 3, 2 chissà quando ed il resto mai.

Conoscere un linguaggio è come conoscere una lingua, ci vuole tempo per impararne una bene. Meglio ormai focalizzarsi sull obiettivo e cercare solo ciò che serve.

infatti oggi i linguaggi di programmazione non sono più come un tempo
prima i comandi/metodi/funzioni erano quelli li imparavi tutti e da li eri tu che creavi
adesso invece un linguaggio di programmazione non’é solo una lingua ma è tutto un mondo
e sopratutto in continua evoluzione, non si ha il tempo di imparare l’ultima versione, che già è
uscita quella nuova con altri migliaia di novità e così via, diventa un inseguire di una chimera. . .

Dai, non esagerare ! …
:wink: :smile:

:smile: :smile:

Emilio, non so se ho esagerato. . .

https://developer.rhino3d.com/api/RhinoCommon/html/R_Project_RhinoCommon.htm

però dal link per RhinoCommon non ho mai aperto tutti, ma ogni volta che apro una tendina
in una classe/metodo ne escono altre in gran quantità con altre tendine. . .

Salvio, parlavi di linguaggi.
Le librerie che usi con il linguaggio sono una cosa diversa.
E non credo nemmeno che un aggiornamento di RhinoCommon contenga migliaia di novita’.
O no ? … :grinning:

potrei dire “mi fido”, ma ho constatato che in genere quando metti il punto di domanda è una certezza :wink:

Hahahahaha :smile:

Lascia stare la fiducia, cerchiamo di ragionare su quanto sappiamo.
Fidarsi e’ una bella cosa, ma capire di solito e’ meglio.

A quanto vedo, pare che l’ultimo aggiornamento di RhinoCommon, nel 2018, contenga una modifica su due classi, per la precisione cambia la classe da cui sono derivate, e resta da vedere se questo abbia effetti pratici per chi utilizza RhinoCommon …

Rhino - What’s New? (rhino3d.com)

Se apri la tendina della classe, ovviamente vedi cosa e’ contenuto nella classe, cioe’ proprieta’, metodi e forse altro

image

Ma se apri un metodo vedi al massimo l’elenco degli overload, senza nessuna tendina interna.

image

E se quel metodo non ha overload, non puoi aprire la tendina, non c’e’ nessuna tendina … :wink:
Vedi ad esempio qui CreateArcBlend

image

Ti aspettavi qualcosa di diverso ? :slight_smile:

di divertso no, ma credevo che la guida attuale fosse la somma di tutti gli aggiornamenti
ma a quanto pare dal 2018, da come hai riportato è cambiato ben poco. . .

considerando ciò, a questo punto anche la guida di C# dovrebbe seguire la stessa logica, infatti se si va a vedere nei tutorial di FCamuso gli aggiornamento tra 8e9 e 9e10 ci sono 6 videi il primo e un video l’ultimo.

quindi tutto ciò conferma ciò che hai detto :+1:

1 Mi Piace