BMM_PACKAGE_CONTAINER has attribute scope with type BMM_PACKAGE_CONTAINER

Specifications BMM/Expressions
1

Hi Thomas, I was, just for hobby (I am retired), looking at the BMM-specs and I found the issue which is in the title of this message: BMM_PACKAGE_CONTAINER has attribute scope with type BMM_PACKAGE_CONTAINER

I think this cannot be right, because how would a compiler compile a recursive attribute?

I looked at the BMM-code from Pieter Bos, and he worked around it by leaving the attribute out

I avoided problems by using an interface at that point

Thanks, when you have time to answer this question.
Have a nice day

Bert Verhees

2

Hi Bert,
that scope attribute will be inherited into BMM_MODEL and BMM_PACKAGE. BMM_PACKAGE can have scope of either type, so it is correct for this. BMM_MODEL scope is set to ‘self’ (i.e. it really has no other scope)

There may be a better way to do this for Java though…

3

Most people think of function-recursion when they discuss recursion. But there is also class-recursion, and that is the case here.

I don’t know if it really makes sense what I write below.

Java is the easy way, it grabs the classes on runtime. Maybe it could get in problems in in recursion, when the code digs into it.

I don’t know why Pieter left out the scope attribute. Maybe his code can live without this attribute.

There are some compilers, which can get in problems during compile-time, because they can dig into the structures during compilation. Especially when they have no maximum recursion depth. This is the case in the C++ compiler, and the Go compiler simply does not seem to allow recursion. Maybe it can get tricked

Using an interface is a solution, because in many ecosystem it is often a pointer to an object. So there is not a memory-space for object created to use as the attribute, but there is pointer to an object, which is created outside the current object.

So it could also be a pointer to the calling object,

This would be the safety against exploding code,

4

I started to code the latest BMM model in Kotlin, on hold for the moment. But it will be interesting to see what problems might arise. Happy to share the code if you are interested.

5

Yes, reading your code would be very nice.

I am coding it in Golang, which is not a OOP-language, but it build in composing of parents-structs (classes) into child-structs, which is in effect very similar to OOP

I think that the problem is that modeling does not think in interfaces, but in real classes, and that scope (which is BmmPackageContainer) is an obligatory attribute in BmmPackageContainer which would be an endless chain if not an interface or pointer

I have been wondering about this a few days, would it be a short-coming of Golang (it has more from OOP-perspective) or is it really a problem, and strictly logically, it is a problem

But it is not a big deal, there are several technical workarounds

You can find my code in my github-repository under the name SemanticalDatabase (hope that is good english), but the code is far from ready, and there are many unfinished experiments in it.

But now I found the way to do it, and I am doing it in BmmModelElement and BmmPackageContainer (the rest is going to be rebuild, coming weeks, every day an hour or two hours)

Best regards
Bert Verhees

1 Like