types for raw tuples

[Motiejus Jakštys]

Good day/morning,

assume this definition:

% one filter definition
.record [
.name filter
.field [ .name attr .type string ]
.field [ .name op .type string ]
.field [ .name parms .type filter-parm ]
]

I get back this:

-record(filter, {
attr :: string() | binary(),
op :: string() | binary(),
parms :: filter_parm()
}).

Would it be possible to get a raw tuple type?

-type filter() :: {
attr :: string() | binary(),
op :: string() | binary(),
parms :: filter_parm()
}.

Reason: we are exposing APIs, and would like to leave records out where
possible.

Regards,
Motiejus

[Anton Lavrik]

Hi Motiejus,

The correct tuple type that corresponds to you record would be

-type filter() :: {
atom(),
string() | binary(),
string() | binary(),
filter_parm()
}.

Did you mean that or do you want to omit the record name atom()
completely therefore defining an Erlang tuple instead of a record?

Either way, this is not something Piqi supports out of the box... Just
curious -- why would you need something like that?

Anton

[Motiejus Jakštys]

On Tue, Jan 22, 2013 at 6:19 AM, Anton Lavrik <ala...@piqi.org> wrote:
>
> The correct tuple type that corresponds to you record would be
>
> -type filter() :: {
> atom(),
> string() | binary(),
> string() | binary(),
> filter_parm()
> }.

Hi,
correct, thanks.

> Did you mean that or do you want to omit the record name atom()
> completely therefore defining an Erlang tuple instead of a record?

Yes.

> Either way, this is not something Piqi supports out of the box... Just
> curious -- why would you need something like that?

We consider not generally good idea to expose records in the APIs of
the functions that can be used by different applications (especially
in different projects!). This is not something technical; it's just
records that we want to avoid in function declarations.

Matter of taste, I guess.

But now when I think more about it, these different projects still
need the coresponding record definitions, and therefore all the piqi
shebang in order to properly generate input to our functions. So in
that case it wouldn't do much help I think.

Anyway, thanks for your reply.

P.S. how is 0.6 going? We are eager to try it out. :)

--
Motiejus Jakštys

[Anton Lavrik]

On Tue, Jan 22, 2013 at 12:26 AM, Motiejus Jakštys
<desir...@gmail.com> wrote:
> On Tue, Jan 22, 2013 at 6:19 AM, Anton Lavrik <ala...@piqi.org> wrote:
>>
>
> We consider not generally good idea to expose records in the APIs of
> the functions that can be used by different applications (especially
> in different projects!). This is not something technical; it's just
> records that we want to avoid in function declarations.
>
> Matter of taste, I guess.

Hmm... You can probably write some Erlang syntax transformation to
achieve that. However, keep in mind that Piqi already generates -type
r() :: #r{} for each generated -record(r, {...}). This is needed in
order to support mutually recursive records.

> But now when I think more about it, these different projects still
> need the coresponding record definitions, and therefore all the piqi
> shebang in order to properly generate input to our functions. So in
> that case it wouldn't do much help I think.

Right... And don't forget about field defaults.

> Anyway, thanks for your reply.
>
> P.S. how is 0.6 going? We are eager to try it out. :)

You are welcome as always!

Functionally, 0.6.0 is done. Just finished it over the weekend. What's
left is mainly bringing documentation up to date. If everything goes
well, I'm planning to release it this coming weekend. It will have
some interesting new features, but for the most part, it is a huge
milestone on the portable interfaces side. After I put it out,
everything will start moving A LOT faster in terms of features and
releases. And yes, Erlang implementation of "piqic-erlang" is
literally next on my list (for which 0.6 was a prerequisite). Sorry
for the long wait -- I had so much things to take care of during the
past couple of months.

Anton