Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > message forwarding in perl

Reply
Thread Tools

message forwarding in perl

 
 
Rainer Weikusat
Guest
Posts: n/a
 
      03-07-2013
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'.

 
Reply With Quote
 
 
 
 
Rainer Weikusat
Guest
Posts: n/a
 
      03-08-2013
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> 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.

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

 
Reply With Quote
 
 
 
 
Rainer Weikusat
Guest
Posts: n/a
 
      03-08-2013
Ben Morrow <(E-Mail Removed)> writes:

[...]

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

 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      03-08-2013
Rainer Weikusat <(E-Mail Removed)> writes:
> Ben Morrow <(E-Mail Removed)> writes:
>
> [...]
>
>> 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.

 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      03-11-2013
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:


[...]

>> 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.
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      03-11-2013
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> Ben Morrow <(E-Mail Removed)> writes:
>> >
>> > 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

>
> 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'.
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      03-12-2013
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:


[...]

>> 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.
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      03-12-2013
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> Ben Morrow <(E-Mail Removed)> writes:
>> > Quoth Rainer Weikusat <(E-Mail Removed)>:

>>
>> >> 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')

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

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

>
> 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).
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      03-12-2013
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> 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).

>
> 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.
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      03-13-2013
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> Ben Morrow <(E-Mail Removed)> writes:
>> > Quoth Rainer Weikusat <(E-Mail Removed)>:
>> >> 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).
>> >
>> > 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.

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
forwarding Args&&... vs forwarding Args... Andrew Tomazos C++ 5 01-05-2012 11:15 PM
Editing message before forwarding using AOL kipper Computer Support 10 03-15-2010 04:49 PM
Fritzbox: Message Waiting Indicator (MWI)? , Call forwarding to SIP ? Brian A UK VOIP 8 08-06-2007 03:20 PM
Message filtering before download? Automatic forwarding? Motorhead Lawyer Firefox 0 01-19-2005 05:07 PM
Automatic page forwarding in cgi perl script Max Perl Misc 12 07-15-2003 09:58 PM



Advertisments