# New Ticket Created by Linda Walsh
# Please include the string: [perl #47181]
# in the subject line of all future correspondence about
this issue.
# <URL: h
ttp://rt.perl.org/rt3/Ticket/Display.html?id=47181 >
This is a bug report for perl from perl-diddler tlinx.org,
generated with the help of perlbug 1.35 running under perl
v5.8.8.
This is a suggestion to make perl "less
surprising" for people who have
been exposed to Object Oriented (OO) concepts outside of
perl. Not that
it is the "ultimate source", but _consistent_ with
my view that there
exist, general OO concepts, and that one of those has to do
with a local
"method" overriding a parent, or base class
method. Specifically,
quoting from Wikipedia's currently listed entry on
"method overriding":
"Method overriding, in object oriented programming, is
a language
feature that allows a subclass to provide a __specific_
_implementation__ of a method that is already provided by
one of its
superclasses. The _implementation_ in the subclass
overrides
(replaces) the implementation in the superclass."
The underlines are mine -- since some believe that supplying
an
"undefined, forwardly-declared function stub"
qualifies, in perl, as a
"specific implementation" that should replace the
implementation in the
superclass.
Perl has runtime features that can turn what may seem to be
an undefined
function stub, and turn it into something useful via Perl's
AUTOLOAD
functionality that can catch, undefined subroutines and load
them at
runtime.
However, after AUTOLOAD has been attempted (in order to
maintain
consistency with past behavior), if the requested function
is _still_
undefined and Perl is about to 'throw' a Fatal Undefined
exception, then
as a last-ditch effort to do *something* that the user might
have meant;
if the user used "OO-syntax" instead of a normal
looking function call,
then I am requesting that perl (as an enhancement to more
closely align
itself with some people's expectations of OO behavior)
search the
object's base classes to see if the method is defined in the
parent.
If so, then call that parent, AND (if warnings are turned
on), issue
a runtime warning, about the local stub being ignored.
Since this change would only be applied before Perl would
normally have
died from a fatal error, I can't see it affecting current
programs --
only programs that would have died anyway. This way -- at
runtime,
the user is given a warning about the local-stub, and perl
tries to
do what the user likely intended (i.e. - the
"&method" was in the same
package (and was local) to where "sub method{}"
was defined, but the
two lines of code had become separated; the &method was
meant to refer
to the parent's method, but had become outdated/non-intended
code
due to the split. An example generating the Undef error:
package A;
sub method {'method'};
package B; ISA=qw(A);
sub setup_error{ $x=&method;}
package main;
bless my $ref={},B;
print $ref->method . "n";
$ref->setup_error();
print $ref->method . "n";
===
Instead of "Undefined subroutine &B::method
called...", Perl could
look for and call "method" as defined in package
A.
---
Flags:
category=core
severity=low
---
Site configuration information for perl v5.8.8:
Configured by rurban at Sun Jul 8 19:08:44 GMT 2007.
Summary of my perl5 (revision 5 version 8 subversion 8)
configuration:
Platform:
osname=cygwin, osvers=1.5.24(0.15642),
archname=cygwin-thread-multi-64int
uname='cygwin_nt-5.1 reini 1.5.24(0.15642) 2007-01-31
10:57 i686 cygwin '
config_args='-de -Dmksymlinks -Duse64bitint -Dusethreads
-Uusemymalloc -Doptimize=-O3 -Dman3ext=3pm
-Dusesitecustomize -Dusedevel'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef
useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define
usesocks=undef
use64bitint=define use64bitall=undef
uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV
-fno-strict-aliasing -pipe -Wdeclaration-after-statement',
optimize='-O3',
cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing
-pipe -Wdeclaration-after-statement'
ccversion='', gccversion='3.4.4 (cygming special, gdc
0.12, using dmd 0.125)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8,
byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define,
longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='ld2', ldflags =' -s -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /lib
libs=-lgdbm -ldb -ldl -lcrypt -lgdbm_compat
perllibs=-ldl -lcrypt -lgdbm_compat
libc=/usr/lib/libc.a, so=dll, useshrplib=true,
libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef,
ccdlflags=' -s'
cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'
Locally applied patches:
CYG01 - hints.cygwin.sh ldflags -s
CYG02 - lib-ExtUtils-Embed insensitive against leading
\s
CYG03 - lib-Test-Harness-Straps $ENV = ''
CYG04 - major.version.cygwin.sh cygperl-5_8.dll and not
cygperl-5_8_x.dll
CYG05 - add Win32CORE to core
CYG07 - File-Spec-Cygwin-TMPDIR.patch
Bug#38628 - allow legacy Cwd->cwd()
Bug#40103 - File-Spec-case_tolerant.patch from 5.9.5
---
INC
for perl v5.8.8:
/usr/lib/perl5/5.8/cygwin
/usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8
/usr/lib/perl5/vendor_perl/5.8
.
---
Environment for perl v5.8.8:
CYGWIN=notitle glob:ignorecase export
HOME=/home/law
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=.:/sbin:/usr/sbin:/home/law/scripts:/home/law/bin:/usr/
local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/bin:/usr/lib:/WI
NDOWS/system32:/WINDOWS:/WINDOWS/System32/Wbem:/Prog/XP-Supp
ort Tools:/Prog/sysinternals:/Prog/Codeplay:/Prog/Common
Files/GTK/2.0/bin:/Prog/Microsoft Visual
Studio/Tools:/usr/lib/lapack:/c/Prog/Sysinternals/cmd
PERL_BADLANG (unset)
SHELL=C:/bin/bash.exe
|