[YANGTOOLS-1204] Do not subclass NamespaceBehaviour in NamespaceBehaviourWithListeners Created: 13/Jan/21  Updated: 06/Apr/23  Resolved: 06/Apr/23

Status: Resolved
Project: yangtools
Component/s: parser
Affects Version/s: None
Fix Version/s: 11.0.0

Type: Improvement Priority: Medium
Reporter: Robert Varga Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to YANGTOOLS-1497 Improve NamespaceBehaviour/NamespaceS... Resolved
Epic Link: Parser Performance

 Description   

We currently allow, in theory at least, for an IdentifierNamespace to be serviced by differing behaviours. This facility is not used and realistically all behaviours are co-located with their namespaces.

All lookups are also based on FooNamespace.class, which means do not pass anything useful beyond the identifier – and ends up being quite weird to use for newcomers. The reactor than has to perform a rather expensive (in relative terms) lookup to acquire the behaviour and execute on it. There is also the annoying matter of ensuring the behaviour registry is correctly populated.

Introduce an parser.spi.meta.ParserIdentifierNamespace:

public interface ParserNamespace {

    @NonNull NamespaceBehaviour behaviour();
}

as well as an AbstractParserNamespace to form the baseline for all implementations.

Then turn all parser implementation namespaces into these, eliminating their respective BEHAVIOUR constants instread of singleton INSTANCEs. All callers need to be then converted to pass 'FooNamespace.INSTANCE' instread of 'FooNamespace.class' in their interactions.

All of reactor mechanics need to be updated to eliminate the behaviour lookup and and instead just take the behaviour from the instance.

This will eliminate a chunk of complexity, make things a bit easier to understand, but most importantly will eliminate map-based/recursive behaviour lookups.



 Comments   
Comment by Robert Varga [ 04/Oct/22 ]

A further examination reveals that there is one behaviour (SourceSpecificContext.SupportedStatements) which is implemented separately by the reactor, i.e. somewhere different than yang-parser-spi.

We need to lookup the behaviour in terms of reactor, simply because the ParserNamespace is the contract spec while the NamespaceBehaviour is the implementation of the contract.

In order to provide this sort of a direct binding all namespace declarations would need to be lifted to yang-parser-rfc7950, which would provide the definitions and implementation based on yang-parser-reactor.

This needs further thought.

Comment by Robert Varga [ 06/Apr/23 ]

So after going through YANGTOOLS-1497 this gets a lot clearer. At the end of the day, NamespaceBehaviour is the part that is defined by statements and namespaces themselves, but unfortunately it gets muddled by reactor subclassing NamespaceBehaviour for its own purposes (NamespaceBehaviourWithListeners).

What we actually need to do here is remove this subclassing and make NamespaceBehaviourWithListeners a facade backed by NamespaceBehaviours.

Generated at Wed Feb 07 20:55:28 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.