[.NET] Perchè il goto è così usato?

[DioBrando]

Originariamente inviato da fek

Come sei tronfio

Originariamente inviato da cionci

Mamma mia non lo sopporto, mi provoca l'orticaria solo a guardarlo per sbaglio.

Ottima soluzione

razzisti

d'altra parte da uno giuentino e un interista non è che ci possa aspettare di meglio...



E alla faccia vostra mi sono iscritto alla PyCon2 magari ci saranno delle track proprio gaming-oriented...

Dai chi mi fa compagnia?

[cdimauro]

Originariamente inviato da fek

Figo, e io volevo solo una struttura
Adoro questo linguaggio.

Le struct non esistono (in realtà esistono, ma servono ad altro ): puoi creare una classe apposita che, tramite il costruttore, definisce gli attributi / variabili d'istanza che ti serve siano presenti; come suggeriva anche Marco.

Concettualmente è simile a quanto faresti con C++, C#, Java, ecc.

Comunque coi dizionari finora non ho mai avuto la necessità di crearmi una "struct", per cui la strada che hai intrapreso con quel pezzo di codice molto probabilmente è quella giusta.

Se ci dici esattamente a cosa ti serviva, ti possiamo dare una mano per risolvere il tuo problema.

x DioBrando: diavolo tentatore! Mi sa che finirò per cadere nella trappola.

[fek]

Originariamente inviato da ||ElChE||88

Quanto è complicato un generatore di shader?

Come per tutte le cose, sapendo quello che si sta facendo non e' complicatissimo. Il problema e' che fino a un paio di anni fa nessuno al mondo sapeva, di preciso, come scrivere un generatore di shader perche' era un problema nuovo

Dopo due anni di esperienza a lavorarci sopra posso tagliare qualche angolo, semplificare qui e la', fare qualche assunzione e, usando un linguaggio degno di questo nome, probabilmente si riesce a riscrivere quell'accozzaglia in maniera molto piu' semplice.

Originariamente inviato da marco.r

a ognuno il suo. Io trovo invece che sia il C# ad essere troppo complicato (soprattutto con le varie aggiunte fatte nel corso del tempo), fa' un po' tu

Ti capisco, d'altronde Python e' pseudocodice leggibile. Tipo questo:

def newStruct( name, *fields ):
    import new
    import compiler
    header = 'def constructor( self, %s ):\n  ' % ','.join( fields )
    body = '\n  '.join([ "self.%s = %s" % (x,x) for x in fields ])
    source = header + body
    exec source
    return new.classobj(name, () , {'__init__' : constructor} )

Si legge come fosse inglese

Originariamente inviato da cdimauro

Comunque coi dizionari finora non ho mai avuto la necessità di crearmi una "struct", per cui la strada che hai intrapreso con quel pezzo di codice molto probabilmente è quella giusta.

Cesare, perdere due giornate di lavoro per un errore di sintassi e trovarmi un altro errore come questo due settimane dopo il deploy impazzendo per capire di che cosa si tratta, non e' cio' che definisco intraprendere una strada giusta.

Comunque non ho scritto io quel codice. Io non scrivo in Python, ci ho solo dovuto mettere le mani... e non lo faccio piu'.

[cionci]

Originariamente inviato da cdimauro

Le struct non esistono (in realtà esistono, ma servono ad altro )

non fa una grinza

[cdimauro]

Originariamente inviato da fek

Come per tutte le cose, sapendo quello che si sta facendo non e' complicatissimo. Il problema e' che fino a un paio di anni fa nessuno al mondo sapeva, di preciso, come scrivere un generatore di shader perche' era un problema nuovo

Dopo due anni di esperienza a lavorarci sopra posso tagliare qualche angolo, semplificare qui e la', fare qualche assunzione e, usando un linguaggio degno di questo nome, probabilmente si riesce a riscrivere quell'accozzaglia in maniera molto piu' semplice.

