freenode/#clim - IRC Chatlog
Search
18:08:12
jackdaniel
I agree that both are valid; there are three reasons why I have decided (contrary to my initial intuition) to be more permissive
18:09:01
jackdaniel
for once, there is no practical reason why not to be permissive (i.e I can't think of any improvements for the implementation which would use this fact)
18:09:53
jackdaniel
second reason is that since more popular implementations allow that, there is most likely some software which does excercise this permissive interpretation
18:11:10
jackdaniel
and the third reason is quite similar to the second one - a new code is (usually) written with more popular implementations (I mean sbcl and ccl by that), so being more permissive is good for forward compatibility
18:12:07
jackdaniel
well, if there are reasons for not being compatible with sbcl I do just that (i.e ,@,@form is not conforming, however sbcl supports that -- but that complicates and basically decides for a very specific reader implementation)
18:14:45
scymtym
i wouldn't mind conforming to the strict interpretation in McCLIM code, since i already had to make the required changes twice. once when playing with Mezzano and once when playing with ABCL
18:15:25
jackdaniel
mind that I'm not trying to convince you, just being talkative about why I have changed ECL's behavior (and Marius had a good argument afair that the more permissive interpretation seems to be more in line with the generic function dispatch as specified)
18:17:15
jackdaniel
re PR, we still need to guard against nil in initialize-instance (for sake of ESA, throw-ptype and similar), so that won't go away regardless of whether we put (ax:required :arg)
18:18:50
jackdaniel
regarding calls to floor, I think that I've just assumed that native coordinates are integers (and they are in /our/ case), so it is only natural to have sheet coordinates the same way. other than that I think that there is no reason
18:19:22
jackdaniel
except maybe for defensive programming in case, that some code in McCLIM assumes exactly that (i.e forgets to round coordinates), but I don't think there is such code in the codebase