message forwarding in perl

[Rainer Weikusat]

Another trivial thing I'm actually using: Can be implemented via
AUTOLOAD. The fact that UNIVERSAL->can and AUTOLOAD don't play nice
with each other is actually documented. Again, one has to wonder why
someone asks for this and specifically mentions a documented technical
limitation of the obvious answer to the question.

Since ->can, like ->DOES and any other way of enabling subroutines
which are not part of a class to make 'control flow descision' based
on the 'type' of some object shouldn't really exist to begin with (the
point of overloading is to eliminate explicit 'switching based on type
fields'), that's a small cost to pay.

A relatively trivial implementation is possible but I won't provide an
example here since this would be asking for another 'sideline
offensive'.

 

[Rainer Weikusat]

Yup, it's easy to do badly, and rather difficult to do well.

At least for suitable definitions of 'done badly' and 'done well'. I'm
using this to attach somewhat 'enhanced' functionality to the DBI
database and statement classes. In both cases, the original DBI
object is stored in an instance variable of the object (Again an
an array reference. "One million flies can't be wrong[*]" isn't an
argument except if one is aspiring to become the lord of the flies by
election) and if a method the replacement object doesn't implement is
called, AUTOLOAD compiles a 'delegation method' of the same name which
invokes the method on the DBI object with the same arguments and calls
that.

That's a perfectly working solution to the problem which needed to be
solved in this case. It is very likely not a 'perfectly working' (or
any kind of) solution for a lot of other problems which are more or
less related to the situation I had to deal with, however, that's no
concern of mine at the moment.

A certain kind of (recreational) programmers (or people with
software-related jobs who have no real problems to deal with and way
to much time on their hands) is convinced that the combined
washer-dryer-lawnmower-bicycle-tophat-eggwarmer-hovercraft-theodolite
would be the pinnacle of 'good software design', however, that's not
how things are constructed in the real world and there are good reason
for that (such as usability [complicated solutions to simple problems
are a pain in the ass] and reliabiliy [complicated stuff breaks more
often than simple stuff and in much more complicated ways]).

Possibly offensive content below the page break.

[*] I'm unsure if this is a well-known idiom outside of the small
German country town I was born in, so I'll include it here: "Scheisse
schmeckt gut. Millionen Fliegen koennen nicht irren." In English, that
would be "Poo must be tasty. Millions of flies can't be wrong".

 

[Rainer Weikusat]

[...]

Perl thinks much more in terms of 'an object is a data structure
with some functions attached to it' than 'an object is something you
can send messages to'.

Perl is an abstract concept and it can't think anyhing. It is
conceivable that the people/person who designed Perl OO thought in
this way and the (probably) C++-inspired method invocation syntax
actually suggests this. But de facto, the Perl method dispatch
mechanism is a message-passing system in all but the name: Any
reference object can have a 'current message interpreter' attached
(this attachment can be changed at runtime) and while there's a
'default' method of locating a subroutine supposed to be executed in
response to a message (namely, look at the 'function slot' of the glob
which is presently associated with the message 'title' in the symbol
table of the 'interpreter' package), the 'interpreter package' can
implement an arbitrary 'other dispatching scheme' via AUTOLOAD.

This may be an unintentional side effect of a couple of design
descisions and possibly even one 'certain people' are not even aware
of, but "It's alive" and this property can be used.

 

[Rainer Weikusat]

[...]

Perl thinks much more in terms of 'an object is a data structure
with some functions attached to it' than 'an object is something you
can send messages to'.

Perl is an abstract concept and it can't think anyhing. It is
conceivable that the people/person who designed Perl OO thought in
this way and the (probably) C++-inspired method invocation syntax
actually suggests this. But de facto, the Perl method dispatch
mechanism is a message-passing system in all but the name: Any
reference object can have a 'current message interpreter' attached
(this attachment can be changed at runtime) and while there's a
'default' method of locating a subroutine supposed to be executed in
response to a message (namely, look at the 'function slot' of the glob
which is presently associated with the message 'title' in the symbol
table of the 'interpreter' package), the 'interpreter package' can
implement an arbitrary 'other dispatching scheme' via AUTOLOAD.

