Domanda

Negli esempi di attori di Scala ho visto dove un messaggio senza parametri viene inviato a un attore (come this ), case class es (o case object ) sono stati creati e quindi utilizzati come messaggi. I simboli funzionano altrettanto bene e sembrano un po 'più ordinati e, dopo aver letto un libro su Erlang, sembrano più naturali. Presumo che l'uguaglianza dei simboli funzionerebbe per gli attori remoti.

Per i messaggi con parametri le classi di casi sarebbero la scelta ovvia, quindi forse la coerenza tra i tipi di messaggio è un problema?

Ci sono ragioni per scegliere un approccio?

È stato utile?

Soluzione

Non credo che i Symbol s possano sostituire le classi case . In realtà, non sono del tutto sicuro di quale sia l'uso Symbol , dato che manca il potere dei simboli in altre lingue (ad esempio Ruby, Smalltalk) - è solo una stringa internata.

Ad esempio, nell'esempio di asta standard, è difficile vedere come rappresenteresti la complessità di un'offerta / offerta usando solo i simboli.

Per quanto riguarda case oggetti , credo anche che questi siano preferibili ai simboli. Ad esempio, possono essere istanze di tratto s ecc., E quindi fornire funzionalità.

Altri suggerimenti

La risposta breve è il controllo in fase di compilazione.

Anche i simboli pensati possono essere usati come messaggi e sono anche più succinti degli oggetti maiuscoli (non è necessario definirli), il compilatore non può rilevare i simboli errati e avrai difficoltà a capire perché gli attori non stanno ricevendo messaggi specifici quando dovrebbero.

Se le classi del caso e / o gli oggetti vengono utilizzati come messaggi, il compilatore ti dirà se stai cercando di inviare e / o ricevere messaggi inesistenti prima ancora che il programma venga eseguito.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top