# New Ticket Created by Zefram # Please include the string: [perl #127015] # in the subject line of all future correspondence about this issue. # <URL: https://rt.perl.org/Ticket/Display.html?id=127015 >
> 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
