Comment by wpearse

7 years ago

Hello! Long-time lurker, and guilty dev behind the garage door. You can see the (broken) code I wrote here:

https://github.com/wpearse/wemos-d1-garage-door-wifi

I'll get around to fixing it later this week.

Also, an apology: I should have used "side-effect-free" instead of "idempotent" in my tweets.

53 comments

wpearse

Reply
inopinatus  7 years ago

> I should have used "side-effect-free" instead of "idempotent" in my tweets

The HTTP term is "safe method". Although you weren't even wrong because section 4.2.2 of RFC7231 (i.e. HTTP) defines all safe methods, including GET, as idempotent.

I think they use this language because nothing is truly side-effect free. In fact GETs can have side-effects, the most obvious of which is writing the fact of it to a logfile, and that's the most harmless side-effect of all, right until you run out of disk space.

Being a language arse I think the high precision descriptor is actually nullipotent. https://en.wiktionary.org/wiki/nullipotent but I'd never say it out loud.

  • cmenge  7 years ago

    'Side-effect free' means that doing it once, twice or n >= 3 times (with same parameters) yields the same result, i.e. what it returns doesn't depend on any remote state that is altered by the call itself.

    However, an idempotent HTTP call is certainly not a pure function which some people seem to be mixing up. Pure functions don't work with I/O.

    REST is bit more specific and explicitly requires GET to be nullipotent which really means "effect free" - it just reads and doesn't alter the state on the remote system at all.

    Side-effects like log files, rate-limiting, etc. will always exist, but they do belong to a different 'layer', so to speak. That is, these should be unobservable side-effects (also think about minuscule effects on the power grid, the fact that a request might write something to an ARP-cache, etc. - they all happen at different layers, so the quantum world state keeps changing, but that's not what this is about). Whether an X-Request-Count header violates the requirements or not depends on interpretation. From the garage door perspective, I wouldn't care...

  • micimize  7 years ago

    IMO "side-effect free" is always a statement constrained by the operating level of abstraction. Logging is not an effect at the level of the application, but rather some subset of it's context (system, db).

    I love that term and am going to use it as much as possible

wpearse  7 years ago

Fixed now: https://github.com/wpearse/wemos-d1-garage-door-wifi/commit/...

I think.

edit: updated link because left creds in the commit :-/

lisper  7 years ago

Please, for the love of all that is holy, don't post long-form content on Twitter.

  • wpearse  7 years ago

    I'm sorry. This is the first time I've used a thread. I won't do it again!

    • wpearse  7 years ago

      Actually, I think I actually wrote this story just so I could try out the "new" (months-old?) threading feature. I don't much twitter.

bjackman  7 years ago

Anything side-effect-free is idempotent too, I suppose

  • someonewithpc  7 years ago

    No. A function which multiplies a number by two is side effect free, but is no idempotent.

    • StavrosK  7 years ago

      I dispute your example. If you call f(2) and it always returns 4, it's idempotent and side-effect-free. If you call f() and it returns 4, then 8, etc, it is neither.

      12 replies →

    • mseebach  7 years ago

      I think that is considered idempotent in the REST-sense of the word: you can multiply a number by two as many times as you like, the result will be the same (and no state is mutated).

      I looked it up, apparently there's a formal definition "denoting an element of a set which is unchanged in value when multiplied or otherwise operated on by itself", which does not seem to describe the REST usage very well, though.

      5 replies →

pletnes  7 years ago

No side effects means no garage door opening or closing. I guess you wanted it to open or close in some cases at least?