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

Comments

Projects
None yet
2 participants
@moonglum
Copy link
Owner

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

This comment has been minimized.

Copy link

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

@moonglum

This comment has been minimized.

Copy link
Owner Author

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 👍

@moonglum moonglum referenced this issue Jan 4, 2019

Open

Non-block-y? #17

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.