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

[Philippe Marschall]

There you go: Seaside2.8a1-pmm.476

Cheers
Philippe

2007/9/11, Dale Henrichs <dale.henrichs at gemstone.com>:
> 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
> >
> >
>
>