Generate dot notation OIDs - Part 2

Following last post, there are few corrections are required both in term of accuracy and correctness.

1. Transmission OID
I referred Object Identifier transmission as 0.3.6.1.2.1.10, this clearly wrong as the correct reference is "1.3.6.1.2.1.10". This is due to dependency module RFC1155-SMI from RFC 1155 does not provide an oidnum for "iso".


RFC1155-SMI.txt

        -- Next original line is commented out for simpler syntax
 -- internet      OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
 iso           OBJECT IDENTIFIER ::= { 0 }
 org           OBJECT IDENTIFIER ::= { iso 3 }
 dod           OBJECT IDENTIFIER ::= { org 6 }
 internet      OBJECT IDENTIFIER ::= { dod 1 }


Earlier I have mistakenly associate iso as '0' hence the error. This should fix it.


RFC1155-SMI.txt

 iso           OBJECT IDENTIFIER ::= { 1 }

Now this produces following output:



2. MIB terminology
Referring dot notation oid string as "Dotted Oid" is not accurate as oid generally refers to dot notation itself, hence again I modified the feature name to just refer it as "Oid" (refer to image above)

Mib.xcore

class OidValue {
 refers Identifier parent
 int oidnum
 derived String oid get {
  var p = parent
  var doid = oidnum.toString
  while (p != null) {
   doid = p.value.oidnum + "." + doid
   p = p.value.parent
  }
  doid
 }
}

Another thing worth to mention here is the usage of Xcore. Xcore is an alternative to common Ecore editor with additional behaviour definitions (class method, derived feature).

TODO: However in above example "derived String oid get {..}", my initial impression was oid is lazy initialization that is set when getOid() is called, however this is not the case - from the generated code, the oid feature does not exist at all, its purely a method that does the calculation every time its called. Therefore the advantage of this "derived String oid get {..}" vs "op String getOid {..}" is the former available within the class feature.

OidValueImpl.java

 @Override
 public Object eGet(int featureID, boolean resolve, boolean coreType) {
  switch (featureID) {
   case MibPackage.OID_VALUE__PARENT:
    if (resolve) return getParent();
    return basicGetParent();
   case MibPackage.OID_VALUE__OIDNUM:
    return getOidnum();
   case MibPackage.OID_VALUE__OID:
    return getOid();
  }
  return super.eGet(featureID, resolve, coreType);
 }

Hope there is a way to make it work as lazy initialization. However, understandably lazy initialization is not going to be an easy implementation, as notification mechanism should be considered as well i.e any change to referent object should re-trigger the evaluation.

TODO2:  How does this set works i.e "derived String oid set {..}"? how do we access the parameters?