Improve support for Swift language

[Andrea-Scuderi]

1. Some Swift language entities and properties are missing

• Swift entities are the following: class, struct, protocol, enum

• Swift properties can be: var, let

• Missing implementation: protocol, enum, let

2. Swift Entities dependencies are not evaluated when used as static

example:

class A {
 static let shared = A()

 func doSomething() {
  print("A")
 }
}

class B {
 func doSomethingWithA() {
  A.shared.doSomething()
 }
}

The class B depends from A, but the relation is not implemented in the output.

Proposed output

Consider the following valid swift example:

protocol Naming {
    var name: String { get set }
}

protocol Describing {
    var describing: String { get }
}

class ClassA: Naming & Describing {

    static let shared = ClassA()

    var name: String = "A"
    let id: UUID = UUID()
    var describing: String = "Class A"
}

class ClassB: ClassA {
    func show() {
        print(name)
    }
}

enum EnumA {
    case one
    case two(EnumB)
}

enum EnumB: String, Describing {
    case one
    case two

    var describing: String {
        self.rawValue
    }
}

struct StructC<T: Naming>: Describing {
    var name: String = "C"
    let state: EnumA = .one
    var generic: T

    var describing: String = "Class C"

    init(generic: T) {
        self.generic = generic
    }
}

public struct EmergeSwiftTest {
    public private(set) var text = "Hello, World!"

    var b = ClassB()
    let eB: EnumB = .one
    let eA = EnumA.two(.one)

    func show() {
        b.show()
        print(ClassA.shared.name)
    }
}

actual output:

desired output:

• Naming doesn't depend from other entities
• Describing doesn't depend from other entities
• ClassA depends on Naming, Describing
• ClassB depends on ClassA
• EnumA depends on EnumB
• EnumB depends on Describing
• StructC depends on Naming, Describing, EnumA
• EmergeSwiftTest depends on ClassB, EnumB, EnumA, ClassA

note:

• String and UUID are ignored in this context as they should appear as dependency on the Foundation framework

I've prepared a version solving the point 1. Happy to do a PR if you are interested. Not sure how to sort out point 2 though.

[glato]

Hi @Andrea-Scuderi 👋, thank you for the interesting ideas and enhancements, I'd appreciate any contribution and help. If you've already prepared a PR to solve point 1, I'd be happy to review/test/merge your solution. I'll try to come up with an approach for point 2 in the following days.

[glato]

@Andrea-Scuderi I've merged your PR #13, will try to follow up on an approach for point 2 in a couple of days.

[Andrea-Scuderi]

Thanks! Actually there is also another nasty case, nested entities: https://docs.swift.org/swift-book/LanguageGuide/NestedTypes.html

[glato]

@Andrea-Scuderi I've been doing some updates on the swift-parser and the modularity metric in general. The next release (together with your last contribution) will have some more Swift enhancements and bugfixes, stay tuned. A small teaser: 1 Swift project, 5 different graph types with different modularity.

[glato]

@Andrea-Scuderi The last release 1.1.0 includes your swift enhancements with further, smaller bugfixes related to parsing and graph types. Hence I'm closing this issue. Nevertheless we still have no support for nested entities. Either we probably would have to define the pyparsing syntax in another way to match such recursive structures or find another way to extract them. This could be a more complex issue, but I'll try to think about some approach to deal with this.

[glato]

@Andrea-Scuderi we could of course also work together in a follow up issue to solve this 💪?