Re: RFC: Extending method specializers
- From: Slava Akhmechet <coffeemug@xxxxxxxxx>
- Date: Sun, 30 Dec 2007 02:42:50 GMT
Pascal Costanza <pc@xxxxxxxxx> writes:
You could start by restricting the predicates to the kinds ofThat's a false dilemma. For situations where priority cannot be
predicates that describe strict subset relationships, and for example,
reject a method on oddp when a method on primep already exists, or
vice versa. But this requires you to (a) either analyze the predicate
to find out what it does, or (b) restrict the predicates to a fixed
set of predefined ones.
clearly determined you could keep track of the method definition order
and evaluate the predicates in that order, selecting the first one
that passes (ML-style). You could add a protocol step and require the
programmer to specify the priority explicitly. You could even pick a
predicate based on the alphabetical order of its name :)
With a little thought, I'm sure it's possible to come up with a
practical and theoretically sound solution. This doesn't have to be
reduced to the halting problem :)
--
Regards,
Slava Akhmechet.
.
- Follow-Ups:
- Re: RFC: Extending method specializers
- From: Pascal Costanza
- Re: RFC: Extending method specializers
- References:
- RFC: Extending method specializers
- From: Leslie P. Polzer
- Re: RFC: Extending method specializers
- From: Pascal Costanza
- RFC: Extending method specializers
- Prev by Date: Re: RFC: Extending method specializers
- Next by Date: Re: macro that writes macros
- Previous by thread: Re: RFC: Extending method specializers
- Next by thread: Re: RFC: Extending method specializers
- Index(es):