Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

please enhance 'use' and "use parent" to use 'base's modfind ability #12100

Closed
p5pRT opened this issue May 14, 2012 · 10 comments
Closed

please enhance 'use' and "use parent" to use 'base's modfind ability #12100

p5pRT opened this issue May 14, 2012 · 10 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented May 14, 2012

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

Searchable as RT112916$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 14, 2012

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

In order that "use" and "use parent" support similar semantics
as "use base", please enhance the first two to allow the same
semantics w/r/t​:

(from 'base' manpage)

  "base" employs some heuristics to determine if a module has already
  been loaded, if it has it doesn't try again. If "base" tries to
  "require" the module it will not die if it cannot find the module's
  file, but will die on any other error. After all this, should your base
  class be empty, containing no symbols, it will die. This is useful for
  inheriting from classes in the same file as yourself, like so​:

  package Foo;
  sub exclaim { "I can have such a thing?!" }

  package Bar;
  use base "Foo";

Currently, "use parent", supports the above through a different and
incompatible syntax ("-norequire"); And simply "use" doesn't
seem to support the above in any direct way (users are asked to
self-insert things in perl-internal arrays and such).

It would be much easier if the all of them supported the same
heuristics and richer sementics implemented in 'base'.

As it stands, the 3 types of use, which I believe are all in "CORE",
support different semantics w/r/t multiple type-classes defined in the
same file.

Thanks!

Perl Info

Flags:
    category=core
    severity=low

This perlbug was built using Perl 5.14.2 - Sat Oct 29 15:59:10 UTC 2011
It is being executed now by  Perl 5.14.2 - Sat Oct 29 15:55:30 UTC 2011.

Site configuration information for perl 5.14.2:

Configured by abuild at Sat Oct 29 15:55:30 UTC 2011.

Summary of my perl5 (revision 5 version 14 subversion 2) configuration:
   
  Platform:
    osname=linux, osvers=3.1.0-rc10-1-default, archname=x86_64-linux-thread-multi
    uname='linux build33 3.1.0-rc10-1-default #1 smp thu oct 20 08:17:26 utc 2011 (f6d77d4) 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 -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:/opt/lsb/bin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/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
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 14, 2012

From @cpansprout

On Sun May 13 17​:30​:23 2012, LAWalsh wrote​:

In order that "use" and "use parent" support similar semantics
as "use base", please enhance the first two to allow the same
semantics w/r/t​:

(from 'base' manpage)

   "base" employs some heuristics to determine if a module has

already
been loaded, if it has it doesn't try again. If "base" tries to
"require" the module it will not die if it cannot find the
module's
file, but will die on any other error. After all this, should
your base
class be empty, containing no symbols, it will die. This is
useful for
inheriting from classes in the same file as yourself, like so​:

           package Foo;
           sub exclaim \{ "I can have such a thing?\!" \}

           package Bar;
           use base "Foo";

Currently, "use parent", supports the above through a different and
incompatible syntax ("-norequire");

One of the purposes of ‘use parent’ was to keep things simple, as
base.pm was considered too smart for its own good. If you need that
functionality, why are you using parent.pm and not base.pm? :-) I think
some have implied that base.pm is deprecated, but that is quite an
overstatement. It’s not going anywhere any time soon, as far as I know.

And simply "use" doesn't
seem to support the above in any direct way (users are asked to
self-insert things in perl-internal arrays and such).

It would be much easier if the all of them supported the same
heuristics and richer sementics implemented in 'base'.

If we were to do that with ‘use’, it would break any code that sets a
variable in a package before the module with the same name has been loaded.

Consider $Data​::Dumper​::Useqq. I set that all the time when debugging.
If I should happen to leave that statement there by mistake (which
would usually be harmless on its own), then any other code in the same
process will be unable to load Data​::Dumper.

--

Father Chrysostomos

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 14, 2012

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 14, 2012

From @cpansprout

On Sun May 13 17​:55​:49 2012, sprout wrote​:

On Sun May 13 17​:30​:23 2012, LAWalsh wrote​:

And simply "use" doesn't
seem to support the above in any direct way (users are asked to
self-insert things in perl-internal arrays and such).

It would be much easier if the all of them supported the same
heuristics and richer sementics implemented in 'base'.

If we were to do that with ‘use’, it would break any code that sets a
variable in a package before the module with the same name has been
loaded.

Consider $Data​::Dumper​::Useqq. I set that all the time when debugging.
If I should happen to leave that statement there by mistake (which
would usually be harmless on its own), then any other code in the same
process will be unable to load Data​::Dumper.

Actually, I misunderstood what base.pm does. This would still be a
problem though, if Data​::Dumper is missing for whatever reason and ‘use’
is silent about it.

--

Father Chrysostomos

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 14, 2012

From @doy

On Sun, May 13, 2012 at 05​:30​:23PM -0700, Linda Walsh wrote​:

In order that "use" and "use parent" support similar semantics
as "use base", please enhance the first two to allow the same
semantics w/r/t​:

(from 'base' manpage)

   "base" employs some heuristics to determine if a module has already
   been loaded\, if it has it doesn't try again\. If "base" tries to
   "require" the module it will not die if it cannot find the module's
   file\, but will die on any other error\. After all this\, should your base
   class be empty\, containing no symbols\, it will die\. This is useful for
   inheriting from classes in the same file as yourself\, like so​:

           package Foo;
           sub exclaim \{ "I can have such a thing?\!" \}

           package Bar;
           use base "Foo";

Currently, "use parent", supports the above through a different and
incompatible syntax ("-norequire"); And simply "use" doesn't
seem to support the above in any direct way (users are asked to
self-insert things in perl-internal arrays and such).

It would be much easier if the all of them supported the same
heuristics and richer sementics implemented in 'base'.

