RFE: class as conditional self-defining keyword for package

p5pRT commented 12 years ago

Migrated from rt.perl.org#114460 (status was 'rejected')

Searchable as RT114460$

p5pRT commented 12 years ago

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

Admittedly this might be doable in a CPAN module\, but having it builtin to the language would seem to clarify and simplify the border between classes and packages\, and the fear of 'use \' trying to use 'auto-semantics' to determine if it should look for pkgname in the LIB list.

This has likely already been thought of in some related form\, but I'm not aware of it being part of the language.

'class' \ will be equivalent to 'package' \\, with the exception that\, UNLESS there has been a *previous* 'use' \ (thus it is loaded); it will define the package the same as a 'package' statement would\, *AND* set the values in the $::INC{} hash to indicate that it should now be considered loaded into memory

i.e.:

class \;

would be equivalent to:

package \; $::INC{'pkgname.pm'}= __FILE__ unless $::INC{'pkgname.pm'};

This provides the notational convenience of allowing class definition without playing with perl internals\, (i.e. "$::INC{pkg2filename(\)}" )\, which\, IMO\, is a good way to allow same-file definitions of 'pure' classes that have no external package (or 'package' baggage -- the requirements of 'package') without the use or knowledge of Perl-Arcana**.

As a lower case bareword\, it shouldn't conflict with existing programs unless they have over-ridden warnings about such.

Might this\, perhaps\, not be a clean solution for not requiring changes to 'use' that would have it 'guess' if a package is loaded or not?

---------------- **Perl-Arcana - knowledge of perl internals and invocations to achive results similar to other languages that require no 'internals-specific' knowledge to use in those other languages (Syntax/Semantic keyword differences not included).

Perl Info

``` Flags: category=core severity=wishlist This perlbug was built using Perl 5.14.2 - Wed Feb 8 15:59:25 UTC 2012 It is being executed now by Perl 5.14.2 - Wed Feb 8 15:55:36 UTC 2012. Site configuration information for perl 5.14.2: Configured by abuild at Wed Feb 8 15:55:36 UTC 2012. Summary of my perl5 (revision 5 version 14 subversion 2) configuration: Platform: osname=linux, osvers=3.1.0-1.2-default, archname=x86_64-linux-thread-multi uname='linux build09 3.1.0-1.2-default #1 smp thu nov 3 14:45:45 utc 2011 (187dde0) x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector' ccversion='', gccversion='4.6.2', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector' libpth=/lib64 /usr/lib64 /usr/local/lib64 libs=-lm -ldl -lcrypt -lpthread perllibs=-lm -ldl -lcrypt -lpthread libc=/lib64/libc-2.14.1.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.14.1' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.14.2/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector' Locally applied patches: @INC for perl 5.14.2: /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.14.2 /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/5.14.2 /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/site_perl . Environment for perl 5.14.2: HOME=/home/law LANG=en_US.UTF-8 LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.UTF-8 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=.:/sbin:/usr/local/sbin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib:/home/law/bin/lib PERL5OPT=-CSA PERL_BADLANG (unset) SHELL=/bin/bash ```

p5pRT commented 12 years ago

From @cpansprout

On Sun Aug 12 10:08:53 2012\, LAWalsh wrote:

Admittedly this might be doable in a CPAN module\, but having it builtin to the language would seem to clarify and simplify the border between classes and packages\, and the fear of 'use \' trying to use 'auto-semantics' to determine if it should look for pkgname in the LIB list.

This has likely already been thought of in some related form\, but I'm not aware of it being part of the language.

'class' \ will be equivalent to 'package' \\, with the exception that\, UNLESS there has been a *previous* 'use' \ (thus it is loaded); it will define the package the same as a 'package' statement would\, *AND* set the values in the $::INC{} hash to indicate that it should now be considered loaded into memory

i.e.:
class    \<pkgname>;
would be equivalent to:
package \<pkgname>;
    $&#8203;::INC\{'pkgname\.pm'\}= \_\_FILE\_\_ unless $&#8203;::INC\{'pkgname\.pm'\};
