# from Adam Kennedy
# on Wednesday 07 March 2007 12:21 am:
>This approach seems to be complicating the format for the sake the
>saving a few lines of code and a few minutes of work.
You could argue that it complicates the extensions phase, but I think it
greatly simplifies the format and the transition to core. Further, it
only complicates reading if you want to be strict about checking, and
that is no more complicated than simply *accessing the data* in the
nested scheme.
>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.
It's about MULTIPLE tools being in-sync whether it is core or not. IMO,
that's better than "well, we like it so we'll break 5 tools by making
it permanent" or "just write it in both places for a while so
everything has a chance to migrate."
It's not about saving "some" code when it gets accepted to core. We all
know saving code sucks.
If we're only talking about private data that will never be core, let's
just nest them under a hints/foo key and be done with it. I don't
think cc_author is such a beast.
>Which is reliant on every extension author always picking unused and
>ideal names, forever.
That could be an issue, but is it really worth all of this:
>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;
>}
vs $meta->{cc_author} ? Think of the one-liners. Please.
1. There will be some public discussion before it goes core.
2. If it is in use in multiple tools before (1), then presumably there
was some public discussion first.
If we need 10 lines of code per extension, we're not doing it right. If
you're using extensions with conflicting names, tell someone about it.
>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.
Of course. That's great for hints and private data too, but if we do
extensions with the values nested under the namespace, we might as well
forget about making them part of the core spec because migration day
will break everything.
--Eric
--
"It ain't those parts of the Bible that I can't understand that
bother me, it's the parts that I do understand."
--Mark Twain
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
