nBNF - Mismatching AST identifiers at code import

[RIL]

Ok, now I'm mastering picking up from Go-source code most of what I want to pick up (skipping body code).  The next step would be to convince EA to start liking the AST I managed to create. :)

I made an MDG technology with the nBNF an all that stuff, which indicate no errors so its OK, but on import EA only recognizes a "class"/struct "WebServer" from my test source code below, and it also makes a model class in a class diagram of it (see also the AST in the next post which is parsed from the source code below).  

On code import no (Model) PACKAGE is created (expected "Server"), and
no IMPORT clauses are imported (four lines in "import (...)", and
no METHODs are imported (and thus not added as members either), and
no PARENT classes are created (called embedding in Go, superclass(es) in OOP),
no members whatsoever were recognized.

So the AST structure below is obviously wrong, but how should the main nodes be organized and named in order for EA to be able to pick the correct identifiers up as to create a model from it?

Code: [Select]

package Server

import  (
      "fmt"
      "../LingualDomain"
      mux "github.com/gorilla/mux"
      "net/http"
)

var UnitVariable string, v int,
      row2 bool

type WebServer struct {
      AmObject
      sys.AmObject
      EA__STEREOTYPE string
}


Code: [Select]

func  Init() {
}      


Code: [Select]

func (self *WebServer) GetHandler(w http.ResponseWriter, r *http.Request) {
}      

func (self *WebServer) PutHandler(w http.ResponseWriter, r *http.Request) {
}      

func (self *WebServer) PostHandler(w http.ResponseWriter, r *http.Request) (bool, *TType) {
}      

func (self *WebServer) TestParamA() TypeA1 { }
func (self *WebServer) TestParamB() (TypeB1) { }
func (self *WebServer) TestParamC() (TypeC1, *TypeC2, TypeC3) {
}      
func (self *WebServer) TestParamD() (nameD1 TypeD2, nameD2 *TypeD2, nameD3 TypeD3) {
}      


Code: [Select]

func  Main() {
}      
(Although Init() and Main() are not true members of struct WebServer I'd still like to draw them as member methods, but stereotype them as <<proc>> in order to generate them as package level funcs instead (as the source code looks above) .

Anyway, the AST parsed from the above source code is posted in a separate post.

So with some pointers about how a correct(ed) AST structure should look (and correct node names), I'll be able to fix the rest, I think.

// Rolf Lampa

[RIL]

And the AST (note that not all code is "meaningful" other than as testcode for stressing the AST parsing to recognize the syntax):

(The code below was harvested via screenshots and OCR, so misspellings may exist)

Code: [Select]

FILE([0-4022][0:0])
- PACKAGE([0-4022] [1:1])
      NAME([8-14][1:9]): {NAME = Server)
      IMPORT([597-682][19:1])
            PACKAGE ([609-614] [20:2]): {NAME =
            PACKAGE([617-635][21:2]): {NAME = '../LingualDomain')
            PACKAGE([638-666] [22:2]): {ALIAS = mux, NAME = 'github.com/gorilla/mux’>
            PACKAGE([669-679][23:2]): {NAME = 'net/http'}
      VAR([686-729] [26:1]): {NAME = UnitVariable, TYPE = string, NAME = v, TYPE = int, NAME = row2, TYPE = bool>
      - CLASS([733-1309] [29:1])
            NAME([738-747] [29:6]): {NAME = Webserver)
            PARENT([759-767][30:2]): {NAME = AmObject)
            PARENT([770-782][31:2]): {NAME = sys.AmObject)
            PARENT([785-799] [32:2]): {NAME = EA_STEREOTYPE)
            PARENT([800-806] [32:17]): {NAME = string)
            DESCRIPTION([ 1308-1308] [43:1])
      - METHOD([1573-1636][52:1])
            - DECLARATION([1573-1636][52:1]): {NAME = Init)
                  BODY([1635-1635][54:1])


Code: [Select]

     - METHOD([1684-2342] [57:1])
            - DECLARATION([1684-2342][57:1]): {NAME = GetHandler)
                  TYPE([1690-1705] [57:7]): {NAME = self, QUALIFIER = "Webserver)
                  PARAMETER([1718-1739][57:35]): {KIND = in, NAME = w, TYPE = http.ResponseWriter)
                  PARAMETER([1739-1756][57:56]): {KIND = in, NAME = r, TYPE = "http.Request)
                  BODY([1790-2339][59:2]): {CODE = ... }
      - METHOD([2372-3030][77:1])
            - DECLARATION([2372-3030][77:1]): {NAME = PutHandler)
                  TYPE([2378-2393][77:7]): {NAME = self, QUALIFIER = "Webserver)
                  PARAMETER([2406-2427][77:35]): {KIND = in, NAME = w, TYPE = http.ResponseWriter)
                  PARAMETER([2427-2444] [77:56]): {KIND = in, NAME = r, TYPE = "http.Request)
                  BODY([2478-3027][79:2]): {CODE = ...}
      - METHOD([3061-3232] [97:1])
            - DECLARATION([3061-3232] [97:1]): {NAME = PostHandler)
                  TYPE([3067-3082] [97:7]): {NAME = self, QUALIFIER = "Webserver)
                  PARAMETER([3096-3117][97:36]): {KIND = in, NAME = w, TYPE = http.ResponseWriter)
                  PARAMETER([3117-3134][97:57]): {KIND = in, ffAME = r, TYPE = "http.Request)
                  PARAMETER([3137-3141][97:77]): {KIND = returft, TYPE = bool)
                  PARAMETER([3143-3149] [97:83]): {KIND = return, TYPE = "TType)
                  BODY([3155-3229] [98:2]): {CODE = ... }


Code: [Select]

     - METHOD([3237-3283] [102:1])
            - DECLARATION([3237-3283] [102:1]): {NAME =TestParamA)
                  TYPE([3243-3258] [102:7]): {NAME = self, QUALIFIER = "Webserver)
                  PARAMETER([3273-3279][102:37]): {TYPE = TypeAl)
                  BODY([3282-3282] [102:46])
      - METHOD([3285-3333] [103:1])
            - DECLARATION([3285-3333] [103:1]): {NAME =TestParamB)
                  TYPE([3291-3306] [103:7]): {NAME = self, QUALIFIER = "Webserver)
                  PARAMETER([3322-3328l\103:381): {KIND = return. TYPE = TypeB1)
                  BODY([3332-3332][10 ...]
      - METHOD([3335-3401] [104:1])
            - DECLARATION([3335-3401] [104:1]): {NAME = TestParamC}
                  TYPE([3341-3356][104:7j): {NAME = self, QUALIFIER = "Webserver}
                  PARAMETER([3372-3378] [104:38]): {KIND = return, TYPE = TypeCl}
                  PARAMETER([3380-3387] [104:46]): {KIND = return, TYPE = *TypeC2}
                  PARAMETER([3389-3395][104:55]): {KIND = return, TYPE = TypeC3>
                  BODY([3400-3400] [105:1])


Code: [Select]

     - METHOD([3404-3491] [106:1])
            - DECLARATION([3404-3491] [106:1]): {NAME = TestParamD}
                  TYPE([3410-3425] [106:7]): {NAME = self, QUALIFIER = "Webserver}
                  PARAMETER([3441-3454] [106:38]): {KIND = return, NAME = nameDl, TYPE = TypeD2>
                  PARAMETER([3456-3470][106:53]): {KIND = return, NAME = nameD2, TYPE = "TypeD2>
                  PARAMETER([3472-3485] [106:69]): {KIND = return, NAME = nameD3, TYPE =TypeD3>
                  BODY([3490-3490] [107:1])
      - METHOD([3579-4022] [111:1])
            - DECLARATION([3579-4022] [111:1]): {NAME = Main}
                  BODY([3596-4019][112:2]): {CODE = ... }

Obviously I have used the wrong IDENTIFIERS in this AST since EA doesn't interpret them as expected on source code import.

[Eve]

At a quick look I see the following problems:

Imports aren't generally used much by EA (only for assistance in linking), but I think you'll need to break that into multiple import nodes.

Your methods don't have anything identifying the class they belong to. Work on the part of your grammar that creates the TYPE node. I think you only want Webserver to be in a QUALIFIER attribute. Having said that, I'm still not sure that EA will pick up the methods because at least for C++ it only looks for a method outside the class if it's already found the matching part in the class body.

If you eventually want to use this for code synchronization, you'll need to move the BODY node outside of the DECLARATION node. If you don't, EA will replace it every time you generate which defeats the purpose.

[RIL]

At a quick look I see the following problems:
Imports aren't generally used much by EA (only for assistance in linking), but I think you'll need to break that into multiple import nodes.

I tried that, but no Imports show up anyware:

Your methods don't have anything identifying the class they belong to. Work on the part of your grammar that creates the TYPE node. I think you only want Webserver to be in a QUALIFIER attribute.

Yes, from the spec I found that the QUALIFIER occur only in a TYPE node, yes. The TYPE node in turn had NAME and QUALIFIER attributes. Removing the NAME-part didn't seem to help.

Having said that, I'm still not sure that EA will pick up the methods because at least for C++ it only looks for a method outside the class if it's already found the matching part in the class body.

As shown on the image above, I removed the NAME-part and kept only QUALIFIER (= "WebServer"). No go.

I also placed BODY outside the METHOD, then imported again:



But no signs of trying to import the items I want.

If you eventually want to use this for code synchronization, you'll need to move the BODY node outside of the DECLARATION node. If you don't, EA will replace it every time you generate which defeats the purpose.

Yes sir, already done, sir.

To sum up: With the above (modified) AST structure EA doesn't succeed (or even try?) importing the Package ("Server"), the Import clauses, although it DOES import the two classes (I added type AmClass to the source) it doesn't understand Superclass and it doesn't recognize Attributes or Methods.

I also tried to moving the METHOD nodes to be embeded in the CLASS instead of the PACKAGE level, but that might have been entirely wrong.

I might have missed or misunderstood something in your post still, but the "binding" of the method to the class in Go seems fairly close to how the owning class is laid out in Pascal for example:

Golang: func  (c OwningClass) Name(param type) ReturnType { /*body*/ };
Delphi: function TOwningClass.Name(param type) TReturnType begin (*body*) end;[/list]
It seems there's still something basically wrong in the AST structure shown above. If I didn't misread your post in this late hour (02:10 am).

Is there perhaps any other documentation on this which I could read in order to advance? Any help would be very much appreciated.

// Rolf

[RIL]

Hm, I moved PARENT and METHOD declarations into the CLASS' BODY node (see AST far below), and then things started to happen.  Now I got this import result:



This definitely means progress. Still no Package, no Imports, and some details looking somewhat misplaced, but now there's hope.

The AST:


Edit:
Although the methods Init() and Main() doesn't "naturally" belong to the class WebServer (since the code speaks of no "binding class") I think that an artificial binding could (perhaps) be tweaked by using special info in a preceding comment as to serve as a "binding", perhaps something like this:

// [EA:(OwningClass *WebServer):/EA]
func Main() {
    ...
}[/list]

[Eve]

I tried that, but no Imports show up anyware:

As I said, they won't be used by EA except for linking classes to the appropriate namespace.

Yes, from the spec I found that the QUALIFIER occur only in a TYPE node, yes. The TYPE node in turn had NAME and QUALIFIER attributes. Removing the NAME-part didn't seem to help.

To be fair, I haven't looked at the documentation, but I do know it needs to be like that.

For a C++ method I get:
 + METHOD(...)
    + DECLARATION(...): {TYPE = int, QUALIFIER = ClassName, NAME = MethodName}
       + PARAMETER(...): {TYPE = int, NAME = a}

[RIL]

For a C++ method I get:
 + METHOD(...)
    + DECLARATION(...): {TYPE = int, QUALIFIER = ClassName, NAME = MethodName}
       + PARAMETER(...): {TYPE = int, NAME = a}

I have a problem understanding what "Type" refers to in the DECLARATION part. It could be interpreted as "return Type" but shouldn't that be an [out]  or [return] PARAMETER, like so:

+ PARAMETER(...): {KIND = return, TYPE = int, NAME = a}

// Rolf

[Eve]

Yes, it's return type.

UML creates it as a return parameter, but to most programming languages (at least those supported by EA) it is distinct and the parser handles it as such.