[PEAK] Docstring for peak.config.modules

Phillip J. Eby pje at telecommunity.com
Wed Apr 27 11:45:18 EDT 2005


At 08:19 AM 4/27/05 -0700, John Landahl wrote:
>Phillip J. Eby wrote:
>>At 11:42 AM 4/25/05 -0700, John Landahl wrote:
>>>BTW, I've just tried module inheritance for the first time, and it looks
>>>like it could be a very powerful feature when used in moderation.  Is it
>>>considered a stable, longterm feature of PEAK?
>>No, it's a gimmicky, obscure, and deprecated one, held over from 
>>TransWarp.  Use generic functions and adaptation instead; I'm only 
>>continuing to include the feature because there are people who are still 
>>using it for a use case ("class replacement") that won't be covered 
>>another way until peak.schema lands.
>
>Class replacement (and extension) is the current use case I'm working 
>with.  The client prefers to generate substantial portions of an 
>application so the code can go to their customers without any ownership 
>issues.  The generated classes often need to be extended to provide 
>business logic and other "meat", and module inheritance simplifies this 
>dramatically.  If generic functions and adaption can be used to the same 
>effect, I'd be very interested in hearing how or seeing some examples.

Have the generated classes include generic function definitions, then 
define the methods for them in separate modules.  Then the behavior is 
entirely dependent on what modules you import.




More information about the PEAK mailing list