develooper Front page | perl.perl5.porters | Postings from August 2012

Re: [perl #114460] RFE: class as conditional self-defining keywordfor package

Thread Previous | Thread Next
From:
David Golden
Date:
August 12, 2012 17:37
Subject:
Re: [perl #114460] RFE: class as conditional self-defining keywordfor package
Message ID:
CAOeq1c8TWN+xF32Uw3U8AMHR=P4Attc=-ZB6H_E1BpQzkm1fOQ@mail.gmail.com
On Sun, Aug 12, 2012 at 6:58 PM, Linda W <perl-diddler@tlinx.org> wrote:
> If you don't want to use the new key word...fine -- you wouldn't have to
> change anything.   But why 'dis' the concept of classes as independent from
> a specific requirement of external files?
>

I'm not 'dissing' it.  I'm pointing out that there is no real
distinction in Perl 5 between "class" and "package", but there is
between "package" and "module", exactly as you quoted from Programming
Perl.

> "Often, a module is used to hold one or more classes".   Now you cannot do
> that
> if you require "use <classname>" to go out and fetch a file, which is the
> default way to use a Class.

I think that might be where your opinion differs from mine.  If you
look at the documentation of "use", it says "use Module", not "use
Class".  If you look at how "use" effectively just wraps "require",
and then read the documentation for "require", it says "require EXPR",
not "require Class".  Then if you read the documentation for what EXPR
means in that context, it talks about "'require' demands that a
library file be included if it hasn't already been included".

In other words, "use" and "require" are explicitly about loading a
*file* (albeit through the convenient abstraction of a
bareword->filename translation).

I understand that you would prefer "use" and "require" to have class
(i.e. package) semantics, but they don't.  Faking them out by putting
dummy entries in %INC is a workaround that suits your particular way
of working to avoid fatal errors -- and I totally respect that desire
-- but it does so in a way that is not consistent with the defined
meaning of %INC.

If you look in perlvar, there are entries in %INC "for each
*filename*" included via 'do', 'require' or 'use' operation" [emphasis
mine].  Converting an inner package name to a file path and creating
an %INC entry for it is a hack (in the good sense) to avoid a fatal
error if someone tries to "require" or "use" it.

I don't mean anything bad in the word hack -- it's a workaround for a
particular way Perl works because of the historical way it evolved,
and there are plenty of examples of those on CPAN.  (I work on
toolchain -- I'm probably guilty of some of those hacks myself.)

However, I don't think that this sort of hack merits inclusion in core.

A broader design question would be whether there should be an
analogous global to %INC that is specific to package names -- i.e.
that maps package names seen during compilation to a list of files
that contain their scope -- and, if so, what semantics it should have.

For example, let's hypothesize such a global called %PACKAGES and a
new hypothetical keyword "ensure".  Then we could imagine something
like this:

    ensure Foo;

Here, "ensure" would check if Foo exists in %PACKAGES.  If so, it
would do nothing.  If not, it would act like "use Foo".  Thus -- just
as "use" wraps "require", such an "ensure" would wrap "use".  (There
are edge cases here like monkey-patching that might actually merit a
new keyword besides "package", but let's handwave that away for the
moment.)

In this case, %PACKAGES and "ensure" wouldn't change the semantics of
"use", "package" or %INC at all -- so all existing expectations and
code are unchanged.  It would add *new* semantics that are more
consistent with package/namespace orientation.  I think that's a much
cleaner design than your proposal and accomplishes much the same
objective.

That said, I'm not convinced that such an extension is vitally
important to the community and wouldn't personally commit time to it.
But if you or someone else did have the time to commit to it,  I would
still encourage CPAN-based prototyping before it was considered for
the Perl core even as an experimental feature.

(It might even be worthwhile for the team working on the p5-mop design
to consider such an extension -- a class loader distinct from "use"
that could check first against a registry of classes, assuming one is
part of the MOP.)

Regards,
David

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About