From 676baad4ab176f7a531952aa5fb770ee71083538 Mon Sep 17 00:00:00 2001 From: kobaken Date: Thu, 25 Jan 2024 09:59:39 +0900 Subject: [PATCH] =?UTF-8?q?ppc0017=E3=81=AE=E9=9B=9B=E5=BD=A2=E3=82=92?= =?UTF-8?q?=E7=94=A8=E6=84=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../PPCs/ppcs/ppc0017-original-build-type.md | 155 ++++++++++++++++++ 1 file changed, 155 insertions(+) create mode 100644 docs/articles/github.com/Perl/PPCs/ppcs/ppc0017-original-build-type.md diff --git a/docs/articles/github.com/Perl/PPCs/ppcs/ppc0017-original-build-type.md b/docs/articles/github.com/Perl/PPCs/ppcs/ppc0017-original-build-type.md new file mode 100644 index 00000000..81861e5c --- /dev/null +++ b/docs/articles/github.com/Perl/PPCs/ppcs/ppc0017-original-build-type.md @@ -0,0 +1,155 @@ +# Perl/PPCs/ppcs/ppcs/ppc0017-original-build-type の翻訳 + +この文書は、[Perl/PPCs/ppcs/ppcs/ppc0017-original-build-type](https://github.com/Perl/PPCs/blob/main/ppcs/ppcs/ppc0017-original-build-type.md)を翻訳したものです。 + +原題は、「built-in functions for checking the original type of a scalar」です + +## Preamble 序文 + +翻訳注：こちらは原文の情報です。 + + Author: Graham Knop + Sponsor: + ID: 0017 + Status: Implemented + +## Abstract 要約 + +This PPC proposes adding new builtin functions created_as_string and created_as_number for checking the original form of non-scalar references. Specifically, checking if a value was created as a string or a number. This is primarily meant for use by serializers. + +## Motivation 動機 + +Perl itself is operator typed and is not generally meant to distinguish +between values like 1 and "1". However, many external systems do care about +these types, and many times these values need to be transferred through perl +without anything like a schema to enforce these types. This makes it important +for things like serializers to be able to track the "origin" type of a value. + +Classically, perl scalars have no set type. They may be created as strings or +numbers, but based on their use they will internally store alternate forms of +the value. If these alternate forms are considered "accurate", the +corresponding flag will be set. This makes it impossible to know for certain +how some values were created, as they will have both string and number forms +that are flagged as "accurate". + +In perl v5.36, this has changed. The POK flag is now only set for values that +are created as strings. Values that are created as strings may gain IOK or NOK +flags based on their use, but since numbers will never gain the POK flag, this +can still be used to detect numbers. + +Exposing this information via builtin functions will allow pure perl code to +accurately serialize values. + +## Rationale 提案理由 + +While the flags on scalars can be checked via the B module, using it requires +an understanding of perl internals, and it is slow and uses a fairly large +amount of memory. Being able to interpret the flags to know string vs number +is also not entirely obvious. + +The functions are intentionally using longer less convenient names, with the +hope that this will discourage their use for type checks within perl. Inside +perl, 1 and "1" are meant to be treated equivalently. It is only when +transferring data outside perl that these are meant to be used. + +`created_as` is meant to only tell how a value was created, without implying +anything further about what the value "is". `created` in this case means any +modification of the value, as any modification of a value requires creating +the new, modified value. + +## Specification 仕様 + + created_as_string VALUE + +`created_as_string` takes a single scalar argument. + +It returns a boolean value representing if the value was originally created as +a string. It will return false for references, numbers, booleans, and undef. +Internally, this would be `SvPOK(sv) && !SvIsBOOL(sv)`. + + created_as_number VALUE + +`created_as_number` takes a single scalar argument. + +It returns a boolean value representing if the value was originally created as +a number. It will return false for references, strings, booleans, and undef. +Internally, this would be `SvNIOK(sv) && !SvPOK(sv) && !SvIsBOOL(sv)`. + +## Backwards Compatibility 後方互換性 + +There should be no significant backwards compatibility concerns. +`created_as_string` and `created_as_number` will be imported only when +requested. Static analysis tools may need to be updated. + +As these functions rely on the changes to how SV flags get set, it isn't +possible to accurately implement these on older perls. Existing serializers +use heuristics that will usually give accurate answers. One of these heuristics +could be used to provide a compatible polyfill. + +## Security Implications + +Nothing specific predicted. + +## Examples 例 + +```perl +use builtin qw(created_as_number created_as_string); + +my $value1 = "1"; +my $string1 = created_as_string $value1; # true +my $number1 = created_as_number $value1; # false + +my $value2 = 1; +my $string2 = created_as_string $value2; # false +my $number2 = created_as_number $value2; # true + +my $value3 = "1"; +my $used_as_number3 = 0+$value3; +my $string3 = created_as_string $value3; # true +my $number3 = created_as_number $value3; # false + +my $value4 = 1; +my $used_as_string4 = "$value4"; +my $string4 = created_as_string $value4; # false +my $number4 = created_as_number $value4; # true +``` + +## Prototype Implementation プロトタイプ実装 + +None. + +## Future Scope 将来の見込み + +It is possible that in the future, the NOK or IOK flags will only be set for +values created as numbers. That would mean the implementation of these +functions may change, but should not impact the results returned. + +Additionally, if the NOK and IOK flags were only set for values created as +integers or created as floats, it may be possible to provide additional +functions `created_as_integer` and `created_as_float` to distinguish these +types. Some serializers care about this distinction as well. + +## Rejected Ideas 却下されたアイディア + +Various alternative names for these functions have been proposed. + +`is_string` and `is_number` were the initial discussed functions, but these +names imply stronger typing than perl is really meant to have. They would more +strongly encourage using these functions for type checking within perl, rather +than the usually more appropriate `looks_like_number`. + +`was_originally_string` and `was_originally_number` were also proposed, but +`originally` carries the implication that the values may no longer be those +things. The use of an adverb also feels wrong stylistically. + +## Open Issues + +None? + +## Copyright + +Copyright (C) 2022, Graham Knop. + +This document and code and documentation within it may be used, redistributed +and/or modified under the same terms as Perl itself. +