minioctt<p><strong>love2d stavolta che gira, nonostante la octo-oriented programming!</strong></p><p>Sorprendentemente, appena qualche ora di <em>sonno</em> e qualche ora di <em>scrittura magica un pochino avanti e indietro</em> più tardi, e <strong>ho effettivamente trovato una soluzione </strong><strong><a href="https://octospacc.altervista.org/2025/09/04/lamore-2d-e-gli-oggetti-orientifici-ma-quello-che-accade-non-fa-divertire/" rel="nofollow noopener" target="_blank">al </a></strong><strong><a href="https://octospacc.altervista.org/2025/09/04/lamore-2d-e-gli-oggetti-orientifici-ma-quello-che-accade-non-fa-divertire/" rel="nofollow noopener" target="_blank"><em>problema problemoso</em></a></strong><strong><a href="https://octospacc.altervista.org/2025/09/04/lamore-2d-e-gli-oggetti-orientifici-ma-quello-che-accade-non-fa-divertire/" rel="nofollow noopener" target="_blank"> delle prestazioni imbarazzanti di Love2D caricato di una tale OOP</a></strong> che non gira affatto bene su una <em>viemmina</em> come quella di Lua… e, anche se come previsto il modo che ho dovuto mettere in atto è <em>abbastanza spaventoso</em>, <em>non</em> è nemmeno <em>inadatto alla produzione</em>, e anzi: <strong>è </strong><strong><em>gnammastico</em></strong>. 😳</p><p>L’obiettivo in mente era una roba del tipo: <strong>avere nel possibile una programmazione orientata ad oggetti</strong> che, per <strong>ridurre l’overhead causato da troppi lookup in tabelle e troppe chiamate di funzioni</strong> in poco tempo, fosse <strong>basata principalmente sulla composizione</strong>, desiderio che è anche comune in Lua… ma, <strong><em>volendo evitare Lua</em></strong><strong>, perché voglio invece qualcosa di fortemente tipizzato</strong>, perché altrimenti so che finisce rapidamente tutto <em>a spacc</em>. In questo senso, <a href="https://memos.octt.eu.org/m/Pc2rtyhRBV5xSKKTckLB6G" rel="nofollow noopener" target="_blank">Teal è interessante</a>, però, per motivi che ora <em>non frecano</em>, non mi convince più di tanto… e allora ho ragionato su cosa si potesse fare con TypeScript… 😨</p><p>Ecco: sorprendentemente, <strong>sfruttando semplicemente gli oggetti anonimi</strong> (uguali a quelli di JavaScript, che si mappano perfettamente a tabelle di Lua) <strong>in congiunzione con il sistema di tipi composti di TypeScript</strong> (che funzionano come le interfacce nella OOP, ma indicano tipi di oggetti), <strong>evitando completamente le classi del linguaggio…</strong> con la proprietà intrinseca degli oggetti in JavaScript (e in Lua, duh, in qualunque linguaggio interpretato) di essere componibili, ma combinati <em>coi tipi lì</em>, <strong>si riesce ad avere a livello di sviluppo tutta la sicurezza dei tipi di TypeScript, ma in output codice Lua estremamente pulito!!!</strong> (E che, per inciso, evita completamente l’uso delle <em>metatabelle</em>, anch’esse causa di rallentamenti.) 🤯</p><p>Benchmark stavolta <em>niente</em>, poiché <em>palle</em>, e anche perché i “<em><a href="https://memos.octt.eu.org/m/2HEiRTfKFKreMyBZbxourz" rel="nofollow noopener" target="_blank">fottuti rettangoli</a></em>” hanno mostrato prestazioni negative inaspettate rispetto alle 2 versioni scritte a mano ieri in Lua… ma non perché <strong>il codice </strong><strong><em>sputato fuori</em></strong><strong> da </strong><strong><a href="https://memos.octt.eu.org/m/fiDD7gpDGBJWdRvbw9grzf" rel="nofollow noopener" target="_blank">TypeScriptToLua</a></strong><strong> in questo caso</strong> sia sporco, quanto più perché <strong>ho già iniziato a reimplementare con questo nuovo paradigma il mio </strong><strong><em>motorino</em></strong><strong> desiderato,</strong> che ovviamente dell’overhead in più lo ha comunque, ma… <strong>Stavolta, la demo di Breakout sul 3DS è magicamente giocabile</strong>, non va più a <em>5 secondi al frame</em>!!! (E sul PC mi si aggira su 1-2% di CPU, che è wow.) 🗽</p><p>Ora… boh, solo <em>le pareti che mi tengono compagnia quando programmo</em> sapranno dirmi come andrà avanti questo affarino. A parte il fatto che <strong>ho dovuto già ripensare abbastanza la API da come l’avrei voluta inizialmente</strong> — dovendo farla deviare già parecchio da HaxeFlixel, perché non sembra esserci modo di avere i tipi completamente sicuri dovendo allo stesso tempo minimizzare gli oggetti nidificati e le catene di funzioni — ci sono alcuni dettagli per cui questa cosa degli oggetti <em>pseudoclassisti</em> funzionano che mi sanno <em>di strano</em>, perché praticamente devo tenere le definizioni all’effettivo completamente separate dalle implementazioni (quindi, per esempio, devo usare <code>Cacca.new()</code> per creare una nuova <code>cacca</code>, ma <code>TCacca</code> per riferirmi al tipo…), ma sarà un <em>TypeScript skill issue</em>. 😶</p><p>C’è anche da dire che con questo mio <em>accrocco</em> non c’è incapsulazione, implementarla sarebbe un casino e costerebbe (per via di come funziona Lua, che costringe ad usare funzioni anonime per implementare questa cosa; funzioni che verrebbero interamente copiate su <em>ogni singolo oggetto</em>) lo spreco di <em>un fottio di memoria</em> (termine tecnico)… ma non lo vedo come un problema; casomai dovesse servire il distinguere campi pubblici da privati, basterà <em>rubare</em> la convenzione di Python per cui le variabili che iniziano con gli underscore sono ad uso interno. E, davvero, <strong>l’unico aspetto negativo di questa </strong><strong><em>macchinazione</em></strong><strong> credo sia il fatto di non poter ottimizzare ulteriormente</strong> senza ridurre il riuso del codice, avendo svariate chiamate a funzioni miste che per quanto piccole sarebbero meglio <em>inlinate</em>, cioè copincollate dal compilatore anziché lo sviluppatore, se solo Lua lo permettesse… <s>(…E se scrivessi un </s><s><em>postprocessore</em></s><s> Lua per fare esattamente ciò???)</s></p><p><a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://octospacc.altervista.org/tag/programmazione/" target="_blank">#programmazione</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://octospacc.altervista.org/tag/demo/" target="_blank">#demo</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://octospacc.altervista.org/tag/development/" target="_blank">#development</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://octospacc.altervista.org/tag/ottimizzazione/" target="_blank">#ottimizzazione</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://octospacc.altervista.org/tag/love2d/" target="_blank">#LOVE2D</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://octospacc.altervista.org/tag/lua/" target="_blank">#Lua</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://octospacc.altervista.org/tag/typescript/" target="_blank">#typescript</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://octospacc.altervista.org/tag/typescripttolua/" target="_blank">#TypeScriptToLua</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://octospacc.altervista.org/tag/optimizing/" target="_blank">#optimizing</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://octospacc.altervista.org/tag/optimization/" target="_blank">#optimization</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://octospacc.altervista.org/tag/oop/" target="_blank">#OOP</a></p>