[Seaside-dev] Date>>daysInMonth:forYear: versus Month>>daysInMonth:forYear:

[Dale Henrichs]

It's not a problem for GemStone. Our Date class doesn't have this 
method. Either way will work fine.

Dale

Philippe Marschall wrote:

>2007/9/10, Michael Lucas-Smith <mlucas-smith at cincom.com>:
>  
>
>>Hi seaside-dev,
>>
>>I've been removing the Squeak clashes with VW so that hopefully
>>ObjectStudio8 will also be able to use Seaside. Pretty much everything
>>works, there aren't many conflicts that are unreasonable - however, I've
>>hit one today that really is a problem.
>>
>>The method daysInMonth:forYear: in Squeak assumes the month parameter is
>>a monthIndex. In VW it assumes the parameter is a monthName.
>>
>>The Month class comes from Squeak, so it's been implement to take either
>>an monthIndex or a monthName. I want to avoid doing an override of the
>>VW base - there's only one place in base Seaside that explicitly calls
>>this on Date instead of Month - that's in WADateInput. WADateSelector
>>specifically calls it on Month.
>>
>>Could we have a porting convention where daysInMonth:forYear: is only
>>ever called on Month instead of Date?
>>    
>>
>
>I don't think the current behavior of sending the same message to two
>different classes and expecting the same behavior makes any sense. So
>we should settle either for Month or Date. Having that said there are
>more dialects to take care of than VisualWorks and Squeak. How is the
>situation on Gemstone? If it doesn't matter for them and you'd prefer
>Month then I'd say we go for Month else for SeasidePlatformSupport :(
>
>WAMiniCalendar is probably the worst you can get in terms chronology
>portability.
>
>And oh, tests would be welcomed :)
>
>Cheers
>Philippe
>  
>