Updates to RoslynDom 1.0.9 Alpha

New Parent property on all items

IDom now contains a Parent property of IDom type

In any tree things can become, well interesting, if nodes appear in more than one location. This is particularly damaging in a tree that takes characteristics from context – which happens with naming (namespaces and nested classes) in the .NET class model. Thus, by intent, no item may appear in more than one location in the tree.

When a member is cloned, its parent is not copied with it. Also, parent and parent properties are not used in determining same intent.

Real-time Namespace property

Previously, Namespace was stored from the symbol when the instance was created. Because Namespace is contextual, this was incorrect. Namespace is now calculated from the parent hierarchy when the namespace is requested for all classes except RDomReferencedType. This resulted in some changes in Namespace results, including the result from

Namespace testing.Foo

Which previously returned Foo and now returns testing.Foo.

The Namespace in RDomRefernecedType is the namespace of the type being referenced, so is still retrieved from the symbol on load.

AddOrMoveMember and RemoveMember methods

Methods to add members to containers have been added to new IRDomStemContainer, IRDomTypeContainer and IRDomCodeContainer interfaces.

As discussed under the heading “New Parent property on all items,” IDom items may not appear in more than one location in the tree. The AddOrMove semantics reflect this. I actually think moving will be a rare task, but if you accidently add an item to a new location in the tree, RoslynDom will remove it from the prior location and I wanted naming to clarify this.

I may add an “AddCloneOfMember” to simplify the process of cloning a member and adding it to a new location after changes. This is the anticipated use case.

ICodeContainer and ICodeMember interfaces

There are new ICodeContainer and ICodeMember interfaces. Support for intra-member features (code) remains almost non-existent in this version.

RawItem and OriginalRawItem semantic changes

RawItem and the new OriginalRawItem on the IDom interface represent the underlying data in an agnostic way. IDom is agnostic on mutability so there may be future implementations where RawItem and OriginalRawItem are always the same. I want the semantics to be clear that RawItem is the best current capturing of the tree, and OriginalRawItem is the original unchanged item. This intentionally implies that the original must be maintained.

TypedSyntax and OriginalTypedSyntax are the RDom implementations of these generalized ideas.

AddMember method added to RDomStemContainer and RDomBaseType

To support mutability, AddMember methods were added to these two base classes. This makes the ability to add types and type members available to appropriate types, namespaces, and the root.

Changed return of PublicAnnotationList.GetValue(string key)

Previously this returned the default value, which blocked access to other values. It now returns the PublicAnnotation. The default value remains accessible by GetValue(name, name).

Changed PublicAnnotation to a Class

PublicAnnotation was a struct. This was the only struct in the system and I felt the value/reference semantic difference would be detrimental to maintenance. As part of this, I removed the equality testing and added a SameIntent method.

Added IHasSameIntentMethod interface

Another characteristic interface was added for the SameIntent methods. This is for consistency with other characteristic interface usage.

Moved SameIntent to a subsystem in RoslynDom.Common

This code may eventually run with a DI, but for now, if the interface data matches, they match.

Changed SameIntent method type parameter

Previously the SameIntent method appeared on the strongly typed IDom<T> interface and could only be called on items of the same type. This was overly restrictive, so the method was changed to have a local strongly typed parameter, constraint only to be a class. Comparing different IDom types of the current implementations will always return false, although it is possible that a derived class could be created that had different behavior, but the same intent, as one of the existing implementation classes, and could therefore return true as the same intent. This was also done to support scenarios where the type is not known, such as public annotations that might be IDom types.

Changed inheritance semantics of SameIntent() method

The previous inheritance semantics of the SameIntent method were to directly override the public SameIntent method. This method is no longer virtual. Instead override the CheckSameIntent protected method. Be sure to call the base CheckSameIntent method for correct behavior.

SameIntent and names

Type members (fields, properties, methods and enum) do not include outer name when considering same intent.

Stem members (types, namespaces) do not include namespace/qualified name in same intent.

Added IHasLookupValues interface

Added this interface to reduce dependencies in an upcoming project.

Virtual Matches method added to IDom

Immediately this allows CheckSameIntentChild to better find the other child to compare to. It also provides a generalized way to find items in a list.

Changed name of RDomTypeParameter. HasReferenceTypeConstraint

Was previously HasReferenceConstraint. Changed for consistency. Also changed ITypeParameter

Changed name of MemberKind, StemMemberKind and LiteralKind

The suffix “type” is confusing. Switched these enums and property names to “kind”


Implementation of syntax recreation from changed nodes is begun, not complete.

Internal cleanup

– Separated RDomBase classes into separate files

– Created SameIntentHelper

– Changes to how IHasNamespace properties are stored and used

– IHasNamespace moved from IStemMember to IType and INamespace

– IUsing now includes IStemMember

– StemMembers property of Namespaces and Root now include usings

– Fixed some bugs in RDomField attributes

Leave a Reply

Your email address will not be published. Required fields are marked *