Re: How do I get custom_types to dialyze

[Anton Lavrik]

On Sat, Apr 27, 2013 at 5:00 AM, <diesway...@gmail.com> wrote:
> Say I have a type 'foo', that can only take the values 1..80
> I set it up as
> .alias [
> .name foo
> .type int64
> .erlang-type "piqirun_custom:foo"
> ]
> In piqirun_custom, I have the following (amongst other stuff)
> -type(foo() :: 1..80).
> foo_of_int64(I) when is_integer(I) andalso I >= 1 andalso I =< 80 ->
> I.
> foo_to_int64(I) when is_integer(I) andalso I >= 1 andalso I =< 80 ->
> I.
> The problem is that when you run this through piqic_erlang, the generated
> getters/setters/... will include the following line
> default_int64() -> 0.
> default_foo() -> piqirun_custom:foo_of_int64(default_int64()).
> And dialyzer is going to choke all over this (the error looks like the
> following
> "The call piqirun_custom:foo_of_int64(0) will never return since it differs
> in the 1st argument from the success typing arguments: (1..255 |
> {1..255,_})"
>
> This actually makes complete sense, since the default is expected to be '0',
> which is not what the typing of piqirun_custom:foo() expects.
> Mind you, this isn't really a protobuf issue - its more about what happens
> in the 'erlang' side of the world, where we want to be able to appropriate
> validate the data...
>
> Am I missing something really obvious here?

You got it right. There's not much more to what you have described.

To avoid Dialyzer warnings and runtime errors we could introduce
another alias property for defining erlang-specific default values to
be used instead of the built-in ones. It could look like something
like this:

.alias [
.name foo
.type int64
.erlang-type "piqirun_custom:foo"
.erlang-default "1"
]

or even this:

.alias [
.name foo
.type int64
.erlang-type "piqirun_custom:foo"
.erlang-default "piqirun_custom:foo_default()"
]

It would be very easy to extend piqic_erlang to handle this.

By the way, using custom types for runtime type validation is
something that I have not envisaged myself. It is a pretty cool hack.

Anton

[Mahesh Paolini-Subramanya]

I'd vote for 

.erlang-default "piqirun_custom:foo_default()" 

Its easier to keep everything in one place, (after all, thats where we're probably defining everything else :-)   )

And yeah, it is a pretty cool hack :-)

cheers

[Anton Lavrik]

This is now implemented in master. It came down to two simple changes:

https://github.com/alavrik/piqi-erlang/commit/01a01fc6ea29b4059ce3be70bcb7b427d79926b8#L5R58
https://github.com/alavrik/piqi-erlang/commit/01a01fc6ea29b4059ce3be70bcb7b427d79926b8#L2R67

Scroll to the top of the commit diff for the updated example
(examples/custom-types/src/example.piqi).

Enjoy :)

Anton

[Mahesh Paolini-Subramanya]

Works like a charm, and pretty much takes care of the issue.  Thanks!

This, of course, brings up the next question  - How do I get piqi to-proto to ignore these new options?

[Anton Lavrik]

On Wed, May 1, 2013 at 6:30 PM, Mahesh Paolini-Subramanya
<diesway...@gmail.com> wrote:
> Works like a charm, and pretty much takes care of the issue. Thanks!
> This, of course, brings up the next question - How do I get piqi to-proto
> to ignore these new options?

That's easy -- just add this to your .piqi modules -- like in the
example module:

(.custom-field erlang-type erlang-default)

This will tell piqi to suppress warnings on unknown fields (in our
case -- custom language extensions). Note that the above is a syntax
shorthand for listing them one by one like this:

.custom-field erlang-type
.custom-field erlang-default

Anton

[Mahesh Paolini-Subramanya]

That should teach me to actually pay attention to the documentation :-)

Thanks for the help!