Skip Menu |
Report information
Id: 127015
Status: new
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: zefram [at] fysh.org
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



To: rakudobug [...] perl.org
Date: Thu, 24 Dec 2015 03:58:38 +0000
From: Zefram <zefram [...] fysh.org>
Subject: [LTA] Date type carries stowaway data
Download (untitled) / with headers
text/plain 2.1k
Show quoted text
> 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: Show quoted text
> my $a = Date.new(:year(1))
0001-01-01 Show quoted text
> my $b = Date.new(:year(True))
0001-01-01 Show quoted text
> $a.WHICH
Date|-678575 Show quoted text
> $b.WHICH
Date|-678575 Show quoted text
> $a.year
1 Show quoted text
> $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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org