Further, and that's the actually crucial part: The way 'method lookup'
works is independent of the code trying to invoke the method, of
the 'object' which is used as invocant and of the 'current message
interpreter' attached to this object: A string which comes from the
invoking code is mapped to a subroutine by using the 'current
interpreter' (stash) property of the 'instance reference' to locate a
package and then searching for a subroutine with this name in the
symbol table of this package (and the symbol tables of the 'parent
package(s)'): Any code can invoke any method on any object.

 

[Rainer Weikusat]

Quoth Rainer Weikusat <[email protected]>:
[...]

if a method the replacement object doesn't implement is called,
AUTOLOAD compiles a 'delegation method' of the same name which
invokes the method on the DBI object with the same arguments and
calls that.

That's a perfectly working solution to the problem which needed to be
solved in this case. It is very likely not a 'perfectly working' (or
any kind of) solution for a lot of other problems which are more or
less related to the situation I had to deal with, however, that's no
concern of mine at the moment.

Incomplete solutions are useful, yes, especially when one is trying to
get things done quickly, but they are inherently fragile.

This is a completely 'complete' solution to a specific problem and it
is not at all 'fragile', it just doesn't support some features you
consider important and I don't (because I don't use them). Should
there ever be a need for ...

[...]

pass one of these delegation objects to something like Storable
which expects ->can to work properly, or something which expects
->isa or (worse) UNIVERSAL::isa to give the right answers.

.... passing such an object to
$random_bad_code_downloaded_from_the_net ('bad' here supposed to
mean that it pokes around in the innards of objects it didn't create
which is an 'inherently fragile' way to hack around structural
deficiencies in a class hierarchy) the necessary feature can always be
added.

 

[Rainer Weikusat]

You snipped the bit where I pointed out that overload (that is, one of
the core perl pragmas) does this.

And I've also snipped the bit were you asserted that not implementing
an unneeded feature which seems very dear to do would imply that 'the
code was "done quickly" and without "thinking about it"'. The
pointless invective was as irrelevant to what I wanted to write as the
remark about auto-generating 'operator methods'.

 

[Rainer Weikusat]

Quoth Rainer Weikusat <[email protected]>:
[...]

it pokes around in the innards of objects it didn't create which is
an 'inherently fragile' way to hack around structural deficiencies
in a class hierarchy) the necessary feature can always be added.

In a dynamic language like Perl, reflection (that is, structured access
to metadata like 'what is this object' and 'what can it do') is really
important. The whole point of methods like ->can is to allow access to
this metadata *without* poking around in the innards of the object.

To be fair: You have a point regarding overload (which is, after all,
supposed to fiddle with the way 'a class' 'works') and even about
Storable (where alternate options would be 'inconvenient to users')
but 'my inner self' revolts against that: Outside of debuggers, this
kind of stuff shouldn't be necessary and no, I don't have a better
idea myself at the moment.

 

[Rainer Weikusat]

Well, the documented public interface of overload could be implemented
without doing anything unclean, but the result would (apparently) be so
slow as to be unusable. Specifically, the implementation goes to great
lengths to avoid making unoverloaded operations do a method lookup.

What I was trying to get at is that it is the purpose of overload to
poke around in the innards of 'other classes/ packages', hence, it
must be obviously be excused for doing so.

Oh, I agree entirely. Perl 5 OO, once you get past the basic C++ish
stuff, is rather a mess;

What I was trying to express is that the UNIVERSAL methods really
shouldn't exist because 'objects' are not supposed to be 'inspected'
by code which isn't a method associated with the particular object in
question. This property is usually known as 'encapsulation'. This is
especially true in 'dynamic languages like Perl' because any property
of 'an object' can change at any time. This includes changes to the
set of messages understood by 'a class', changing the 'response
subroutines' and changing the package association of a particular
reference.

I totally disagree with the opinion that 'Perl 5 OO' would be 'rather
a mess'. I usually undestand this as code language for 'it is
different from $something I happen to be familiar with AND I
ABSOLUTELY HATE THAT !!!!1', glossed over with pseudo-rationalization
constructed in the usual, hackneyed way' ('the usual way' being
'emphasizing the disadvantages of the undesired something while
ignoring the advantages, vice versa for the preferred something' and
resorting to character assassination in order to discredit people who
don't agree with this opinion).

[...]

Perl 6's OO model was an attempt to clean all this up, and provide a
system which was less flexible in unimportant ways while allowing the
remaining, useful, flexibility to be used

