Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework message naming/definition conventions #13

Open
ecpeterson opened this issue Nov 12, 2020 · 0 comments
Open

Rework message naming/definition conventions #13

ecpeterson opened this issue Nov 12, 2020 · 0 comments

Comments

@ecpeterson
Copy link
Contributor

Messages are not currently named consistently, stored in consistent places in files, … . Their organization has some of the same flavor as the organization of commands making up a procedure (#6), whose solution might enable some better compile-time checks (#11).

In the message specification case, one thing you might hope to track are the intended senders / receivers of messages. In applications, we've tried renaming the message classes to follow the format sender->receiver~message-type, but the associated constructors make-sender->receiver~message-type and slot accessors sender->receiver~message-type-slot-name start to look really unwieldy. I think it would be far preferable for Lisp to make use of this message typing information directly: a message type could be defined along the lines of

(defmessage message-type
  (:sender type
   :receiver type)
  (&rest direct-slots))

Then make-message, send-message, and receive-message could all be updated to validate that message generators/receivers are typed as specified by the defmessage payload, rather than putting this burden on the programmer (both their brain and their fingertips).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant