Type system improvements about montage

[kriskowal]

@romancortes points out that, for the purpose of serialization, it does not make sense to link properties of components until after all of them have been constructed and initialized. So, my thought about using the serialization properties to pass information into the initializer would not work. "properties" are really post-construction "linkage".

Bearing in mind that I’m not attacking a specific use case, I just fear we’re painting ourselves into a corner. Components rely on bindings to ensure consistency, so the present model works fine.

Regardless of whether initializers are parameterized, or whether properties are assigned before or after initialization, I think we need separate syntax for instantiation and creating subtypes.

[kriskowal]

We’re planning a meeting to discuss this ticket. My ideas have shifted somewhat with education, so I’ll restate my ideas.

1. Montage.create should be only a polymorphic method with the signature of type.create(descriptor_opt). If the descriptor is omitted, it should default to an empty descriptor. This would be used directly for creating new types, and indirectly (through constructors or serializers) to create new instances.
2. Deprecate the two-argument form of Montage.create(type, descriptor). The create function, though inspired by the static method of Object.create is not a static method. It would be clumsy for Montage.create(type, descriptor) to call type.create(descriptor) to regain polymorphism.
3. Deprecate the behavior of Montage.create() where it calls didCreate in the no-argument case. The no-arg case should only differ by the defaulting of the descriptor argument. It is “too clever” for it to assume you’re instantiating if you omit a descriptor.
4. Ponder didCreate(). Does this method make sense for both serialization and programmatic initialization? Does it make more sense before or after serialized properties are populated?
5. Ponder the pattern for construction and initialization. The pattern for constructing instances should be terse. Prototype.create().initWithThisArgumentPattern(…args) is not terse. Constructor(…args) is very terse, but not really going to happen since we don’t do constructors. Prototype.someName(…args) is okay, and gives us the win that Prototype is this in the constructor function so we can do this.create() inside to make our instance, handing off to a polymorphic create function. someName could be init or construct, but the key is that it would call this.create() internally so the user doesn’t have to.

[kriskowal]

Outcome of meeting was:

• Prototype.inherit(descriptor) is for deriving a new type
• Prototype.create() is for instantiation and initialization with no arguments
• Prototype.createWith…(…) forms are for instantiation and initialization with arguments

Migration path overlaps existing patterns:

• Montage.create(Prototype, descriptor). Change to Prototype.inherit(descriptor)
• Montage.create(Prototype). Change to Prototype.create() (This pattern is only used once, in Logger)
• Prototype.create() stays the same
• Prototype.create().init() can be subsumed into Prototype.create()
• Prototype.create().initWithArguments(…args) can be subsumed by Prototype.createWithArguments(…args)

The meeting approached consensus, but these changes remain contentious.

[francoisfrisch]

Solved!!

[kriskowal]

Perhaps there should be a party when you close an issue that is more than a 1000 behind the most recently opened issue!