Search
Wednesday, 19th of September 2018, 14:29:38 UTC
14:30:23
jackdaniel
or we can define these methods so the other argument is specialized on region
14:30:38
jackdaniel
I'm not clos expert, so I don't know what would be a clean solution in this scenario
14:31:08
jackdaniel
I'd go after specializing unspecialized argument on region
14:31:30
slyrus1
I'm inclined to specialize on both drei-areas.
14:31:43
jackdaniel
as of sbcl bug, I don't know sbcl's internals well enough to investigate
14:31:56
slyrus1
and I can't reproduce it at the moment :)
14:32:07
slyrus1
I'm sure it will show up soon enough though.
14:32:08
jackdaniel
sure, when you specialize on both areas you may get somewhere, but you'll still have an abstraction leak
14:32:30
jackdaniel
(region-union my-standard-rectangle my-drei-area) will use general sepcialization *again*
14:32:56
jackdaniel
I need to wash dishes now, I'll be back later
14:33:16
slyrus1
It strikes me that maybe calling region-union on the drei-area it self is bogus and maybe it should be fixed at the call site.
14:33:38
slyrus1
OK, let me know if you have thoughts on an acceptable solution.
14:34:48
jackdaniel
as I said, *working* solution would be adding specialization on region for unspecialized arguments
14:50:15
slyrus1
jackdaniel: Ok, so just change the method signatures to: ((region1 drei-area) (region2 region)) and vice versa? That seems to fix the problem.
15:37:10
slyrus1
should these be explicit calls to e.g. region-union or should we use call-next-method?
15:40:26
slyrus1
and should we apply the same logic to region-intersection and region-difference?
15:50:06
jackdaniel
and if there are unspecialized arguments in drei for region-* methods, then yes
16:06:20
slyrus1
jackdaniel: PR submitted. thanks!
Thursday, 20th of September 2018, 2:29:38 UTC