As Larry Wall put it: "Second system done right". And insofar the
so-called 'second system effect' is considered, they couldn't possibly
have done it more right (In case someone doesn't understand this: This
means they blew it completely by trying to remedy everything anybody
ever criticized uncritically at the same time, leading to a
horrendous, bloated mess of 'unintegrated' ideas randomly stolen from
a myriad different sources and consequently, a lack-of-design which
takes an eternity to implement and which will be totally obsolete and
abandoned by all people who were once interested in using it except
hardcore fanboys by the time it is considered to be complete -- if
this ever happens).

 

[Rainer Weikusat]

Oh dear. And for a minute there you were being so reasonable...

'Being reasonable' and 'agreeing with opinion X' are two very much
different things.

 

[Rainer Weikusat]

The first sentence I quoted I left in for context; it's not directly
pertinent to my reply. My problem is with the rest of the paragraph.

'Your problem' seems to be 'how to turn this away from Perl and into
an [entirely personal] flamewar' and the approach you seem to be
taking, namely, suggesting that people who employ literary devices in
a way you wouldn't, must clearly "be mad [!!2]" and hence, their
opinions can be disregarded, isn't exactly 'new and creative'
(searching for 'people hate perl' on the web easily uncovers texts
which argue that 'Perl can be disregarded' because it was 'clearly
designed by a total madman' based on the style of writing used in some
of the published 'state of the onion' texts) and it is also illogical
(not a great surprise): No statement about me, even if this statement
happened to be true, enables any valid conclusions about any statement
made by me: It could be 'truthful and valid' merely by
coincidence.

NB: This obviously cuts both ways and my conviction that especially a
lot of the more heated criticism about 'Perl OO' one can find on the
web is - ultimatively - manifest xenophobia doesn't imply anything
about the truthfulness of these statements either. But since you were
essentially just repeating the party line, eg, the bit about 'keyword
reuse' which can be found directly in the Perl 6 OO 'design
apocalypse' (alongside 'second system done right' --- isn't it great
how ambiguities in natural language always lend themselves to
'interesting alternate interpretations'?[*] --- Considering my opinion
on Perl 6, 'design apocalypse' seems a very accurate label) a reply
decomposing this text into 'high-level functional units' [a little],
combined with a hint at their purpose, seemed appropriate. Not the
least because of your absolutely marvellous 'demonstration follow-up'.

[*] I need to make an exception for 'It is too minimal' here. This is
just plain nonsense --- the minimum may be too little or not enough
but it can't be 'too minimal' since this already a superlative.

 

[Rainer Weikusat]

[...]

Considering my opinion on Perl 6, 'design apocalypse' seems a very
accurate label

Nit-picking addition: Since most people don't know any Greek, they
don't understand this as 'relevation' but as some vague remembrance
of the content of the book of relevations, IOW, ragnaroek without the
happy ending (it is really difficult to avoid Greek words which mean
'something completely different' when writing about this, eg,
catastrophe ...).

 

[Rainer Weikusat]

[...]

Once you stopped accusing anyone you disagree with of fascism

This is actually another classic, namely, the 'Have you stopped
beating your wife' question.

 

[Rainer Weikusat]

[...]

Once you stopped accusing anyone you disagree with of fascism

This is actually another classic, namely, the 'Have you stopped
beating your wife' question.

Absolutely last attempt at turning this back into a rational
discussion: Would you perhaps have the unbelievable kindness to stop
ventilating your totally unsubstantiated assumptions about me?

 

[Rainer Weikusat]

If you will do likewise. I am referring here to

I usually undestand this as code language for 'it is different from
$something I happen to be familiar with AND I ABSOLUTELY HATE THAT
!!!!1', glossed over with pseudo-rationalization constructed in the
usual, hackneyed way' ('the usual way' being 'emphasizing the
disadvantages of the undesired something while ignoring the
advantages, vice versa for the preferred something' and resorting to
character assassination in order to discredit people who don't agree
with this opinion).

and other comments of that nature.

I have no idea what 'other comments of this nature' could possibly
be and what your precise problem with this text actually is. It
certainly doesn't contain anything specifically targetted at you but
some general observations about the ways people behave.

 

[Rainer Weikusat]

I have no idea what

Emphasis: This is supposed to mean that I have really no idea, not
some other 'weird' interpretation which might suggest itself. I
usually talk to computers because they're 'reasonably' simple and
predictable while I avoid most people because they confuse me, I have
no real idea how to deal with them and usually, dealing with them
isn't necessary.