thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Lavoie (JIRA)" <>
Subject [jira] Assigned: (THRIFT-908) Make required types actually required by the Haskell type system
Date Wed, 03 Nov 2010 03:08:25 GMT


Christian Lavoie reassigned THRIFT-908:

    Assignee: Christian Lavoie

> Make required types actually required by the Haskell type system
> ----------------------------------------------------------------
>                 Key: THRIFT-908
>                 URL:
>             Project: Thrift
>          Issue Type: Bug
>          Components: Haskell - Compiler, Haskell - Library
>    Affects Versions: 0.6
>         Environment: ghc 6.12.3 on Mac OS X 10.6 (Haskell Platform 2010.2)
> Darwin -- 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386
> The Glorious Glasgow Haskell Compilation System, version 6.12.3
>            Reporter: Christian Lavoie
>            Assignee: Christian Lavoie
>             Fix For: 0.6
>         Attachments: v1-thrift-make-required-fields-required.patch
>   Original Estimate: 6h
>  Remaining Estimate: 6h
> Currently Haskell bindings consider all struct fields to be optional by having all struct
fields be "Maybe $field". This patch removes that Maybe for required fields.
> It's also probably incomplete -- I haven't looked too carefully yet at what happens on
the server side if it tries to parse out an incomplete struct definition:
> {noformat}
> struct myStruct {
>   1: required byte foo,
> }
> {noformat}
> became after some code changes
> {noformat}
> struct myStruct {
>   1: optional byte foo,
> }
> {noformat}
> And code generated for the first version is asked to read a struct from the second version
where foo is missing.
> I suspect after this patch the Haskell server commits hara-kiri trying to evaluate {{undefined}}
_outside_ of the thrift generated code (so the client could would receive an error for something
that the thrift generated code should have noticed as wrong). This is clearly inadequate.
> Consider this bug a thought experiment / request for comments until I validate that the
patch is complete. It will still break existing code.
> First and foremost:
> # Thoughts?
> # What would be an acceptable way to handle the case described above for other Haskell
users? Break the current interface some more by returning some error type (Either $struct
$errMessags?). Throw a Haskell exception?
> # How do the other bindings handle parsing invalid data off the network?
> # The generator and generated code is fairly painful to read. Would the powers that be
welcome a cleanup patch that moves as much of the t_hs_generator.cpp code to a boost::format-style
system that uses template strings that look like Haskell code, and reformats the output to
be indented, proper style Haskell code as much as possible?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message