On Mon, 2004-04-26 at 16:20, Richard Proctor wrote:
> Issues:
>
> 1) Why does this only use Version and Author? Suppose there are versions
> for different oses or that use other particular libraries that are wanted
> or not?
personally, I think this should be handled in the class itself.
you always "use DBI", don't "use DBI-(Any)-(Any)-MSWin32" or "...-linux"
or "...-whatever". class name, version and author(ity) seem to me a good
set to univocally identify a class.
> 2) Shouldn't all these properties just be in a hash against the module
> rather than some having special significance? Others can then be simply
> added as appropriate.
see below.
> 3) Why is the information positional rather than by keyword property?
> use Dog :version«1.2.1» :author«JRANDOM» :os«cpm»;
probably because use itself can take parameters (or adverbs), and you
don't want them to collide with the class metadata.
> 4) What are the expected rules for versioning? While the public CPAN has
> one set of versioning, other projects have weird versioning rules, with
> letters and numbers. What would work and why?
not to mention the fact that a lot of modules do things like:
$VERSION = sprintf("%d.%02d", q$Revision: 1.46 $ =~ /(\d+)\.(\d+)/);
which I think is a Good Thing, and should stay there.
> These are not fully thought through answers, but illustrate some thoughts
> or the matter.
well, I have an idea on the matter. given that class definitions are
closures to be executed by the class constructor code, there should be a
context, somewhere, that knows about the current class being
constructed. in this context (and no others, presumably), the .meta
method could be given write-access to the metadata of the class.
so, you can say:
class Dog-1.21-JRANDOM { ... }
as well as:
class Dog {
.meta.version = 1.21;
.meta.author = "JRANDOM";
# and of course...
.meta.description = "This class implements camera obscura.";
.meta.subject = <<optics boxes>>;
.meta.language = "ja_JP";
# etc.
}
cheers,
Aldo