Non è un problema di linguaggio questa volta.

Ti capisco, d'altronde Python e' pseudocodice leggibile. Tipo questo:

def newStruct( name, *fields ):
    import new
    import compiler
    header = 'def constructor( self, %s ):\n  ' % ','.join( fields )
    body = '\n  '.join([ "self.%s = %s" % (x,x) for x in fields ])
    source = header + body
    exec source
    return new.classobj(name, () , {'__init__' : constructor} )

Si legge come fosse inglese

E' una soluzione "universale" al problema di creare una struttura qualunque. Cosa non fattibile con altri linguaggi, comunque.

Per creare strutture "as usual":

class Punto:
  def __init__(self, x, y):
    self.x = x
    self.y = y

p = Punto(0, 0)
print p.x, p.y
p.x = 1
p.y = 2
print p.x, p.y

Cosa c'è di "illegibile" in questo?

Cesare, perdere due giornate di lavoro per un errore di sintassi e trovarmi un altro errore come questo due settimane dopo il deploy impazzendo per capire di che cosa si tratta, non e' cio' che definisco intraprendere una strada giusta.

Quest'errore l'avresti commesso anche in C#, col quale vorresti riscriverlo. Da qui http://support.microsoft.com/kb/309357 :

/Use the indexer of the Hashtable class to retrieve your objects. The indexer takes 
//Key as a parameter and accesses it with the Hashed location.

