RE: aspectclass interface/target idea

I've been thinking about supporting something like this. It's not very
hard to implement actually. For example the using the new
configuration-system (or if you're just using the core-classes) it's
possible to subclass MixinInstance which would open up for customizing
things like this by overriding an invoke-method. I've even considered
turning AspectInstance and MixinInstance into interfaces to allow for
completely different implementations for different purposes (for example
optimizations for speed or for memory footprint and so on). But that
might add some unnecessary complexity.




> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On 
> Behalf Of Steve Conover
> Sent: Monday, March 03, 2003 5:03 PM
> To: nanning-developer
> Subject: [Nanning-developer] aspectclass interface/target idea
> 
> 
> About this main target problem...I think our discussion left 
> off with Jon saying that making it so the main target didn't 
> have to implement the aspectClass's interface was too EJB-ish.  
> 
> The fundamental challenge is to get people to fulfill their 
> contracts. 
> OTOH, since we have these mixins, it seems a little strange 
> to force the main target class to implement ALL methods of 
> the main aspectClass interface.  
> 
> So any methods defined by the aspectClass's interface should 
> be implemented by a target (and maybe you could even go 
> further and say "should be implemented once and only once").  
> Couldn't we have some sort of static check when Nanning is 
> first loading these classes, to makes sure the target classes 
> actually do implement all necessary methods?
> 
> Of course, you could get around this and swap out your 
> targets later on
> - that is unless we test the new target class to make sure it 
> implements the same methods as the old one.  Does anyone 
> think this behaviour would be too restrictive?  I don't think 
> it would have much of a performance impact.  You wouldn't 
> really catch problems at compile time, but you'd almost 
> certainly see them at the beginning of runtime.
> 
> Another idea - you could choose between the current behavior 
> and the behavior I'm proposing.  Maybe not realistic given 
> the implications, I'm not sure.
> 
> -Steve
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more 
http://taxes.yahoo.com/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Nanning-developer mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/nanning-developer



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com