As it stands, the 3 types of use, which I believe are all in "CORE",
support different semantics w/r/t multiple type-classes defined in the
same file.

As long as loading modules can have arbitrary effects in arbitrary
packages, I think that any heuristics about "has this module been loaded
already?" do not belong in core.

-doy

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 14, 2012

From @ikegami

On Sun, May 13, 2012 at 8​:30 PM, Linda Walsh <perlbug-followup@​perl.org>wrote​:

In order that "use" and "use parent" support similar semantics
as "use base", please enhance the first two to allow the same
semantics w/r/t​:

If you want that behaviour, use L<base>. L<parent> was specifically created
to deviate from that buggy behaviour of L<base>.

- Eric

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 14, 2012

From @demerphq

On 14 May 2012 08​:24, Eric Brine <ikegami@​adaelis.com> wrote​:

On Sun, May 13, 2012 at 8​:30 PM, Linda Walsh <perlbug-followup@​perl.org>
wrote​:

In order that "use" and "use parent" support similar semantics
as "use base", please enhance the first two to allow the same
semantics w/r/t​:

If you want that behaviour, use L<base>. L<parent> was specifically created
to deviate from that buggy behaviour of L<base>.

Thank you for calling it what it is. We would not have L<parent> if
L<base> were not perceived as buggy by design.

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 14, 2012

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

@p5pRT p5pRT closed this May 14, 2012
@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 19, 2012

From perl-diddler@tlinx.org

Father Chrysostomos via RT wrote​:

On Sun May 13 17​:55​:49 2012, sprout wrote​:

On Sun May 13 17​:30​:23 2012, LAWalsh wrote​:

And simply "use" doesn't
seem to support the above in any direct way (users are asked to
self-insert things in perl-internal arrays and such).

It would be much easier if the all of them supported the same
heuristics and richer sementics implemented in 'base'.

If we were to do that with ‘use’, it would break any code that sets a
variable in a package before the module with the same name has been

loaded.

Consider $Data​::Dumper​::Useqq. I set that all the time when debugging.
If I should happen to leave that statement there by mistake (which
would usually be harmless on its own), then any other code in the same
process will be unable to load Data​::Dumper.

Actually, I misunderstood what base.pm does. This would still be a
problem though, if Data​::Dumper is missing for whatever reason and ‘use’
is silent about it.


  If use base did that, it would be bad, but if it was written
correctly --
to look for code instances that would define a base (i.e. it would
require more than a
variable reference), then that shouldn't happen.

  Are you sure use 'base' will not load classes if you've referenced a
var from the class,
or is it smart enough to look for previous definitions of code?

  If it is the latter, and one has defined code in the class before a
use statement, it seems entirely reasonable not to load other 'code'
with the same
name.

I.e. usually if one has a 'cache', and one has loaded an object into the
cache, then one doesn't
goto disk to load that object if they check the in-memory copy first and
find it present.

I can't think of any system that ignores in-memory versions an object in
preference to a disk
copy -- by DEFAULT.

Certainly with an override, or a cache-flush, forcing a reload from disk
is an oft' included
feature.

But can anyone think of any systems or subsystems in computer science
where the default
is to ignore in-memory copies of them in preference for searching on disk?

I would go so far that if a computer found a copy of a file in memory or
a browser found an
object in memory that had not been marked 'invalid', and it defaulted to
pulling it in off disk,
most would consider it bug.

So why is perl backwards from what would seem to be the norm? Why
would it be
considered a bug to do that which not only is a default in other cached
v. disk copy
algorithms, but usually a performance enhancement as well?

Of course this presumes correct implementation of checking that a
class's code is in
memory, and not just data.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 19, 2012

From @Corion

Hello,

as the author of parent.pm, I think that some historical context will be
beneficial. Most of this can be found by using Google or another search
engine with the appropriate search terms. Please read these links to
familiarize yourself with the reasons why base.pm is as it is, and why
parent.pm exists​:

http​://www.nntp.perl.org/group/perl.perl5.porters/2007/07/msg127273.html

Also, a short description of some situations where base.pm fails to load
a file when you touch a namespace in the wrong place​:

http​://perlmonks.org/?node_id=738152

I also gave a talk at the German Perl Workshop on the problems with
base.pm. Unfortunately it's in German only, but maybe Babelfish gives
you an amusing translation [1].

http​://corion.net/talks/Probleme-mit-base.pm/probleme-mit-base.pm-talk.html

Are you sure use 'base' will not load classes if you've referenced
a var from the class, or is it smart enough to look for previous
definitions of code?
You could look at the code of base.pm to clear that question. The code
is surprisingly long for something that is documented as basically being
five lines.

But can anyone think of any systems or subsystems in computer
science where the default
is to ignore in-memory copies of them in preference for searching
on disk?
What does "computer science" have to do with the topic here? Please
consider that you are talking in a bug report/feature request, and
appeal to general ideas of "computer science" need to be justified as in
how they relate to the bug at hand. Consider for example at the
Perl-built-in "sysread", which does not use any buffering but asks the
operating system to load data from disk.

"Caching at every level" is not the motto of Perl.

So why is perl backwards from what would seem to be the norm?
[...]
Of course this presumes correct implementation of checking that
a class's code is in memory, and not just data.
Please familiarize yourself with the problems that base.pm has, to see
why changes to the API of parent.pm just won't happen. All the arguments
about maintaining backwards compatibility have already been made and I
don't want to repeat them.

-max

[1]
http​://98.139.168.220/babelfish/translate_url_content?.intl=de&lp=de_en&trurl=http%3A%2F%2Fcorion.net%2Ftalks%2FProbleme-mit-base.pm%2Fprobleme-mit-base.pm-talk.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant