AOP use case? (was Re: Proposed PEP: Treating Builtins as Constants in the Standard)
Daniel 'Dang' Griffith
noemail at noemail4u.com
Wed Apr 21 07:31:15 EDT 2004
On Tue, 20 Apr 2004 10:33:36 -0400, Peter Hansen <peter at engcorp.com>
wrote:
>Daniel 'Dang' Griffith wrote:
>
>> On Mon, 19 Apr 2004 08:09:56 -0400, Peter Hansen <peter at engcorp.com>
>> wrote:
>> ...
>>>automated testing. The most easily demonstrated one is where
>>>the builtin open/file calls are replaced with a simulated ("mock")
>>>file system which applies to *all* modules, not just a single
>>>module under test. This functionality is critical to some people
>>>using Python with the Test-Driven Development approach to software.
>>
>> Isn't this the use case for AOP you were looking for?
>> --dang
>
>As you might imagine from my previous postings, I have no idea.
>I don't understand well enough what AOP really is to say,
>obviously (given my requests for compelling use cases so I can
>understand why I would even want to investigate it).
>
>Can you describe how AOP would solve this problem? As I
>understand it so far, it has nothing to do with mock objects...
Probably not.
I'm not an "AOP person", but from what I understand, you could use
an AOP-enabled language to replace the real file system (or whatever)
objects with the mock objects. This is roughly analagous to the
standard logging or auditing examples, wherein a program is doing what
it needs to do, meanwhile a cross-cutting aspect intercepts certain
operations and performing additional, or different, operations.
--dang
More information about the Python-list
mailing list