{'fraction_non_alphanumeric': 0.015895953757225433, 'fraction_numerical': 0.0, 'mean_word_length': 5.441860465116279, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Aspect Instances and their Interactions

Programming languages and paradigms provide mechanisms by which we can express our own solutions to problems. The way by which one formulates a solution is affected by the medium with which the solution is expressed. Currently, the lack of polymorphism and the difficulty with which aspect instances can be accessed and used within AspectJ, force programmers to resolve to less elegant solutions, introducing code tangling in advice definitions, increasing code complexity and diminishing maintainability and robustness. Through examples in AspectJ we discuss issues that relate to aspect instances, their interactions, and also the reflective capabilities of an AOSD language. We argue that any AOSD language should provide the means by which programmers can refer and manipulate aspect instances with the same ease and simplicity as with object instances in OO languages. Reflective capabilities inside AOSD languages should allow for introspection on their join point and pointcut mechanisms, allowing for the acquisition and manipulation of runtime information about these entities. We hope that by exposing these issues for discussion will allow for a better assessment of these techniques as well as a communitywide decision as to what should comprise “good” or “bad” techniques based on “proper” or “improper” use of an AOSD technology.