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

Isolating side effects #4

Open
moonglum opened this issue Feb 12, 2018 · 2 comments
Open

Isolating side effects #4

moonglum opened this issue Feb 12, 2018 · 2 comments

Comments

@moonglum
Copy link
Owner

@moonglum moonglum commented Feb 12, 2018

It should not be possible to create side effects everywhere in the program. In particular, the functions representing the methods of an object should not create side effects. The idea is to have a second type of object for that. The names of those objects should be surrounded by *stars* (inspired by Common Lisp's earmuffs). Let's call them Schlawiner for now:

(Schlawiner new *logger*
  methods [
    "info" { |'self 'message|
      (*stdio* puts ("[info] " + message))
    }
  ]
)

(*logger* puts)

The rules are:

  • Only a Schlawiner is allowed to send messages to another Schlawiners.
  • Only a Schlawiner is allowed to create or access atoms.

The existing stdio and web objects will be converted to be Schlawiners.

The Schlawiner also has attributes in the same way an objects has. But its attributes dictionary is an atom. It can reassign its attributes with the reassign to message.

(Schlawiner new *counter*
  methods [
    "increase" { |'self|
      (self reassign "counter" to ((self @ "counter") + 1))
    }
    "counter" { |'self|
      (self @ "counter" else 0)
    }
  ]
)

(*counter* increase)
@JWahle
Copy link

@JWahle JWahle commented Mar 31, 2018

@moonglum I really like the idea of enforcing stars around objects with side-effects. I'm wondering if the rule to let only Schlawiners send messages to other Schlawiners is too restrictive. An alternative might be to let only Schlawiners create other Schlawiners. So you can pass a Schlawiner to a non-Schlawiner via Dependency Injection.
So you would still be able to reason about side-effects by looking at the DI Factories.

In Halunke, there would be no "Text" Interface, but the Objects could be implemented similarly.
I'm using Java-like-Syntax here:
`
interface Text {
String asString()
}

Text t = new UpperCaseText(
new TextOfFile("myFile.txt") // <- Schlawiner here
)
`

The Idea of building up an object graph like this is explained in more detail here:
http://www.yegor256.com/2017/06/22/object-oriented-input-output-in-cactoos.html
https://github.com/yegor256/cactoos

Loading

@moonglum
Copy link
Owner Author

@moonglum moonglum commented Apr 1, 2018

@JWahle Thank you so much for the feedback and the links 🙇 I like the idea – I agree that my proposal might be a little too restrictive. I will definitely experiment with this 👍

Loading

@moonglum moonglum mentioned this issue Jan 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants