Linguaggio di programmazione mutante?

5

Per divertirmi pensavo a come un paradigma di programmazione potesse differire da OOP e si sarebbe inventato questo concetto. Non ho una solida base in informatica, quindi potrebbe essere un luogo comune senza che io lo sappia (più probabilmente è solo un'idea stupida :)

Mi scuso in anticipo per questa domanda piuttosto sconclusionata, comunque qui va:

Nei normali metodi OOP e le classi sono varianti solo su parametri, ovvero se due diverse classi / metodi chiamano lo stesso metodo ottengono lo stesso output.

La mia idea, forse pazza, è che il metodo e la classe di chiamata potrebbero essere una parte "invisibile" della sua firma e la risposta potrebbe variare a seconda di chi chiama un metodo.

Diciamo che abbiamo un oggetto Window con un metodo Break (), ora chiunque (chi ha accesso) potrebbe chiamare questo metodo su Window con lo stesso risultato.

Ora dì che abbiamo due oggetti diversi, Hammer e SledgeHammer. Se Break necessita di produrre risultati diversi in base a questi, li passeremo come parametri Break (IBluntObject bluntObject)

Con un linguaggio di programmazione mutante (mpl) gli oggetti operativi sul metodo sarebbero visibili al metodo di interruzione senza iniziare in modo esplicito e si potrebbe adottare in base a essi. Quindi se SledgeHammer chiama Window.Break () genererebbe risultati molto diversi rispetto a Hammer.

Se le classi sono caselle nere, le classi mutanti sono caselle nere che sanno chi sta provando a premere i pulsanti e ad adattare il loro comportamento di conseguenza.

Potresti anche avere diversi set di autorizzazioni sui metodi a seconda di chi li sta chiamando piuttosto che avere autorizzazioni assolute come pubbliche e private.

Questo ha qualche vantaggio rispetto a OOP? O forse dovrei dire, aggiungerebbe qualcosa in quanto dovresti essere in grado di aggiungere semplicemente questo aspetto ai metodi (basta dare accesso a una variabile CallingMethod e CallingClass nel contesto)

Non sono sicuro, potrebbe essere difficile per avvolgere la testa, sarebbe piuttosto interessante avere classi che si sono adottate da sole a chi le usa però. Eppure è un concetto interessante, cosa ne pensi, è fattibile?

Ecco alcuni potenziali codici fittizi di un gioco in cui un giocatore ha danneggiato qualcosa. Nella normale OOP molte cose sarebbero invece passate come parametri al metodo, mentre qui Damage "tira" le proprietà che usa. Diverso? si, meglio? forse no:)

Class Player
{
    [AccessableBy:Terrain,Player]
    void Damage
    {
        if (#CallingClass has property HitPoints)
        {
            this.health -= #CallingClass.HitPoints;
        }

        if (this.health < 0 && #CallingClass is Terrain)
        {
            ShowMessage("was killed by the environment");
        }
        else if (health < 0 && #CallingClass is Player &&  #CallingMethod is RocketLauncher)
        {
            ShowMessage("was killed with a rocketlauncher by player" + #CallingClass.PlayerName);
        }

    }
}

Per ridurre le istruzioni if-else, è possibile eseguire l'override del metodo in base ai metodi e alle classi del chiamante

    
posta Homde 11.01.2011 - 22:21
fonte

9 risposte

21

Fammi vedere se capisco cosa stai ricevendo.

Nei linguaggi OOP tradizionali come C ++ o C #, l'azione di un metodo dipende dal tipo di runtime del ricevitore :

Window w1 = new GlassWindow();
Window w2 = new PlexiglassWindow();
w1.Break(new Brick());
w2.Break(new Brick());

Il metodo effettivamente invocato dipende dal tipo di runtime, non dal tipo di tempo di compilazione, del ricevitore, a condizione che Break sia "virtuale".

Le lingue che hanno questa proprietà sono chiamate lingue "single virtual dispatch".

La tua proposta è che l'azione di Break dipenda anche dal tipo di runtime dell'argomento. Supponiamo che Break abbia un oggetto:

w1.Break(new Hammer());
w1.Break(new Pillow());
w2.Break(new Hammer());
w2.Break(new Pillow());

e ora forse quattro cose diverse accadono a seconda dei tipi di runtime.

Questa sorta di operazione di doppia spedizione è molto comune in cose come i giochi, in cui si desidera avere una logica diversa per ogni possibile tipo di collisione: lettore con laser, laser con laser, laser con lettore, lettore con muro, laser con parete ...

Le lingue che hanno questa proprietà sono chiamate lingue "doppia spedizione"; le lingue che possono fare più della doppia spedizione sono dette "invio multiplo".

Questa è un'area abbastanza ben studiata; fai una ricerca sul "modello visitatore" per saperne di più sulla simulazione del doppio invio in un unico linguaggio di spedizione.

    
risposta data 11.01.2011 - 23:00
fonte
3

Questo suona molto simile a ciò che S4 sta facendo in R : definendo un metodo generico e poi spedendo ad un metodo basato sulla firma degli argomenti, cioè:

setGeneric("sum", function(x,y) standardGeneric("sum")) 

# method for numeric object with a numeric argument
setMethod("sum", 
          signature=c("numeric","numeric"), 
          function {
             return(x+y)
})

# method for a numeric object with a character argument
setMethod("sum", 
          signature=c("numeric","character"), 
          function {
             return(paste(x,y))
})

# method for a numeric object with all the rest
setMethod("sum",
          signature=c("numeric","ANY"), 
          function {
             return(x)
})

O devo averti frainteso completamente. In questo codice la funzione "somma" corrisponderà agli argomenti dati (ciò che chiamate il chiamante (primo argomento) e il callee (secondo argomento) con la firma delle funzioni. Se non può corrispondere, corrisponderà a quello in cui la firma dice "ANY".

PS: questo è un esempio banale, ovviamente

    
risposta data 11.01.2011 - 22:33
fonte
1

Una delle regole principali nella vita non è aggiungere complessità extra a meno che non sia necessaria. Il chiamante in OOP può sempre passare alcuni parametri che direbbero al chiamato, in che modo esattamente il callee deve comportarsi. Quello che vuoi fare è semplicemente aggiungere un parametro implicito (firma di classe / metodo). E quale è lo scopo?

Se alcuni metodi dovessero reagire a ciò che è il chiamante, basta semplicemente passare il nome della classe / tipo / qualsiasi cosa esplicitamente e tutto qui. Con buona RTTI questo può essere fatto in modo pratico - si passa un riferimento all'oggetto del chiamante a un chiamato e si verifica il tipo di informazioni dell'oggetto chiamante.

    
risposta data 11.01.2011 - 23:32
fonte
1

Puoi già fare questo (cioè scoprire chi è la classe / metodo chiamante) in qualsiasi linguaggio JVM osservando la traccia dello stack. Dovresti dare un'occhiata alla documentazione per il metodo "getStackTrace" nella classe Thread. Quello che vuoi può essere implementato in poche righe.

    
risposta data 12.01.2011 - 10:09
fonte
1

Potresti voler esaminare Programmazione orientata al soggetto , come ad es. implementato nella noi programmazione Lingua (dalle stesse persone che hanno anche fatto una bella implementazione di Programmazione orientata agli oggetti nel Self Linguaggio di programmazione ).

Nella programmazione orientata ai soggetti, la forma di un oggetto è soggettiva dal punto di vista del chiamante. Cioè a ogni chiamante l'oggetto sembra diverso.

Questa idea era ancora più generalizzata nell'idea di Programmazione orientata al contesto nel linguaggio di programmazione Korz , che è stato presentato un paio di volte questo anno .

    
risposta data 31.12.2014 - 12:16
fonte
0

Sembra metodi di estensione .

Tranne che i metodi di estensione possono vivere solo su classi statiche. Vuoi solo la stessa idea (un modificatore di parametro this ) per qualsiasi metodo.

    
risposta data 11.01.2011 - 23:11
fonte
0

La tua idea sembra simile a:

Risulta che potresti non aver nemmeno bisogno di parametri impliciti per ciò che stai cercando di fare.

    
risposta data 12.01.2011 - 03:42
fonte
0

Penso che ciò che stai suggerendo interrompa completamente il concetto di astrazione. Una funzione non dovrebbe avere una logica basata su quale funzione o oggetto lo ha chiamato. La dipendenza implicita ci sarebbe un incubo di manutenzione.

    
risposta data 12.01.2011 - 05:36
fonte
-2

Questo suona molto simile a un typeclass o, come sottolinea @Ken Bloom, ai parametri impliciti di Scala (che sono fondamentalmente l'interpretazione orientata agli oggetti di Typeclass di Scala).

    
risposta data 16.01.2011 - 09:04
fonte

Leggi altre domande sui tag