5 ms·

For every situation I can conceive of offhand where this "worlds" abstraction could be useful, I can immediately think of a simpler way to achieve the same resu

For every situation I can conceive of offhand where this "worlds" abstraction could be useful, I can immediately think of a simpler way to achieve the same results. Perhaps I'm being naive?

apgwoz 17y ago
Perhaps you're thinking in blub? edit: Can you give examples? How do you roll back side effects in your solutions?
- viraptor 17y ago
  Exception catching. Worlds only handle your local memory (and remote resources via destructors if you can use them). But even if you could rely on world destruction, do you really want to deal with situation where 2 worlds have to roll back 2 different remote resource modification? Can you do it reliably? If you need to write more than 1 line to do it, how is it different from old-style "except ....: ..."?
  - calambrac 17y ago
    You're missing the point. Here's the basic transaction paradigm for remote resources: try: remote_resource.start_transaction() #dostuff remote_resource.commit() except e: remote_resource.rollback() How do you do the same thing when modifying a local variable? You might try making a copy, modifying that, and then assigning back, but that's boilerplate, and it's easy to get wrong. Worlds are a more primitive mechanism that would be baked into a language, such that building a generic transaction api for local actions on top of worlds would be trivial. The fact that it could look exactly like the transaction api that you currently know and love for remote resources is a feature.
    - viraptor 17y ago
      Ok... maybe it's because I like to program the functional way (in imperative languages), but I've never found a reason to rollback local variable changes. That's because local variables don't "fail" and don't need to be rolled back. I see why it's a nice solution but I've never really seen the problem. What I normally do is: operate on temporaries (or copied parameters), change remote resource (it's safe to just rollback resource changes and exit here in case of problems), then change "the state" when operations cannot fail any more. Is there any real-live problem that needs local variables rollback? (that is shorter / nicer than returning the result from temporary locals) I'd really like to see it.
    - scott_s 17y ago
      http://en.wikipedia.org/wiki/Software_transactional_memory http://en.wikipedia.org/wiki/Software_transactional_memory It's a heavily researched topic right now. The Worlds concept, as far as I can tell, is actually more general than STM and what you described. In STM, there's the global state everyone can see, and then there's local states that try to commit atomically to the global state. With Worlds, I don't think there's one true global state. I think it would give you more explicit control, which I'm not convinced would be a good thing.
      - calambrac 17y ago
        The Worlds concept, as far as I can tell, is actually more general than STM and what you described Where in my comment did I describe Worlds in a limited way? I just gave one small example of one possible application of them, in reply to a comment specifically about their relationship to transactions.
        scott_s 17y ago
        I got the impression you didn't see it as more general than that. And I think it's worth noting that STM is a solution the problem you presented.
        deleted 17y ago
        [deleted]

For every situation I can conceive of offhand where this "worlds" abstraction could be useful, I can immediately think of a simpler way to achieve the same results. Perhaps I'm being naive?

apgwoz 17y ago

Perhaps you're thinking in blub? edit: Can you give examples? How do you roll back side effects in your solutions?

viraptor 17y ago
Exception catching. Worlds only handle your local memory (and remote resources via destructors if you can use them). But even if you could rely on world destruction, do you really want to deal with situation where 2 worlds have to roll back 2 different remote resource modification? Can you do it reliably? If you need to write more than 1 line to do it, how is it different from old-style "except ....: ..."?
- calambrac 17y ago
  You're missing the point. Here's the basic transaction paradigm for remote resources: try: remote_resource.start_transaction() #dostuff remote_resource.commit() except e: remote_resource.rollback() How do you do the same thing when modifying a local variable? You might try making a copy, modifying that, and then assigning back, but that's boilerplate, and it's easy to get wrong. Worlds are a more primitive mechanism that would be baked into a language, such that building a generic transaction api for local actions on top of worlds would be trivial. The fact that it could look exactly like the transaction api that you currently know and love for remote resources is a feature.
  - viraptor 17y ago
    Ok... maybe it's because I like to program the functional way (in imperative languages), but I've never found a reason to rollback local variable changes. That's because local variables don't "fail" and don't need to be rolled back. I see why it's a nice solution but I've never really seen the problem. What I normally do is: operate on temporaries (or copied parameters), change remote resource (it's safe to just rollback resource changes and exit here in case of problems), then change "the state" when operations cannot fail any more. Is there any real-live problem that needs local variables rollback? (that is shorter / nicer than returning the result from temporary locals) I'd really like to see it.
  - scott_s 17y ago
    http://en.wikipedia.org/wiki/Software_transactional_memory http://en.wikipedia.org/wiki/Software_transactional_memory It's a heavily researched topic right now. The Worlds concept, as far as I can tell, is actually more general than STM and what you described. In STM, there's the global state everyone can see, and then there's local states that try to commit atomically to the global state. With Worlds, I don't think there's one true global state. I think it would give you more explicit control, which I'm not convinced would be a good thing.
    - calambrac 17y ago
      The Worlds concept, as far as I can tell, is actually more general than STM and what you described Where in my comment did I describe Worlds in a limited way? I just gave one small example of one possible application of them, in reply to a comment specifically about their relationship to transactions.
      - scott_s 17y ago
        I got the impression you didn't see it as more general than that. And I think it's worth noting that STM is a solution the problem you presented.
        deleted 17y ago
        [deleted]