Pattern per ereditarietà con membri protetti

[carmichael]

Devo ammettere che sono un principiante del javascript come premessa.
Un paio di serate fa smanettando con gli ambiti di visibilità mi sono creato un pattern molto ingenuo per mettere a disposizione una serie di facilty legate al concetto dell'ereditarietà.

Tutto è perfettibile e migliorabile, premesso che qui è presente una piccola demo che esplica un attimo l'idea, mi interesserebbe sapere se qualcuno ha già provato ad affrontare il problema degli accessi protetti in javascript e che pattern ha usato per risolverlo.

Saluti a tutti!

[Friko85]

Ciao, da un pò sono al 'lavoro' per un fw tutto mio...

Tutto si basa su un costruttore Class simile a quello di mootools:

http://debbe.altervista.org/beta.html

Cosa ne pensi?

[carmichael]

Personalmente penso che creare un framework comporti la creazione di un dsl e nel mio ordine delle idee usare un dsl comporta la perdita di feeling con il linguaggio stesso.

Fra le altre cose ho sempre trovato difficile pensare di poter competere con i colossi sviluppati oltreoceano, supportati da community enormi e quindi preferisco dedicarmi alla definizione di pattern al momento.

Per quanto riguarda la qualità e la mole del lavoro che hai fatto penso di non poter azzardare alcun tipo di giudizio se non che sia veramente notevole e che mi fa piacere vedere che in Italia c'è ancora gente che abbia voglia di creare e comprendere.

(Una volta mi è capitato di avere a che fare con un project manager che credeva che il modificatore this di javascript avesse lo stesso significato che ricopre in java)

Il mio personale punto di vista è che un selector engine debba essere una facility messa a disposizione dal framework e non un entry point... cioè per spiegarmi meglio il dom è un elemento messo a disposizione di alcuni host e penso che in un framework js meriti minore enfasi rispetto a quella che è tendenza comune attribuirgli... magari fra 5-6 anni avremo app html5 incentrate sul canvas e questo discorso sembrerà ancora più sensato.

Keep on rocking!

E se ti va di mettere su qualcosa mi trovi disponibilissimo, attualmente sto studiando il protocollo bosh per la comunicazione full duplex su protocollo http.

[Friko85]

DSL a parte ero curioso nello scrivere in js usando la logica OOP! , cosi prima ho cercato qualcosa di già fatto e non trovando nulla che mi soddisfacesse...

this, self, parent sembra che rispondano bene..

la visibilità l'ho gestita cosi:

- faccio craere 3 oggetti classe distinti: public, provite, protected
- analizzo i metodi e sostituisco i puntatori this self e parent con i veri indirizzi

per forza di cose il tempo maggiore viene sprecato al momento della creazione della classe, lo script completo ci mette circa 80ms per caricarsi jquery mi pare sui 30, per ovviare sto problema quando comprimo il codice gli faccio già sostituire gli indirizzi.

Ho fatto dei test paragonando la velocità con mootools..

faccio craere 10000 istanze e calcolo il tempo

mootools: http://debbe.altervista.org/test2.html
mio: http://debbe.altervista.org/mio.html

PS: pensa SEMPRE in grande

[carmichael]

Hai parsato la funzione via regex per capire se i metodi erano private protected o public, io stavo pensando una cosa del genere pero' parsando quel parametro che ho chiamato _className, attraverso argument.caller.callee, solo per gli elementi protected, poi pero' ho desistito, pensando al peso del parsing su ogni livello di ereditarietà.

In finale è un compromesso, ma è abbastanza chiaro che se stai chiamadno la funzione d'accesso protect, sia corretto farlo solo all'interno dell'istanza stessa.

Che ne pensi di questo approccio?

[Friko85]

Oppure alle classi ereditate...

Si ma il parsing glielo faccio solo se il codice non è compresso..

Il parsing non è cosi pesante in uso normale.. ovvioc he se crei un metodo con dentro 10000 this ci vorrà del tempo.

PS: scusa sarà l'ora tarda ma non ho capito 'l'approccio'

[carmichael]

Nel mio pattern ho una funzione pubblica ereditata dalla base EObject per accedere ai membri contenuti in $ (aggiunta, modifica, lettura).

Volevo implementare un controllo per cui se il chiamante di protect, (la funzione d'accesso ai membri protetti ) fosse diverso dall'istanza dell'oggetto stesso ci fosse una return null.

Questo per evitare di avere la funzione protect che è pubblica che ritorna risultati in ambiti indesiderati.

Quanti livelli di ereditarietà gestisci con quel pattern?

[Friko85]

Non ha un limite, posso ereditare quante classe voglio..

Il controllo non mi convice in quanto anche se la funzione è protetta e dall'oggetto principale se richiamata da null, in realtà esiste..

Nel mio script se fai un analisi degli elementi dell'oggetto gli mp protetti e privati non sono in lista..

[carmichael]

La tua soluzione mi piace in leggibilità e funzionalità.

Come la vedresti a mentenere soltanto la sintassi che identifica i protected e mantenere invece i costrutti nativi del linguaggio per i pubblici e i privati?

Perdersti in leggibilità ma risparmieresti in performance.

Ho aggiunto un benchmark al mio pattern su 10000 istanze, ma non so quanto sia in realtà falsato dal dispatcher di oggetti che ho fatto nel ns di test, che non ho rimosso per pigrizia.

[Friko85]

Originariamente inviato da carmichael
La tua soluzione mi piace in leggibilità e funzionalità.

Come la vedresti a mentenere soltanto la sintassi che identifica i protected e mantenere invece i costrutti nativi del linguaggio per i pubblici e i privati?

Perdersti in leggibilità ma risparmieresti in performance.

Ho aggiunto un benchmark al mio pattern su 10000 istanze, ma non so quanto sia in realtà falsato dal dispatcher di oggetti che ho fatto nel ns di test, che non ho rimosso per pigrizia.

Appunto leggibilità...

Secondo me il gioco vale la candela... si parla di pochi ms che poi vengono recuperati in fase di compressione..

vado a dormire