On Thu, Apr 29, 2004 at 01:36:39PM +0200, Aldo Calpini wrote:
: 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.
Alternately, for OS-specific modules, it's part of the name as it is now, or
possibly part of the author(ity).
: > 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.
Hashes are not as powerful as properties, and you can always treat the
properties as a hash, since you can treat any object as a hash. But
we have to be sure to capture the information at compile time, not
run time.
: > 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.
That is correct.
: > 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.
That looks like one of those naughty run-time things that aren't
guaranteed to run soon enough. I suspect we can make accomodations
for RCS/CVS without compromising that. Maybe as simple as allowing
class Dog-$Revision: 1.46 $-JRANDOM
since it's a special parse anyway. Wouldn't be the first accomodation
Perl made to other tools... :-)
: > 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.
: }
Okay, but you'd have to be careful. If the class refers to itself
before you define its full name, it must not try to dereference that
name prematurely. Worse, you're back in the situation that you have
to compile the class before you can know its version, or you have to
rely on hacky conventions to extract the version, which stinks.
I suppose another way to hack around it is to set up the compiler
with an option to bail out and tell you the full name of the class
the moment it thinks it knows it. That's also pretty stinky.
As I alluded to in A12, another way around it is to require that the
filename or filesystem or module database always identify the full
name. We need that anyway for installed modules in order to allow
version coexistence. That doesn't interact so well with revision
control systems that assume a single file for multiple versions,
however. Unless, of course, we say that the file storing all the
revisions is what Perl is actually interested in. Hmm...
Larry