try
{
        MessageBox.Show(MyTable[Person1.Lname].ToString());
	MessageBox.Show(MyTable[Person2.Lname].ToString());
	MessageBox.Show(MyTable[Person3.Lname].ToString());
}
catch (NullReferenceException ex)
{
	MessageBox.Show("Key not in Hashtable");
	MessageBox.Show(ex.Message);

Prova a togliere il try/catch che intercetta l'eccezione (di chiave non presente): la situazione sarebbe esattamente la stessa del codice Python di cui ti lamenti.

Comunque non ho scritto io quel codice. Io non scrivo in Python, ci ho solo dovuto mettere le mani... e non lo faccio piu'.

Infatti il problema è proprio che non hai scritto tu quel codice, e chi l'ha fatto non mi sembra particolarmente ferrato con Python e, dopo tutti i disastri che finora hai riportato, nemmeno col testing del codice.

Originariamente inviato da cionci

non fa una grinza

Già, perché si usano per leggere (e scrivere) strutture di dati da file.

Python non ha bisogno del classico concetto di struct che si trova in C o in altri linguaggi: ci sono le classi oppure i dizionari per questo.

[fek]

Originariamente inviato da cdimauro

E' una soluzione "universale" al problema di creare una struttura qualunque. Cosa non fattibile con altri linguaggi, comunque.

Per fortuna in altri linguaggi non e' facile scrivere quegli orrori

Quest'errore l'avresti commesso anche in C#, col quale vorresti riscriverlo. Da qui http://support.microsoft.com/kb/309357 :

No Cesare, in C# userei qualcosa che mi fa' un bell'errore in fase di compilazione se commetto quella fesseria. Non scomodo certo una hash table.

Python non ha bisogno del classico concetto di struct che si trova in C o in altri linguaggi: ci sono le classi oppure i dizionari per questo.

E ci sono tanti linguaggio molto piu' robusti che mi fanno perdere meno tempo

[cdimauro]

Quindi il problema è la mancanza di costrutto struct-like del C? Voglio dire: in un linguaggio come il C# la soluzione al tuo problema sarebbe stata quella di usare una "struct"?

Rimane, comunque, il fatto che l'autore del codice non mi sembra particolarmente ferrato con Python e il testing in generale.

[fek]

Originariamente inviato da cdimauro

Quindi il problema è la mancanza di costrutto struct-like del C? Voglio dire: in un linguaggio come il C# la soluzione al tuo problema sarebbe stata quella di usare una "struct"?

Rimane, comunque, il fatto che l'autore del codice non mi sembra particolarmente ferrato con Python e il testing in generale.

Cesare, io ti dico "Per colpa di questo ho perso due giorni di lavoro che usando un altro linguaggio non avrei perso" e tu mi rispondi "L'autore non e' ferrato in Python". In pratica mi stai dicendo che se il programmatore non e' ferrato in Python, rischia di scrivere codice che fa perdere tantissimo tempo. La stessa cosa che accade in C, anzi, peggio

[cdimauro]

Mi sembra normale parlare di "ferratezza": un dizionario/hashtable è un oggetto che ha dei PRECISI requisiti d'utilizzo.

Se cerchi di accedere a un elemento inesistente Python solleva un'eccezione.

Se utilizzi un dizionario senza conoscere questo "dettaglio" non di poco conto oppure con leggerezza, commetti un errore, come quello che hai mostrato e che t'ha fatto perdere.

Ma è una cosa che capita con altri linguaggi appunto.

Tra l'altro i dizionari permettono di evitare il sollevamento dell'eccezione restituendo un valore di default.

In entrambi i casi, quindi, bisogna conoscere lo strumento. Ecco perché dico che bisogna essere ferrati.

Detto ciò, mi sembra di capire che per risolvere il tuo problema sarebbe bastato una struct.
Ne prendo atto, ma in Python lo si può fare:
- in maniera MOLTO simile (vedi l'esempio che t'ho fornito prima);
- coi dizionari, usandoli in maniera appropriata.

Questo senza considerare che una buona unittest avrebbe permesso di risalire al bug prima ancora di lanciare l'esecuzione dello script.

[fek]

Originariamente inviato da cdimauro

Mi sembra normale parlare di "ferratezza": un dizionario/hashtable è un oggetto che ha dei PRECISI requisiti d'utilizzo.

Se cerchi di accedere a un elemento inesistente Python solleva un'eccezione.

Se utilizzi un dizionario senza conoscere questo "dettaglio" non di poco conto oppure con leggerezza, commetti un errore, come quello che hai mostrato e che t'ha fatto perdere.

Ma io non voglio usare una hash table e non voglio conoscere quel dettaglio per qualcosa che puo' essere risolto in maniera molto piu' semplice con un linguaggio diverso.
Io qui non sto imparando un linguaggio, io qui sto finendo un gioco, e con una previsione di 1000/2000 bug da fissare da qui ai prossimi quattro mesi, francamente, con dettagli delle hash table di Python mi ci sciacquo
Se per ogni fix dovessi andarmi a studiare le sottigliezze del linguaggio per evitare di cadere nelle sue trappole, il gioco esce nel 2050.

Mi ha fatto perdere tempo che non avrei perso con un linguaggio migliore, e' l'unica cosa che mi interessa.

Ma è una cosa che capita con altri linguaggi appunto.

Questo no perche' in altri linguaggi ho a disposizione strumenti piu' robusti.

Questo senza considerare che una buona unittest avrebbe permesso di risalire al bug prima ancora di lanciare l'esecuzione dello script.

E se mia nonna aveva le ruote era un carretto, e se fossimo tutti piu' buoni non ci sarebbero guerre...
Non mi interessa quello che poteva essere, mi interessa quello che e' accaduto: due giorni persi perche' lo strumento che hanno scelto e' inadeguato grrrr.

[cdimauro]

Lo strumento giusto era questo:

class Punto:
  def __init__(self, x, y):
    self.x = x
    self.y = y

p = Punto(0, 0)
print p.x, p.y
p.x = 1
p.y = 2
print p.x, p.y

[fek]

Originariamente inviato da cdimauro

Lo strumento giusto era questo:

class Punto:
  def __init__(self, x, y):
    self.x = x
    self.y = y

p = Punto(0, 0)
print p.x, p.y
p.x = 1
p.y = 2
print p.x, p.y

Bene. Ora manda una mail al tipo di Python e digli che se sbaglio cosi' platealmente ad usare lo strumento giusto mi dovrebbe avvertire presto. Non due settimane dopo il deploy di quel codice

Anzi no, uso un linguaggio serio appena mi sono smazzato sti 2000 bug...

[cdimauro]

Fran, ma il codice l'hai scritto tu o qualche tuo collega? Nel primo caso sei giustificato: odi Python, e non hai mai mostrato interesse a impararlo.

Comunque il creatore di Python lavora per la "concorrenza" ( www.google.com ).

P.S. Se non ti piacciono i pitoni, puoi provare coi cobra.

[fek]

Originariamente inviato da cdimauro

Fran, ma il codice l'hai scritto tu o qualche tuo collega? Nel primo caso sei giustificato: odi Python, e non hai mai mostrato interesse a impararlo.

Io imparo qualunque cosa mi serva per andare prima a casa, non ho pregiudizi su nulla

Ricapitolo la storia:
- Qualcuno ha avuto l'imponente idea di usare Python per scrivere il nostro sistema di build degli asset
- Io ho avuto la sfortuna di dover aggiungere un flag per una risorsa
- Due righe di codice che ho dovuto aggiungere si sono trasformate nell'inferno che ti ho descritto

Tutto il lavoro avrebbe dovuto prender trenta o quaranta secondi al massimo, due settimane dopo sono ancora qui che debuggo... Anzi no, se lo sta debuggando quello che ha scelto Python ora... Ah l'ironia della sorte

[cionci]

Originariamente inviato da fek

Tutto il lavoro avrebbe dovuto prender trenta o quaranta secondi al massimo, due settimane dopo sono ancora qui che debuggo... Anzi no, se lo sta debuggando quello che ha scelto Python ora... Ah l'ironia della sorte

E che dice...per curiosità ? Sta cominciando a pensare di aver sbagliato scelta ?

[cdimauro]

Originariamente inviato da fek

Io imparo qualunque cosa mi serva per andare prima a casa, non ho pregiudizi su nulla

Ricapitolo la storia:
- Qualcuno ha avuto l'imponente idea di usare Python per scrivere il nostro sistema di build degli asset
- Io ho avuto la sfortuna di dover aggiungere un flag per una risorsa
- Due righe di codice che ho dovuto aggiungere si sono trasformate nell'inferno che ti ho descritto

Tutto il lavoro avrebbe dovuto prender trenta o quaranta secondi al massimo, due settimane dopo sono ancora qui che debuggo... Anzi no, se lo sta debuggando quello che ha scelto Python ora... Ah l'ironia della sorte

Visto? Hai appena dimostrato che dio esiste (ed è giusto, anzi: vendicativo )...

[DioBrando]

Originariamente inviato da cdimauro

Visto? Hai appena dimostrato che dio esiste (ed è giusto, anzi: vendicativo )...

cmq se uno "sperimenta" l'utilizzo del linguaggio per scrivere tutto il sistema di build di un progetto così imponente senza aver almeno testato prima se è quello che fa per lui o meno, non fa una mossa esattamente geniale.

A prescindere dallo strumento scelto.

[fek]

Originariamente inviato da cionci

E che dice...per curiosità ? Sta cominciando a pensare di aver sbagliato scelta ?

Cambiamo argomento

[fek]

Originariamente inviato da DioBrando

cmq se uno "sperimenta" l'utilizzo del linguaggio per scrivere tutto il sistema di build di un progetto così imponente senza aver almeno testato prima se è quello che fa per lui o meno, non fa una mossa esattamente geniale.

A prescindere dallo strumento scelto.

Cambiamo argomento

[mindwings]

Originariamente inviato da fek

Cambiamo argomento

si infatti fornisco l'input
http://www.st.cs.uni-sb.de/edu/semin...ocs/sweeny.pdf
cosa ne pensi dell'opinione di un tuo "collega"

In generale nel futuro utilizzeremo i linguaggi fuzionali