Re: Method combination and ASDF

2024-04-23 Thread Faré
What are the methods defined by asdf-flv?

IIRC, POIU also has a few :around methods (it also doesn't properly support
ASDF 3.3 phases).

-#f


On Tue, Apr 23, 2024, 17:24 Robert Goldman  wrote:

> An issue that came up discussing ASDF-FLV with Didier has to do with
> outside modification to exported ASDF generic functions. I think it's
> unambiguously reasonable to say "if you mess with unexported functions,
> generic or otherwise, you're on your own, and could break things
> arbitrarily."
>
> But I don't think ASDF has established clear expectations about extending
> methods of exported ASDF generic functions. I think there's been an
> unspoken assumption that if ASDF generic functions are to be extended,
> particularly by :around, :before, and :after methods, there should be
> some novel class introduced that will be used to select extensions. So, for
> example, it's fine to wrap or write new methods for perform, but not for
> existing component and operation classes. Doing so means that a change one
> might think appropriate for one's own library bleeds out into other code
> that one has no way of predicting, and also has the potential to collide
> with ASDF's own code or other people's ASDF extensions.
>
> Those are good reasons for this convention -- no modification without
> introducing new classes for method dispatch -- but ASDF-FLV is an example
> of a system that wants to introspect about the entire running lisp image.
> I'd be interested in hearing what people think about this kind of case.
> Should we introduce, for example, an ASDF object that extenders could add
> mixins to in order to enable modifications to ASDF behavior that aren't
> limited to a single library?
>
> Please post any thoughts you have about this idea.
>


Method combination and ASDF

2024-04-23 Thread Robert Goldman
An issue that came up discussing ASDF-FLV with Didier has to do with 
outside modification to exported ASDF generic functions.  I think it's 
unambiguously reasonable to say "if you mess with unexported functions, 
generic or otherwise, you're on your own, and could break things 
arbitrarily."


But I don't think ASDF has established clear expectations about 
extending methods of exported ASDF generic functions.  I think there's 
been an unspoken assumption that if ASDF generic functions are to be 
extended, particularly by `:around`, `:before`, and `:after` methods, 
there should be some novel class introduced that will be used to select 
extensions.  So, for example, it's fine to wrap or write new methods for 
`perform`, but not for existing component and operation classes.  Doing 
so means that a change one might think appropriate for one's own library 
bleeds out into other code that one has no way of predicting, and also 
has the potential to collide with ASDF's own code or other people's ASDF 
extensions.


Those are good reasons for this convention -- no modification without 
introducing new classes for method dispatch -- but ASDF-FLV is an 
example of a system that wants to introspect about the entire running 
lisp image.  I'd be interested in hearing what people think about this 
kind of case.  Should we introduce, for example, an `ASDF` object that 
extenders could add mixins to in order to enable modifications to ASDF 
behavior that aren't limited to a single library?


Please post any thoughts you have about this idea.

signature.asc
Description: OpenPGP digital signature