[aspectc-user] Improvements for reference documentation around AspectC++ 2.0?

[Markus Elfring]

> thanks for pointing out these deficiencies in the language reference!

Dear Olaf,

Thanks for your quick response.


> However, we longer have this restriction.

Do you mean "… we do not have this restriction any longer" eventually?

How do you think about to provide a documentation format selection
like it is offered for various GNU software?


> The version number on the cover page refers to the documented ac++ version,

Yesterday I missed the display of this cover page while reading the document
by the program "evince 3.18.2-1.2" while it seems to work as expected for
the updated variant today.


> while the date reflects the version of the document.

To which "date" do you refer here exactly?

I suggest to reconsider this detail under the constraints for reproducible
software builds.


> We normally don't have more than one update per day.

Will an other revision identifier (or commit hash) be more appropriate
for this document?


> I made an update and removed the whole sentence.

Thanks for your correction.


> Referring to a manual that hasn't been written yet is pointless.

I wonder then why a broken link was released together with
a corresponding footnote.


>> 6. How do you think about to start each chapter on a new page?
> 
> This a matter of the latex style we use. I'm not sure if that would
> really look nicer. For instance, the chapter "1 About" is very short.

I imagine that it is easier to reference each chapter when they get
a distinct start page
Would you like to perform any fine-tuning for page breaks of a few chapters?


>> 8. I am particularly interested in the handling of various functions.
>> * Would it be a bit more appropriate to refer to the identifier "MemPool::alloc"
>>   in the section "Example: function matching"?
> 
> In contrast to checking whether dealloc is called with a NULL-pointer
> argument we could also check alloc is with a size of 0. However, the
> difference doesn't matter much, right?

It seems that you have got another adjustment in mind.


> Or did I miss the point here?

The shown name pattern caught my attention there. How likely is it
that the identifier "dealloc" will be connected with a function
which will eventually return a null pointer?


>> * Can an advice become context-dependent?
> 
> What do you mean by "context-dependent"?

Can the advice source code be adjusted according to specific attributes
or variables?


> Something like the "if" pointcut function in AspectJ?

I am unsure on this detail.


> At the moment AspectC++ is ignoring attributes, which is for some platforms
> a bit dangerous, because (gnu) attributes can affect parameter types.

I am curious on how the software will evolve further around such
implementation details.


>> * Is it possible to adjust a specific source code change by taking the function
>>   call hierarchy into account?
> 
> Not yet. The problem is that ac++ sees a single translation unit only,
> which contains only a fraction of the call graph.

Can the situation be handled when only a function call hierarchy needs to be
considered from a single translation unit?

Use case:
Can your software determine if a function belongs to the implementation
of a signal handler?
How can a property like "asynchronous signal safety" be integrated with
aspect-oriented software development?


> However, we are working on that already.

Good to know.


> There is only one useful library at the moment, which is JPTL
> (Joint-Point Template Library).

Is there any interest growing to improve the situation any more around
libraries for pointcuts, advices and aspects?

Regards,
Markus