message forwarding in perl

Discussion in 'Perl Misc' started by Rainer Weikusat, Mar 7, 2013.

  1. 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, Mar 7, 2013
    #1
    1. Advertising

  2. Ben Morrow <> writes:
    > Quoth 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.

    >
    > 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, Mar 8, 2013
    #2
    1. Advertising

  3. Perl method dispatching (was: message forwarding in perl)

    Ben Morrow <> 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.
    Rainer Weikusat, Mar 8, 2013
    #3
  4. Re: Perl method dispatching

    Rainer Weikusat <> writes:
    > Ben Morrow <> 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.
    Rainer Weikusat, Mar 8, 2013
    #4
  5. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:


    [...]

    >> 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, Mar 11, 2013
    #5
  6. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >> Ben Morrow <> 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'.
    Rainer Weikusat, Mar 11, 2013
    #6
  7. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:


    [...]

    >> 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, Mar 12, 2013
    #7
  8. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >> Ben Morrow <> writes:
    >> > Quoth Rainer Weikusat <>:

    >>
    >> >> 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).
    Rainer Weikusat, Mar 12, 2013
    #8
  9. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >> 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.
    Rainer Weikusat, Mar 12, 2013
    #9
  10. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >> Ben Morrow <> writes:
    >> > Quoth Rainer Weikusat <>:
    >> >> 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.
    Rainer Weikusat, Mar 13, 2013
    #10
  11. Rainer Weikusat <> writes:

    [...]

    > 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, Mar 13, 2013
    #11
  12. Ben Morrow <> writes:

    [...]

    > 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, Mar 14, 2013
    #12
  13. Rainer Weikusat <> writes:
    > Ben Morrow <> writes:
    >
    > [...]
    >
    >> 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, Mar 14, 2013
    #13
  14. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >> Rainer Weikusat <> writes:
    >> > Ben Morrow <> writes:
    >> >
    >> >> 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?

    >
    > 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, Mar 14, 2013
    #14
  15. Rainer Weikusat <> writes:
    > Ben Morrow <> writes:
    >> Quoth Rainer Weikusat <>:
    >>> Rainer Weikusat <> writes:
    >>> > Ben Morrow <> writes:
    >>> >
    >>> >> 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?

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


    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.
    Rainer Weikusat, Mar 14, 2013
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eqbal Z
    Replies:
    1
    Views:
    1,232
  2. Andrew Tomazos
    Replies:
    5
    Views:
    562
  3. Max
    Replies:
    12
    Views:
    326
    Jacqui Caren
    Jul 15, 2003
  4. Debashish Mishra

    Port forwarding utility in perl

    Debashish Mishra, Jun 16, 2004, in forum: Perl Misc
    Replies:
    2
    Views:
    102
    Joe Smith
    Jun 20, 2004
  5. sverne

    Perl access to email forwarding

    sverne, Mar 16, 2006, in forum: Perl Misc
    Replies:
    2
    Views:
    154
Loading...

Share This Page