Front page | perl.perl5.porters |
Postings from August 2012
Re: [perl #114460] RFE: class as conditional self-defining keyword for package
Thread Previous
|
Thread Next
From:
Linda W
Date:
August 12, 2012 15:58
Subject:
Re: [perl #114460] RFE: class as conditional self-defining keyword for package
Message ID:
50283506.9080303@tlinx.org
David Golden via RT wrote:
> On Sun, Aug 12, 2012 at 1:08 PM, Linda Walsh <perlbug-followup@perl.org> wrote:
>
>> [snip]
>> border between classes and packages, and the fear of 'use <pkgname>'
>> trying to use 'auto-semantics' to determine if it should look for
>> pkgname in the LIB list.
>>
>
> My view is that there is *no* border between classes and packages,
> because the former has no (current) meaning in Perl 5. A "class" is
> just a namespace, i.e. a package, that happens to have a reference
> blessed to it.
>
=====================
A Class in OO doesn't require a corresponding file of xx::=>/yy+.pm to exist
in a library somewhere... It can exist in the file, it can exist in a
library.
I agree with your view -- except that the perl package and use keywords
have been overloaded with specific physical actions making them non-general.
Introducing 'class' to separate concept from "library implementation",
allows for cleaner conceptualizing in the language... unless you want to
support package doing what I am suggesting with Class -- I.e. by using
package, you are
defining it as already included in the current file, so any future 'use'
statements won't cause an ugly death. There was general outcry against
such a change based on perceived compatibility and reliability issues.
This addresses those issues. Putting it on CPAN wouldn't solve the
point of fixing the language to have classes as a separate concept that
isn't tied to a specific implementation. Tying a general concept to a
specific implementation seems to
be contrary to the very idea of OO semantics not to mention perl's DWIM
design
philosophy.
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?
FWIW .. Classes, according to the latest Perl reference manual,
(programming Perl, 4th Ed., aka Camel book), "A class is simply a package".
And what more, get this sentence (which I and many people know, but I get
flamed for doing again and again on perlmonks because everyone knows you are
supposed to put all your classes in separate packages.
"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. "Use" verifies @ compile time that the
class is available for use. It's not needed to pull in definitions for
an OO class --
as all that is resolved at runtime (unless you do strict+warnings --
which do
compile-time checks to add some sanity checking).
A class doesn't have to have specific semantics that require Perl to
throw a Fatal Error when it doesn't know that the _Class_ is already
defined in the current module.
It doesn't Require modifying Perl internal variables
(to address Chryst' comment) that describe where to look for modules,
though sometimes an ENV VAR of CLASSPATH is used for classes that need
to be looked up in a library (aren't defined in the current file). ENV
vars, are external.
BEGIN{%::INC{name_adaptation(Classname)}=some value;}
BEGIN isn't even part of normal perl syntax -- It's a way to have
something performed pre-execution time, a perl internals concept.
> There is an often blurry border between "package" (namespace) and
> "module" (a .pm file). E.g. both "use" and "require" can load a
> module, which may or may not contain a package of the corresponding
> name.
>
----
That's because package {Classes or Functional modules} that require
a file to be looked up.
> So, with that in mind, I could see benefit in trying to clarify what
> people intend, and to allow people to "use" a bareword without needing
> to worry whether it's in a module or already loaded as part of another
> module. However, I don't think "class" is an appropriate keyword for
> it, as that already has lots of overloaded meanings (and desired
> meanings) and I don't see this specific feature consistent with or
> clarifying any of those.
>
It is solely and singularly consistent with the definition of class in
the OO
section of the camel book, and upper case CLASS (in Core 'use CLASS'), is
already a synonym for __PACKAGE__.... it isn't overloaded. "Class" is used
alot, but 'class' isn't something that would normally conflict.
I'm not suggesting it be retroactively added to all perl's, only those
using a "use 5.X;" # (∃ "X" ∈ "V">=16.0 && V
<= ∞ )
would be saddled with this additional keyword.
> I do think it would be appropriate to prototype such a capability on
> CPAN and see if there is widespread adoption.
>
----
Nep. No more than you would expect people to goto CPAN to use the
"package" statement, though part of Core would probably be sufficient if
it is "autoloaded" ;-).
> For example, this would be trivially easy and less verbose than direct
> %INC hacking:
>
> package Foo::Bar;
> use Inc::Loaded; # import sets caller as loaded in %INC
>
----
Yeah... tried to use one of those...got the T-shirt.
Someone implemented the notion of a function to convert a module
name to perl notational form using notional. Caused a fair amount of
grief because it wasn't clear, nor was it clear it was working.
BEGIN { $INC{module_notional_filename(__PACKAGE__)}=__FILE__ }
Still had to be in a BEGIN (equivalent). Still required a separate
include/package. (use Module::Runtime qw(module_notional_filename);)
Lets see, do I want to have to type 113 chars or 5 when I want to
define a class? Yes I do have RSI, and typing long and complicated
(involving special symbols and/or upper case) is notably harder on my hands
than simple lower case).
> I tend to think either of those would be better places to start than
> by adding a new keyword to the core.
>
---
The problem is that "Core" doesn't have pure classes -- it has modules, yet
it represents itself as an OO language. The modules have requirements that
classes don't -- inherently, tying 'concept' to implementation is an
anathema
to OO design. Adding a package to CPAN won't change the problem in Core.
Thread Previous
|
Thread Next