Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Date type carries stowaway data #4920

Open
p6rt opened this issue Dec 24, 2015 · 1 comment
Open

Date type carries stowaway data #4920

p6rt opened this issue Dec 24, 2015 · 1 comment
Labels
LTA Less Than Awesome; typically an error message that could be better

Comments

@p6rt
Copy link

p6rt commented Dec 24, 2015

Migrated from rt.perl.org#127015 (status was 'new')

Searchable as RT127015$

@p6rt
Copy link
Author

p6rt commented Dec 24, 2015

From zefram@fysh.org

Date.new(​:year).year
True

It is less than awesome that the .year method on a Date object returns
something other than a basal Int. I appreciate that True.^isa(Int),
but the year portion of a date is an integer in the mathematical sense,
not merely in the sense of .^isa(Int) in your class hierarchy. So it
is surprising that .year returns something other than the value that
most directly represents the relevant integer. The True passed to the
constructor should be coerced to a basal Int somewhere along the line.

Preferably, it should be coerced in the constructor. This avoids the
Date object storing a distinction (between subclasses of Int) that is
irrelevant to its function and will only need to be thrown away later.
Keeping the irrelevant distinction wouldn't matter much in a mutable
object, but in an immutable object (as Date objects externally appear
to be) it impedes recursive object identity comparison. In fact, the
distinction being visible via .year leads to objects claiming to be the
same as judged by .WHICH but behaving distinguishably​:

my $a = Date.new(​:year(1))
0001-01-01
my $b = Date.new(​:year(True))
0001-01-01
$a.WHICH
Date|-678575
$b.WHICH
Date|-678575
$a.year
1
$b.year
True

Similar issues arise from (1 but False) and other nominally-Int objects
that are not basal Ints. The Bool class is merely the most accessible
way to invoke this problem.

There has been a lot of talk from Perl 6 core developers of "enough rope
to shoot yourself in the foot", and ceteris paribus this would be at least
a partial defence regarding problems that arise from subclassing Int.
But with Bool and other enumerations actually being subclasses of Int,
the core developers have themselves wielded that rope in a dangerous
manner, and a fair few foot injuries have resulted. One might not have
expected Date to cope well with Int subclasses if those only arose from
incautious users, but surely it must be expected to cope with mundane
objects supplied by the core language.

The same kind of problem presumably occurs with other classes and other
kinds of type constraint. I don't propose to report any others for the
time being; this is a test case for the principle.

-zefram

@p6rt p6rt added the LTA Less Than Awesome; typically an error message that could be better label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LTA Less Than Awesome; typically an error message that could be better
Projects
None yet
Development

No branches or pull requests

1 participant