This provides the notational convenience of allowing class definition without playing with perl internals\, (i.e. "$::INC{pkg2filename(\)}" )

%INC is not internal any more than $! is. While adding such a keyword would be harmless\, I see little benefit.

--

Father Chrysostomos

p5pRT commented 12 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 12 years ago

From @xdg

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 \' 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.

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.

I.e. a module contains zero or more package declarations; these may or may not correspond to the bareword "name" of the module before it is translated into a path to search @INC.

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.

I do think it would be appropriate to prototype such a capability on CPAN and see if there is widespread adoption.

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

A more sophisticated approach could use the hoookable parser to do this:

use Devel::InnerClass;

innerclass Foo::Bar { ... }

(The phrase "innerclass" seems less likely to conflict with what people expect of a "class" keyword.)

I tend to think either of those would be better places to start than by adding a new keyword to the core.

-- David

p5pRT commented 12 years ago

From perl-diddler@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 \' 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 \" 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&#8203;::Bar;
use Inc&#8203;::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.

p5pRT commented 12 years ago

From @doy

On Sun\, Aug 12\, 2012 at 03:58:14PM -0700\, Linda W wrote:

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.

One of our medium-term goals for the language in the next couple of years is to add the concept of real\, actual classes to the perl core. I'd be against adding this idea to core if only because of namespace clashing issues (a real class implementation will also want to be able to use the 'class' keyword).

-doy

p5pRT commented 12 years ago

From perl-diddler@tlinx.org

Jesse Luehrs via RT wrote:

On Sun\, Aug 12\, 2012 at 03:58:14PM -0700\, Linda W wrote:

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.

One of our medium-term goals for the language in the next couple of years is to add the concept of real\, actual classes to the perl core. I'd be against adding this idea to core if only because of namespace clashing issues (a real class implementation will also want to be able to use the 'class' keyword).---

I don't see this as bad or necessarily conflicting.

I don't need to RESERVE the keyword -- just use it.

If you want add to it to make them 'more classy'\, I wouldn't have a problem. But...you didn't even introduce given/when unless the user uses "5.10.0" or the specific keyword\, how likely is it that the new keyword will just be dumped into the namespace and cause conflicts?

Isn't it likely to have\, some 'base' of similar semantics (though if you have it forcing file includes\, I'll be cross!). But what other things? method as a synonym for 'sub ... my $this=shift;' or what? how would the syntax vary? from "class Class::Name;" or would it?

