Added types implementation

[patrickhrastnik]

Suggested fix for #75

Signed-off-by: HRASTNIK Patrick Ing [email protected]

[kadler]

Please resolve the merge conflicts and re-submit.

[kadler]

I'd suggest changing digits and delimiter to something more descriptive. SQL uses the terms precision and scale, though some may find that confusing. Perhaps total_digits and decimal_digits would be more appropriate?

[kadler]

I would rather see separate float and double functions which take no parameters and return "4F2" and "8F4", respectively.

Aside: I'm not sure why XMLSERVICE wants 4F2 and 8F4, when RPG says the decimal digits field must be blank (and would be 4F and 8F, respectively).

[kadler]

AFAIK, XMLSERVICE doesn't support integer types with scale, so the delimiter must always be 0 and is thus unnecessary.

Also, I'd also like to have separate functions for each type/length that would need no parameters, eg. signed_byte, signed_short, signed_int, signed_bigint, etc..

[github-actions]

👋 Hi! This pull request has been marked stale due to inactivity. If no further activity occurs, it will automatically be closed.

[kadler]

Would be good to get this merged. @patrickhrastnik, not sure if you have time to resolve the conflicts otherwise @abmusse if you want to pull the changes in to a new PR and get it merged that would be great.

[kadler]

One thing that I was thinking about that would impact this, is it would be really nice to have a varchar type, but that would require having the function/object return both the XMLSERVICE type as well as the varying="XX" attribute.

I think this could be done by having the function return an object with the attributes and using the javascript spread operator:

# old way
program.addParam({ type: '10A', varying: '4', value: 'Gill' });

function varchar(len) {
  return { type: len.toString() + 'a', varying: '2' }
}
function longvarchar(len) {
  return { type: len.toString() + 'a', varying: '4' }
}

program.addParam({ ...longvarchar(10), value: 'Gill' });

If we did that, it might also make sense to use camel case on the names:

• Integer
• Char
• Varchar
• LongVarchar
• etc

[abmusse]

One thing that I was thinking about that would impact this, is it would be really nice to have a varchar type, but that would require having the function/object return both the XMLSERVICE type as well as the varying="XX" attribute.

I think this could be done by having the function return an object with the attributes and using the javascript spread operator:

# old way
program.addParam({ type: '10A', varying: '4', value: 'Gill' });

function varchar(len) {
  return { type: len.toString() + 'a', varying: '2' }
}
function longvarchar(len) {
  return { type: len.toString() + 'a', varying: '4' }
}

program.addParam({ ...longvarchar(10), value: 'Gill' });

If we did that, it might also make sense to use camel case on the names:

• Integer
• Char
• Varchar
• LongVarchar
• etc

Nice! The spread operator works out cleanly in this situation. I just tested it out in sample script:

function LongVarChar(len) {
  return { type: len.toString() + 'A', varying: '4' }
}

function addParam(param) {
  console.log(param)
}

addParam({ type: '10A', varying: '2', value: 'Gill' });
addParam({ ...LongVarChar(10), value: 'Gill' })

Output

{ type: '10A', varying: '2', value: 'Gill' }
{ type: '10A', varying: '4', value: 'Gill' }

The use of camel case be to minimize confusion for the reader?
I'm pretty sure the linter will complain but we can work around that.

[github-actions]

👋 Hi! This pull request has been marked stale due to inactivity. If no further activity occurs, it will automatically be closed.