[HN Gopher] Rusty Typestates - Starting Out
       ___________________________________________________________________
        
       Rusty Typestates - Starting Out
        
       Author : 42jd
       Score  : 46 points
       Date   : 2021-12-03 19:13 UTC (3 hours ago)
        
 (HTM) web link (rustype.github.io)
 (TXT) w3m dump (rustype.github.io)
        
       | brunoqc wrote:
       | I wonder how it improved since the last article.
        
       | lliamander wrote:
       | Note that you can do something like Typestates in Java using
       | static inner classes that have no public constructors, though
       | undoubtedly there are advantages to having first class language
       | support. Behold:                 Scanner.OpenScanner sOpen =
       | Scanner.open(/*some source*/);       //do some processing
       | Scanner.ClosedScanner sClosed = sOpen.close();
       | sClosed.nextLine() //type error
       | 
       | I sometimes do this in combination with the Builder pattern. This
       | "typesafe builder" allows for a fluent API that guides the user
       | as to its use.
       | 
       | The point is, you can still use types to represent states.
        
         | ketralnis wrote:
         | Is sOpen.nextLine() after the close also a compile time error?
        
           | lliamander wrote:
           | No. That's a good point and one of those things that having
           | built-in language support helps. But if you are using method
           | chaining (i.e. fluent API) that matters less.
        
         | tstack wrote:
         | Yes, one of the advantage of language support is that "sOpen"
         | will be consumed by the "close()" call and can't be reused. I
         | don't think that's really possible in Java without an extra
         | checker. But, it's usually not a problem in practice if the
         | user sticks to using the API in a fluent manner.
        
       | nllsh wrote:
       | I just read about typestates in Rust on Cliff Biffle's blog here:
       | http://cliffle.com/blog/rust-typestate/#variation-state-type...
       | 
       | He covers a few additional parts of the typestate pattern, such
       | as isolating data in specific states as well as sharing common
       | implementations across a subset of states.
       | 
       | I'd also like to note that typestates also show up in functional
       | programming under Indexed Monads, where a function might take a
       | struct from an initial typestate, unwrap its data, and return a
       | final(likely different) typestate. You can search Indexed Monad
       | for more explanation there. If you work primarily in typescript
       | you can find a production ready implementation of typestate
       | programming here: https://github.com/DenisFrezzato/hyper-ts
        
       | thechao wrote:
       | My gut feeling is that the combination of typestates and
       | stackless coroutines (really: CSP) would make for a kick-ass
       | driver design. It's pretty solid for the toys I've designed for
       | OpenGLES-2-class drivers. My gut feeling is that a lot of the
       | command-buffer shenanigans in Vulkan, Metal, and DX45035+ come
       | from trying to make reasoning about driver development tractable,
       | while also not making the users' lives awful.
        
       | Klasiaster wrote:
       | Since this often matters when implementing protocols, there is
       | research about session types and verification. Here is a Rust
       | library for session types: https://github.com/Munksgaard/session-
       | types
       | 
       | I believe both have some overlap.
        
       ___________________________________________________________________
       (page generated 2021-12-03 23:01 UTC)