Replace the column options array with an object

[burzum]

As already suggested 2 years ago https://github.com/cakephp/phinx/issues/249#issuecomment-373716784

// suggested backward compatible way, using a factory to create the object
$this->table('some_table')
	->addColumn(Column::text('name')->length(212)->notNull())
	->addColumn(Column::bool('active')->default(false)
	->update();

// even shorter complementary API, use the factory internally and provide methods
$this->table('some_table')
	->addTextColumn('name')->length(212)->notNull()
	->addBoolColumn('active')->default(false)
	->update();

// old way
$this->table('some_table')
	->addColumn('name', 'text', ['length' => 212, 'null' => false])
	->addColumn('active', 'bool', ['default' => false])
	->update();

The first example would require a check inside of the addColumn() method if it's only one arg and if it is of a specific interface (ColumnFactoryInterface?). The second example would not require and backward compatibility change to addColumn() but provide new expressive methods for add a specific column type.

I think we really don't need to have a discussion about the obvious advantages of using an expressive object oriented notation over the fugly arrays. Do we?

[MasterOdin]

I would think that after this implemention, one might reasonably expect that the table options could be configured in a similar way, which would lead to ambiguous behavior with the second option.

[burzum]

@MasterOdin agreed, they should become an object as well. But how would this lead to ambiguous behavior?

[MasterOdin]

Both tables and columns have a handful of similar options, for example, both tables and columns can have comments. So then what ->comment('foo') would refer to becomes ambiguous. You could mandate table options must precede any columns, but that just then leads to some additional code in the table class to handle this, as well as also in my opinion just setting up someone to mess up writing a migration.

[dereuromark]

I agree that this is not easily doable with the current API.

Also, we do for example have some autocomplete for the fields and types already (using meta directives) for e.g. PHPStorm IDE This also works quite nicely already.

So as bad as magic strings in general are, this helps to make them actually quite useful here, and the way to work with them efficient in this context.

Maybe this is fine for now - I am sure there are few other tickets and bugs that would need our more immediate attention.

[lulco]

Where are these meta directives for php strom stored? I can’t find them in phinx repository