Fermare la ricorsione

[cerza]

Mi serve comunque impostare la variabile a true perché globale, ma se metto return dopo il verify non esce dal metodo se non dopo che ha eseguito tutti i nodi non ancora esaminati.

[andbin]

Mi serve comunque impostare la variabile a true perché globale, ma se metto return dopo il verify non esce dal metodo se non dopo che ha eseguito tutti i nodi non ancora esaminati.

Ah beh, aspetta ... avevo capito male io. Se metti un return, l'unica cosa certa è che in quella invocazione di treeSplit2 in cui sei non fai altri cicli e quindi non scendi sicuramente più "sotto" ricorsivamente. Ma questo NON blocca di per sé invocazioni ricorsive fatte dai livelli più "alti".

Usare una variabile "globale" ... uhm, non è molto bello, detto in generale .... Io ti suggerirei di sfruttare un valore di ritorno boolean, visto che ora come ora non restituisci nulla.

[cerza]

Grazie per la risposta!

Ah beh, aspetta ... avevo capito male io. Se metti un return, l'unica cosa certa è che in quella invocazione di treeSplit2 in cui sei non fai altri cicli e quindi non scendi sicuramente più "sotto" ricorsivamente. Ma questo NON blocca di per sé invocazioni ricorsive fatte dai livelli più "alti".

Per cui le invocazioni ricorsive fatte dai livelli più alti non possono essere in alcun modo fermate, giusto?

Usare una variabile "globale" ... uhm, non è molto bello, detto in generale .... Io ti suggerirei di sfruttare un valore di ritorno boolean, visto che ora come ora non restituisci nulla.

Ma alla fine se mettessi una variabile locale e modificassi il tipo di ritorno del metodo non è la stessa cosa? quale la scelta migliore?
Grazie ancora, aspetto un tuo consiglio.

[andbin]

Per cui le invocazioni ricorsive fatte dai livelli più alti non possono essere in alcun modo fermate, giusto?

Certo che si può, basta far ritornare dal livello più "basso" una indicazione (es. false = ferma tutto), che il metodo dovrà ovviamente testare e quindi potrà fare subito un return false, il livello ancora più alto vedrà false e ritornerà false, ecc...
È così che si può (e si dovrebbe) ragionare.

Adesso, quando invochi ricorsivamente treeSplit2(collectionSet, string) non testi nulla.

Ma alla fine se mettessi una variabile locale e modificassi il tipo di ritorno del metodo non è la stessa cosa? quale la scelta migliore?

Non ho capito cosa c'entra una variabile locale .... ogni invocazione di un metodo ha il suo stack frame, le sue variabili locali.
Non puoi far "comunicare" due invocazioni di metodi (anche se fosse lo stesso metodo) solo di per sé con una variabile locale ..... a meno che tenga il riferimento ad un oggetto "condiviso" che ha stato mutabile. Ma dimentica questo pezzetto ...

[cerza]

Grazie per la pazienza

Adesso, quando invochi ricorsivamente treeSplit2(collectionSet, string) non testi nulla.

Allora nel while ho messo il controllo sulla valore della variabile verify, non basta? devo dichiarare un'altra variabile oltre a quella booleana "verify"?

Non ho capito cosa c'entra una variabile locale .... ogni invocazione di un metodo ha il suo stack frame, le sue variabili locali.
Non puoi far "comunicare" due invocazioni di metodi (anche se fosse lo stesso metodo) solo di per s� con una variabile locale ..... a meno che tenga il riferimento ad un oggetto "condiviso" che ha stato mutabile. Ma dimentica questo pezzetto ...

Mi riferivo a quanto scritto nel post precedente in cui mi suggerivi che le variabili globali non erano proprio il top della programmazione