Influence of visibility modifiers on artefact creation

[igorcadelima]

Hi,

I've been facing some issues wrt artefacts creation and visibility modifiers. Currently, this is what's being done:

• Artefacts can be created without taking their #init's modifier into account
• If the default constructor of a class that extends Artefact is anything but public, it can't be created as an artefact (ie, by means of makeArtifact(...))

I find this quite confusing. I believe that, when creating artefacts, the init method's modifier should be considered, and its modifier only, not the default constructor's. This way I can create ordinary and artefact instances out of the same class, the former by using new and the latter by using makeArtifact, while still keeping the visibility modifiers' semantics.

This is a real problem when tying to implement some design patterns. For example, I tried to implement an adapted version of Joshua Bloch's Builder design pattern to work with artefacts but I can't have it properly done as I can't have private constructors. Here's how I tried to implement it:

• SimpleClass extends Artifact, has a private constructor with SimpleClassBuilder as parameter, and a public init method that has SimpleClass as parameter (this would be something like an "object-artefact copy constructor");
• SimpleClassBuilder is a SimpleClass' static inner class whose build method returns a SimpleClass ordinary instance

Note that a SimpleClass artefact can only be created if we have an ordinary instance of it, which can only be obtained by using SimpleClassBuilder. I could have made SimpleClassBuilder an artefact whose build method creates a SimpleClass artefact and returns its ArtefactId. However, this would incur unnecessary computational costs (due to the use of reflect for everything including setters in the builder) and if I had a parser class (which is also my case), for example, that uses the builder, this would have to be an artefact as well. After the parsing and building, I'd also need to dispose the builder and parser artefacts.

Could you please give your thoughts on this, @jomifred @aricci303 ?

Cheers.

[igorcadelima]

In the creation process of #4, I realised that, because of the way CArtAgO is designed today, it's impossible to dissociate constructors from artefact creation. In order to create an artefact, there should be at least one constructor, which currently is the default one.

One way to allow creation of ordinary objects and artefacts out of the same class would be bypassing constructors when creating artefacts. I believe this could be done by using a bytecode manipulator such as https://github.com/easymock/objenesis. However, this would incur even more performance cost.

A good way to deal with this would be to let every artefact be able to call a method like makeArtifact(OpFeedbackParam<ArtifactId>) in order to become an artefact. If any configuration is needed before, after, or around such method, AspectJ could come in handy here. So the artefact creation steps would be:

1. Create object by calling an appropriate constructor
2. Call makeArtifact on the object in order to turn the object into an artefact
   2.1. AspectJ executes advice to be called before makeArtifact
   2.2. AspectJ executes makeArtifact
   2.3. AspectJ executes advice to be called after makeArtifact

I haven't thought it entirely through, but I'm pretty sure this would allow for better performance and easier implementations of OO design patterns.

Sorry to bother you with all this. Just wanted to give my two cents :)