Comment 1 Neale Upstone 2009-03-24 14:45:17 EDT

Mmm... definitely wouldn't use the word shadow, as it's yet another bit of terminology for people to use.

I think I understand perjoinpointstaticpart, as I've been doing exactly that.

Here's my use case:

My current aspect is:

public aspect CacheDbQueries
{
    // We want a different map for each join point
    private Map<StaticPart, Map<Object, Object>> m_cache = new HashMap<StaticPart, Map<Object, Object>>(); 

    Object around(Object queryItem) :
        callsToBeCached(queryItem) { ... }
}

would this become the following?

public aspect CacheDbQueries perjoinpointstaticpart(callsToBeCached())
{
    // This is now perjoin
    private Map<Object, Object> m_cache = new HashMap<Object, Object>();

    Object around(Object queryItem) :
        callsToBeCached(queryItem) { ... }
}

Comment 2 Andrew Clement 2009-03-24 16:04:38 EDT

Yes Neale, that translation to the new style is something like that.

Not sure if you read the long wordy 89009 but the upshot is that staticparts are going to have an ID shortly so that array lookups can be done instead of map lookups - to improve performance.

public aspect CacheDbQueries pertypewithin(*) 
{
    // We want a different map for each join point
    private Map<Object, Object>>[] m_cache = ... 

    Object around(Object queryItem) :
        callsToBeCached(queryItem) {
      Map m = m_cache[thisJoinPointStaticPart.getId()];
      if (m==null) { ... initialize it ... }
    }
}

Unfortunately the onus is all on the developer to manage the correct size of the array... (the pertypewithin is necessary because the array must be per advised type - since the ids start from 0 for the staticparts in each affected type.

When perjoinpointstaticpartorshadoworsomething() is working properly then all the magic will be done internally by generated code to support the instantiation model.