Print int custom raw value

[Orest-Divintari]

There is a use case where via rector we convert an integer from this format 1050 to 10_50 which represents for example $10.50

This was supported by rector but after this pr that is not supported anymore.

If you create a new Int_(10_50) the printer will print it as 1050

So i created this pr to add it here if that makes sense
If not, could you please let me know if there is an alternative solution to separate with _ integer values ?

[theofidry]

There is a version of the printer for which the node formatting is preserved (within reason). Maybe that could be done there automatically rather than hiding it behind an undocumented flag.

[Orest-Divintari]

There is a version of the printer for which the node formatting is preserved (within reason). Maybe that could be done there automatically rather than hiding it behind an undocumented flag.

Thanks for replying!
I want to clarify the use case: I'm not trying to preserve existing formatting, but rather transform the formatting of parsed integers.

For example, in a Cash context where amounts are in cents:

• Original: new Cash(1050)
• Desired output: new Cash(10_50) (for readability of $10.50)

[ruudk]

There is a version of the printer for which the node formatting is preserved (within reason). Maybe that could be done there automatically rather than hiding it behind an undocumented flag.

It's true, when using the preserving formatter, this is kept. But that's the point. We want to change existing integers and format them using underscores. That means that we don't want to preserve, want a complete new representation. Therefore, the preserving formatter does not have a role.

$node = Int_::fromString('12_34');

// object(PhpParser\Node\Scalar\Int_)#2 (2) {
//  ["attributes":protected]=>
//  array(2) {
//    ["rawValue"]=>
//    string(5) "12_34"
//    ["kind"]=>
//    int(10)
//  }
//  ["value"]=>
//  int(1234)
// }
var_dump($node);

echo new Standard()->prettyPrintExpr($node); // returns 1234 while we expect 12_34

So there is no way with the Standard printer, and plain AST, to write it to format 12_34.

[ruudk]

@samsonasik What do you think of this? I think it makes a lot of sense. Would be great if you could do a review as well.

[samsonasik]

This should apply on float values as well?

[Orest-Divintari]

This should apply on float values as well?

the float method does not reach to the kind attribute
If the concern for performance regarding the int method was to reach to another attribute
Does that apply here as well ?

Meaning,
Will it slow down if we check for the kind attribute in the float method ?

[samsonasik]

Looks good to me 👍

I think this can be starter, another scalar values can follow this if this merged 👍

[ruudk]

@nikic I know you are probably very busy, but if you have time, would you mind giving this a review? This will help us a lot in Rector. Thanks 🙏

[Orest-Divintari]

Hi @nikic , if you find some time, a review on this would be greatly appreciated. Thank you!

[nikic]

What I considered doing here when the raw value was originally introduced was to always use it for printing if the rawValue matches the value (to gracefully handle the case where the value is modified but rawValue is stale). But at this point that would be a non-trivial breaking change, so the opt-in is probably better.

I'm not sure handling this as a separate "kind" is best though. Ultimately, the "raw value" is still going to be one of bin/oct/dec/hex. Whether to use the raw value is only a pretty printing choice. So I think I'd prefer this to be a separate option, like you had originally. (There is also the variant of making this a global pretty printer option instead of something per-node.)

[Orest-Divintari]

What I considered doing here when the raw value was originally introduced was to always use it for printing if the rawValue matches the value (to gracefully handle the case where the value is modified but rawValue is stale). But at this point that would be a non-trivial breaking change, so the opt-in is probably better.

I'm not sure handling this as a separate "kind" is best though. Ultimately, the "raw value" is still going to be one of bin/oct/dec/hex. Whether to use the raw value is only a pretty printing choice. So I think I'd prefer this to be a separate option, like you had originally. (There is also the variant of making this a global pretty printer option instead of something per-node.)

Hi @nikic

thanks for replying

i went back to the original approach

[nikic]

Can you please rebase over e481026 and then document the attribute there?

[Orest-Divintari]

Can you please rebase over e481026 and then document the attribute there?

done

[nikic]

LGTM