I.e. -- This could easily be an early start... with the proviso that in future versions\, exact syntax and semantics may change -- as long as it doesn't force file access... I'm pretty copacetic with such... but I would ask that you support inclusion of the described level of support while you until you get to your medium-term time-frame\, as it doesn't sound like it it's going to happen soon (?)...of course if medium term = next major (next summer?) then it may be of no consequence / issue anyway... (i.e. well\, get to it\, and I wouldn't have to deal with trying to push partial semantics through now\, as it very easily/conceivably could solve/address the issue raised ).

p5pRT commented 12 years ago

From @xdg

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 \" 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

p5pRT commented 12 years ago

From Eirik-Berg.Hanssen@allverden.no

On Mon\, Aug 13\, 2012 at 2:37 AM\, David Golden \xdaveg@gmail\.com wrote:

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".

Sounds good to me\, except one amendment/clarification:

As described\, it will call C\<\< Foo->import >> or not\, depending on whether Foo exists in %PACKAGES. That's not good.

If should either act like C\<\< use Foo (); >> when the package is not already loaded (i.e. never call C\<\< Foo->import >>)\, or else always call C\<\< Foo->import >> (at compile time) whether or not the package was already loaded.

(Gut feeling says the latter. This could well be used not only for purely OO packages\, but also those that implement new syntax. They're the ones that most need compile time effects\, after all. And then it generalizes as C\<\< ensure Foo (); >> would be the don't-call-import syntax.)

And while I cannot say I personally have missed this functionality much (tried use-ing a package from a different module once\, found it didn't work\, found another WTDI)\, I do recall seeing others ask for something similar. And I think it will make it easier to teach/learn Perl\, highlighting the difference between module and package\, and so making it less inaccessible to the uninitiated. (A kind of language design "show\, don't tell"? The documentation clearly tells us packages and modules are not the same\, but that does not stop otherwise sane and intelligent people from confusing them.)

However\, I'm not going to make this\, and this is not a vote – but perhaps\, rather\, a cheer from the peanut gallery? With the above amendment/clarification\, it sounds good to me.

Eirik

p5pRT commented 12 years ago

From dcmertens.perl@gmail.com

On Sun\, Aug 12\, 2012 at 6:04 PM\, Jesse Luehrs \doy@tozt\.net wrote:

On Sun\, Aug 12\, 2012 at 03:58:14PM -0700\, Linda W wrote:

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.

One of our medium-term goals for the language in the next couple of years is to add the concept of real\, actual classes to the perl core. I'd be against adding this idea to core if only because of namespace clashing issues (a real class implementation will also want to be able to use the 'class' keyword).

-doy

I happen to agree with Jesse on this point: at the very least\, don't use the reserved word "class".

In general\, though\, is your point of contention not solved by a well written SYNOPSIS section in the module's documentation? Unlike other languages\, Perl makes documentation writing very simple\, and a well written SYNOPSIS should make it very clear what needs to be "use"d in order to get the class properly pulled in.

David

-- "Debugging is twice as hard as writing the code in the first place. Therefore\, if you write the code as cleverly as possible\, you are\, by definition\, not smart enough to debug it." -- Brian Kernighan

p5pRT commented 12 years ago

From @jkeenan

On Mon Aug 13 18:38:41 2012\, dcmertens.perl@gmail.com wrote:

On Sun\, Aug 12\, 2012 at 6:04 PM\, Jesse Luehrs \doy@tozt\.net wrote:

On Sun\, Aug 12\, 2012 at 03:58:14PM -0700\, Linda W wrote:

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.

One of our medium-term goals for the language in the next couple of years is to add the concept of real\, actual classes to the perl core. I'd be against adding this idea to core if only because of namespace clashing issues (a real class implementation will also want to be able to use the 'class' keyword).

-doy

I happen to agree with Jesse on this point: at the very least\, don't use the reserved word "class".

In general\, though\, is your point of contention not solved by a well written SYNOPSIS section in the module's documentation? Unlike other languages\, Perl makes documentation writing very simple\, and a well written SYNOPSIS should make it very clear what needs to be "use"d in order to get the class properly pulled in.

David

This RT generated considerable discussion but\, AFAICT\, no actionable patches. I recommend that we close this ticket and have interested parties open a new RT when they're ready to submit a patch.

I will close this ticket in seven days unless there is strong objection.

Thank you very much. Jim Keenan

p5pRT commented 11 years ago

From @jkeenan

On Tue Sep 18 18:54:49 2012\, jkeenan wrote:

On Mon Aug 13 18:38:41 2012\, dcmertens.perl@gmail.com wrote:

On Sun\, Aug 12\, 2012 at 6:04 PM\, Jesse Luehrs \doy@tozt\.net wrote:

On Sun\, Aug 12\, 2012 at 03:58:14PM -0700\, Linda W wrote:

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.

One of our medium-term goals for the language in the next couple of years is to add the concept of real\, actual classes to the perl core. I'd be against adding this idea to core if only because of namespace clashing issues (a real class implementation will also want to be able to use the 'class' keyword).

-doy

I happen to agree with Jesse on this point: at the very least\, don't use the reserved word "class".

In general\, though\, is your point of contention not solved by a well written SYNOPSIS section in the module's documentation? Unlike other languages\, Perl makes documentation writing very simple\, and a well written SYNOPSIS should make it very clear what needs to be "use"d in order to get the class properly pulled in.

David

This RT generated considerable discussion but\, AFAICT\, no actionable patches. I recommend that we close this ticket and have interested parties open a new RT when they're ready to submit a patch.

I will close this ticket in seven days unless there is strong objection.

Thank you very much. Jim Keenan

No further comments received in > 7 days. Closing ticket.

Thank you very much. Jim Keenan

p5pRT commented 11 years ago

@jkeenan - Status changed from 'open' to 'rejected'

Perl / perl5