Creating artefacts from another artefact's init method

[igorcadelima]

Hey everyone,

What I should do to create artefacts from another artifact's init method? In my project file I'm creating a workspace with an artefact A, which should create other artefacts when it's created. Is it possible to do that?

I've seen some examples showing how to create artefacts from inside operations but not from the init method. Calling makeArtifact from init raises cartago.OperationException.

Cheers.

[igorcadelima]

I just found a way to work around this by moving the artefacts creation to an internal operation which is called from the init method. I still appreciate any explanation about this though.

Cheers.

[igorcadelima]

I realised that the problem happens because no opFrame is set in the Artifact class when calling makeArtifact. Then, when creating the second artefact from the first's init method, the current operator is tried to be got in order to set the creator agent id, but, as opFrame is null, an exception is thrown.

@aricci303 why isn't opFrame also set when calling makeArtifact? This has been causing other problems, such as https://github.com/CArtAgO-lang/cartago/issues/2.

Cheers.

[aricci303]

Hello Igor. Some useful premises before answering you:

• Artifacts are not (simply) OOP objects, the level of abstraction is different. They can be considered "objects" but for being used by "agents", so at the agent level of abstraction. Current meta-model has been intentionally kept very simple to capture the key points of the "artifact" abstraction (vs. agent one). Indeed, many interesting extensions can be explored, taking inspiration by OOP. For instance: inheritance. The point is that every feature possibly inspired by OOP should be properly "recast" and framed at the proper level of abstraction.

• Even if the basic CArtAgO API are in Java, artifacts are not meant to used and deployed like normal objects in OOP, and then also used by other objects of an OOP application. When this is necessary in order to exploit and reuse existing OOP libraries/frameworks, a specific discipline and API should be used (based on beginExternalSesssion/endExternalSession public methods).

• The "visibility" model for artifacts is slightly different from OOP's one): -- @OPERATION can be requested by any agent -- @INTERNAL_OPERATION only by the artifact itself -- @LINK operation can be executed by other artifacts

After this premise:

• ABOUT ARTIFACT CREATION AND init. -- Intentionally artifacts can be created only by agents or other artifacts and are not meant to be created like simple objects with "new" -- the init() method is used to handle artifact construction and intentionally is not an operation, that is: it has not an operation context, it cannot be suspended, so e.g. it cannot request the execution of other operation on other artifacts. -- if you want to do it, you need to define your "setup" operation (or alike), as a normal artifact operation

-- Default constructors have been intentionally designed to enforce this discipline and are not meant to be called directly.

• ARTIFACT INHERITANCE AND PATTERNS

The introduction of further mechanisms for promoting artifact extension/reuse as well as composition is interesting and important, however any proposal should be "compatible" with the basic set of principles described above. Or, it could drive a change and an improvement of such basic principles, after showing the benefits.

Patterns creating/treating artifacts like objects should be rethought and possibly described at the proper level of abstraction. It is worth noting that differently from classic OOP patterns (design or not), patterns in AOP supported by agents & artifacts may have 2 abstractions on the scene: agents and artifacts - not just single (passive) one (i.e. objects).

-

It would be great then if you could try to (re)formulate your interesting points and proposals given the conceptual framework above.

Cheers /A

[igorcadelima]

Thanks for pointing out these premises, @aricci303 !

I believe that what I've "proposed" wrt visibility modifiers is still applicable and compatible with the current model.

1 - Assuming that @INTERNAL_OPERATION should be similar to the protected keyword in Java, it's actually buggy. Derived artefact classes should be able to override internal operations from the super class. However, the internal operation from the super class is always the one which is called rather than the overriding one.

2 - The annotations are only applicable to ordinary methods which should become operations. As you pointed out, the init method is not an operation, so it shouldn't be annotated with them. However, CArtAgO always considers the init method as public, which shouldn't be necessarily true. What if I want to allow the creation of an artefact only by means of a builder artefact? In this case, the artefact should only have a private init method which receives a builder as argument.

3 - As I reported here, CArtAgO doesn't support different signatures of init with the same number of parameters.

As you know, I've made a PR fixing 2 and 3.

Cheers, Igor.

[aricci303]

Hello Igor

I can understand your points, the implementation fixes that you propose are reasonable but I think that, before including them, it is a good idea to have a clear model about artifact inheritance/extension/specialization - which is currently missing in A&A and CArtAgO.

I mean: of course it is easy from an implementation point of view to define a new artifact template A' from an existing artifact template A by defining the class A' extending the class A. However, since artifacts are not (exactly) objects and artifact templates are not (exactly) Java classes (they are implemented by exploiting Java classes..), before reusing available extension mechanisms for defining artifact inheritance/extension/specialization we need to have a clear model of the mapping.

Having this mapping, we can indeed easily contextualize and apply your points and nice extensions (1,2,3) and the points about visibility. But before, let's define it at the model/semantics level, i.e. an extension of the current A&A / CArtAgO model taking into the account (1) visibility feature, (2) inheritance/extension/specialization.

It is just a matter of setting up a (synthetic) shared doc in which we clearly depict this. Actually this could become something interesting for a paper. Then, before applying the changes to the master, we can test all the introduced features on a branch, that we will merge at the end.

[igorcadelima]

Hi, @aricci303

Fair enough! Something interesting could indeed come out of this. Let's do this!

Would you mind setting up the doc? My email is igorcadelima[at]gmail[dot]com.

Cheers.