This approach seems to be complicating the format for the sake the
saving a few lines of code and a few minutes of work.
Firstly, two modules don't need two keys.
The use of a module name in the extension is merely the resuse of the
uniqueness of modules for the purposes of cheaply gaining a unique
namespace in the extensions.
An alternate implementation would use the same namespace of the module
that defined the concept.
If you are going to just write in to the root of META.yml why even
bother with writing the extension. The only reason to write the
extension is to have some form of validation or checking, and in that
case it greatly complicates the validation.
If there's no validation then there's no reason to list the extension.
It might as well be an argument between having an extentions namespace
and not having one.
As for the implementation...
sub cc_author {
my $meta = shift;
if ( defined $meta->{cc_author} ) {
return $meta->{cc_author};
}
if ( defined $meta->{extensions}->{'my module namespace'}->{cc_author}
) {
return $meta->{extentions}->{'my module
namespace'}->{cc_author};
}
return $default;
}
This is not THAT imposing.
Now lets imagine that you write cc_author into the root namespace, but
it turns out that someone ELSE used cc_author as well.
When the person's badly-picked name goes to core, it's now foo_cc_author...
By using extensions you can now do.
sub cc_author {
my $meta = shift;
if ( defined $meta->{foo_cc_author} ) {
return $meta->{foo_cc_author};
}
if ( defined $meta->{extensions}->{'my module namespace'}->{cc_author}
) {
return $meta->{extentions}->{'my module
namespace'}->{cc_author};
}
return $default;
}
The argument of putting it into the root to save some code when you get
accepted into the core assumes both that the extension WILL be accepted
into the core, and that it will always retain the same name when it
moves to the core.
Which is reliant on every extension author always picking unused and
ideal names, forever.
Adam K
Eric Wilhelm wrote:
# from Adam Kennedy
# on Monday 05 March 2007 02:30 am:
The problem is it's not self-contained, it requires much more
additional state to be held, and far more additional checking.
True, it is not self-contained, but how would the nested approach go
core?
cc_author: 0
...
extensions:
cc_author: 'identify what you mean by it here'
The actual data of interest is simply:
$meta->{cc_author}
You have to look out for collisions, or at least go to the trouble to
overwrite it in both places. But, for promoting extensions to core
status, your code looks the same.
extensions:
'identify what you mean by it here':
cc_author: 0
that's
$meta->{extensions}{'identify what you mean by it here'}{cc_author}
And it means that code for cooperating/competing extensions is more
complicated:
my $ext = $meta->{extensions};
my $cc_author =
exists($ext->{"joe's implementation of cc_author"}) ?
$ext->{"joe's implementation of cc_author"} : (
exists($ext->{"jill's cc_author attempt"}) &&
$ext->{"jill's cc_author attempt"}
);
Ugh. Let's try it the other way while simultaneously adding features.
if($meta->{'meta-spec'}{version} > 1.5) {
# pretend all three are compatible as far as we're concerned
my %supported = map({$_ => 1}
"joe's implementation of cc_author",
"jill's cc_author attempt",
"http://www.nntp.perl.org/group/perl.qa/2007/03/msg8032.html',
);
my $type = $meta->{'meta-spec'}{extensions}{cc_author};
$supported{$type} or return;
}
my $cc_author = $meta->{cc_author};
More things can go wrong and the implementation would thus be more
complicated.
Some guy once said something about "as simple as possible, but no
simpler."
Again, the data of interest is a top-level key and the path to it
doesn't change when it goes core. Even the most naive of
implementations would do the right thing 95% of the time.
And it's more wordy and more complicated that the other way
I think it is less wordy because the extension identifier is not the key
name. Also, when the extension goes core, all of the tools that are
using it are able to be automatically in sync with no added code.
# and on Monday 05 March 2007 06:28 am:
And it creates a sort of DMZ and testing ground for features, before
they most to the core.
What's the migration path for the
$meta->{extensions}{"my big long identifier"}{key_of_interest}
code? And how long will it take for tools to catch-up after this
mosting of which you speak?
I think it's better to just make sure that it has a hall pass than to
lock it in the closet.
--Eric
