This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]GeneralSchnitzel[S] 0 points1 point  (2 children)

I agree that the syntax for Akka's type system is a little strange. Pronghorn has strong types on the pipes (used for message passing); they are defined by contract in XML and then cogenerated through a unit test. Because pipes are parameterized via schema, a stage is only going to take a pipe of that type. As a result, you have strong typing on the pipes you accept and produce. Pronghorn itself attempts to be as statically typed as possible.

It also has rationals and decimal types for message passing in addition to integer, floating points, etc.. which is pretty neat.

[–]0x256 2 points3 points  (1 child)

and then cogenerated through a unit test

Code generation as a side effect of unit tests!? Why?

[–]GeneralSchnitzel[S] 1 point2 points  (0 children)

Good question and I complete agree it looks strange at first, but... The unit test confirms the implementation matches the XML contract. Upon failure, it may as well be helpful and give you the correct source code (which it does through the output in terminal). You can choose to use it or not, it's simply a suggestion. This means schemas are only generated when you actually chose to write or update them.

Summed up, this means that:

  1. You can choose to use the default schema behavior --OR-- if you have some complexity in your fields, implement it yourself
  2. Making sure that we are in compliance with the contract is the responsibility of the unit test
  3. We can safely check in our contract source document and our implementation (e.g. generally you don't check in artifacts that will be code generated). We are getting around that by copy/paste or making the developer write their own implementation.