-
-
Notifications
You must be signed in to change notification settings - Fork 48
Description
What I'm planning to do is to keep only mandatory parameters like Path for FileExtractors in the constructor, and move all other options to be set through the fluent interface for example:
to_xml(__DIR__ . '/file.xml')->withRootElementName('orders')
I would like to do the same for Extractors however extractors are a bit more problematic due to DSL and a decision I made a long time ago
#[DocumentationDSL(module: Module::XML, type: DSLType::EXTRACTOR)]
function from_xml(
string|Path|array $path,
string $xml_node_path = ''
) : Extractor {
if (\is_array($path)) {
/** @var array<Extractor> $extractors */
$extractors = [];
foreach ($path as $next_path) {
$extractors[] = new XMLParserExtractor(
\is_string($next_path) ? Path::realpath($next_path) : $next_path,
$xml_node_path
);
}
return from_all(...$extractors);
}
return new XMLParserExtractor(
\is_string($path) ? Path::realpath($path) : $path,
$xml_node_path
);
}as we can see here, if we pass $path as a list of array<string> or array<Path> from_xml, it will return ChainLoader so IDE will not suggest methods ->withXX() on it since they are methods of extractors chained under ChainExtractor
I thought that this passing array is going to be useful, but so far I didn't have a single use case for it, and it's also perfectly doable by the user, it requires to use from_all(from_xml(),from_csv()) for example
that's why I think I'm going to replace string|Path|array with string|Path only
which will let me set the proper return type for those DSL functions which will let IDE's to suggest options setting methods.
Thread about this change is also available at our Discord Server
Metadata
Metadata
Assignees
Labels
Type
Projects
Status