MJD HOP influence

Discussion in 'Perl Misc' started by Matija Papec, Aug 27, 2005.

  1. Matija Papec

    Matija Papec Guest

    It seems that functional approach is better suited for smaller "classes"
    compared to classical OOP. Thinking in such way is challenging and pretty
    new to me so I would be interested to hear suggestions; eg. is there some
    flaw which can show in threading environment or how to optimize this very
    basic OO example below.


    ===========================
    use strict;
    use warnings;

    my $obj = Child(foo => 1, bar =>2);
    $obj->(addcond => [id => 7]);
    $obj->(addcond => [name => "lucas"]);

    print $obj->(dumper => 1) if $obj->(can => "dumper");


    sub Child {
    #
    # child class
    #
    our ($AUTOLOAD, $SUPER);
    # child object data
    my @foobar;

    my $m = {
    AUTOLOAD => sub {
    my $self = shift;
    print "There is no $AUTOLOAD!\n";
    return;
    },
    dumper => sub {
    my $self = shift;
    $SUPER->(dumper => @_);
    },
    addcond => sub {
    my $self = shift;
    # get $SUPER via $self
    # $AUTOLOAD contains current method name
    $self->("SUPER")->($AUTOLOAD => @_);
    },
    };
    return newclosure(usebase => \&Parent, $m, @_);
    }

    sub Parent {
    #
    # parent class
    #
    use Data::Dumper;
    # object data
    my %arg = @_;
    my @cmdcond;

    my $m = {
    dumper => sub {
    my $self = shift;
    Dumper \@cmdcond, \%arg;
    },
    addcond => sub {
    my $self = shift;
    push @cmdcond, shift;
    },
    };
    return newclosure($m, @_);
    }


    #########################################
    sub newclosure {
    #
    our ($AUTOLOAD, $SUPER);
    my $m = shift;

    my $usebase;
    my $super;
    # inheritance?
    if ($m eq "usebase") {
    $usebase = shift;
    $m = shift;
    $super = &$usebase;
    }

    # core methods
    $m->{SUPER} = sub { $super };
    $m->{can} = sub {
    my $self = shift;
    my $sub = shift;
    $m->{$sub} || $super->(can => $sub) || $m->{AUTOLOAD};
    };

    my $self;
    return $self = sub {
    my $sub = shift;
    local $AUTOLOAD = $sub;
    local $SUPER = $super;

    # who you gonna call?
    return
    $m->{$sub} ? $m->{$sub}->($self, @_) :
    $super->(can => $sub) ? $super->($sub, @_) :
    $m->{AUTOLOAD}->($self, @_);
    };
    }


    --
    Matija
    Matija Papec, Aug 27, 2005
    #1
    1. Advertising

  2. Matija Papec

    Anno Siegel Guest

    Matija Papec <> wrote in comp.lang.perl.misc:
    >
    > It seems that functional approach is better suited for smaller "classes"
    > compared to classical OOP.


    With "functional approach", do you mean a class whose objects are
    coderefs? What is the "classical" approach and what are the advantages
    you see?

    > Thinking in such way is challenging and pretty
    > new to me so I would be interested to hear suggestions; eg. is there some
    > flaw which can show in threading environment or how to optimize this very
    > basic OO example below.


    There is no OO in your example. The hallmark of Perl OO is that objects
    are blessed into their class. This never happens here. Neither are the
    calls

    $obj->(addcond => [id => 7]);

    etc. method calls, this is just the syntax to call a coderef. So whatever
    you have built, it isn't an alternative to a classical OO approach.

    Otherwise, classes whose objects are coderefs offer better protection
    (and harder access to) the the object variables, assuming that the
    object variables are implemented as private lexicals. They are usually
    harder to deal with than more conventional implementations. The size
    of the class (in terms of number and complexity of methods) has little
    to do with the advantages and drawbacks of this approach.

    Anno

    > ===========================
    > use strict;
    > use warnings;
    >
    > my $obj = Child(foo => 1, bar =>2);
    > $obj->(addcond => [id => 7]);
    > $obj->(addcond => [name => "lucas"]);
    >
    > print $obj->(dumper => 1) if $obj->(can => "dumper");
    >
    >
    > sub Child {
    > #
    > # child class
    > #
    > our ($AUTOLOAD, $SUPER);
    > # child object data
    > my @foobar;
    >
    > my $m = {
    > AUTOLOAD => sub {
    > my $self = shift;
    > print "There is no $AUTOLOAD!\n";
    > return;
    > },
    > dumper => sub {
    > my $self = shift;
    > $SUPER->(dumper => @_);
    > },
    > addcond => sub {
    > my $self = shift;
    > # get $SUPER via $self
    > # $AUTOLOAD contains current method name
    > $self->("SUPER")->($AUTOLOAD => @_);
    > },
    > };
    > return newclosure(usebase => \&Parent, $m, @_);
    > }
    >
    > sub Parent {
    > #
    > # parent class
    > #
    > use Data::Dumper;
    > # object data
    > my %arg = @_;
    > my @cmdcond;
    >
    > my $m = {
    > dumper => sub {
    > my $self = shift;
    > Dumper \@cmdcond, \%arg;
    > },
    > addcond => sub {
    > my $self = shift;
    > push @cmdcond, shift;
    > },
    > };
    > return newclosure($m, @_);
    > }
    >
    >
    > #########################################
    > sub newclosure {
    > #
    > our ($AUTOLOAD, $SUPER);
    > my $m = shift;
    >
    > my $usebase;
    > my $super;
    > # inheritance?
    > if ($m eq "usebase") {
    > $usebase = shift;
    > $m = shift;
    > $super = &$usebase;
    > }
    >
    > # core methods
    > $m->{SUPER} = sub { $super };
    > $m->{can} = sub {
    > my $self = shift;
    > my $sub = shift;
    > $m->{$sub} || $super->(can => $sub) || $m->{AUTOLOAD};
    > };
    >
    > my $self;
    > return $self = sub {
    > my $sub = shift;
    > local $AUTOLOAD = $sub;
    > local $SUPER = $super;
    >
    > # who you gonna call?
    > return
    > $m->{$sub} ? $m->{$sub}->($self, @_) :
    > $super->(can => $sub) ? $super->($sub, @_) :
    > $m->{AUTOLOAD}->($self, @_);
    > };
    > }
    >
    >
    > --
    > Matija



    --
    If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers.
    Anno Siegel, Aug 29, 2005
    #2
    1. Advertising

  3. Matija Papec

    Matija Papec Guest

    X-Ftn-To: Anno Siegel

    -berlin.de (Anno Siegel) wrote:
    >> It seems that functional approach is better suited for smaller "classes"
    >> compared to classical OOP.

    >
    >With "functional approach", do you mean a class whose objects are
    >coderefs? What is the "classical" approach and what are the advantages
    >you see?


    By classic OO perl I mean using package and blessing hash/array/etc into it.
    Potential advantage is avoiding separate file/package when you only need a
    few methods for your objects.

    > The hallmark of Perl OO is that objects
    >are blessed into their class. This never happens here. Neither are the


    True, but nobody claimed otherwise..

    > $obj->(addcond => [id => 7]);
    >
    >etc. method calls, this is just the syntax to call a coderef. So whatever
    >you have built, it isn't an alternative to a classical OO approach.


    That depends on what do you mean it should provide to be an alternative.
    This example has *some* OO qualities like object methods and inheritance; in
    that way it follows OO paradigm (OO paradigm in general, not that of perl).

    >Otherwise, classes whose objects are coderefs offer better protection
    >(and harder access to) the the object variables, assuming that the
    >object variables are implemented as private lexicals. They are usually
    >harder to deal with than more conventional implementations. The size


    Yes; unfortunately I'm not sure if you can inherit from such class; perhaps
    building parent so it can provide data container for it's children?

    >of the class (in terms of number and complexity of methods) has little
    >to do with the advantages and drawbacks of this approach.


    Now that you mention this, I can only say that my OO coderefs doesn't suffer
    completely like blessed ones. :)



    --
    Matija
    Matija Papec, Aug 29, 2005
    #3
  4. Matija Papec

    Anno Siegel Guest

    Matija Papec <> wrote in comp.lang.perl.misc:
    > X-Ftn-To: Anno Siegel
    >
    > -berlin.de (Anno Siegel) wrote:
    > >> It seems that functional approach is better suited for smaller "classes"
    > >> compared to classical OOP.

    > >
    > >With "functional approach", do you mean a class whose objects are
    > >coderefs? What is the "classical" approach and what are the advantages
    > >you see?

    >
    > By classic OO perl I mean using package and blessing hash/array/etc into it.


    That's what I mean too.

    > Potential advantage is avoiding separate file/package when you only need a
    > few methods for your objects.


    Avoiding a separate *file* is usually just a matter of source organization,
    it can be done with any implementation. Avoiding a *package* goes to
    the root of Perl OO since classes are normally packages. So the question
    is, what takes the role of classes in this implementation? I sincerely
    don't see what does.

    > > The hallmark of Perl OO is that objects
    > >are blessed into their class. This never happens here. Neither are the

    >
    > True, but nobody claimed otherwise..


    Then please explain the terms: What are objects in this implementation,
    what are methods and what are classes. I can't think of an OO system
    that doesn't define these.

    I haven't read HOP cover to cover yet. Perhaps you could point out
    what part of the book stimulated your code so others can read up on
    the background.

    > > $obj->(addcond => [id => 7]);
    > >
    > >etc. method calls, this is just the syntax to call a coderef. So whatever
    > >you have built, it isn't an alternative to a classical OO approach.

    >
    > That depends on what do you mean it should provide to be an alternative.
    > This example has *some* OO qualities like object methods and inheritance; in
    > that way it follows OO paradigm (OO paradigm in general, not that of perl).


    What are the object methods, and what are objects, and how does
    inheritance happen? Normally inheritance goes from one class to another.
    Without defining what classes are, it is impossible to even talk about
    inheritance.

    > >Otherwise, classes whose objects are coderefs offer better protection
    > >(and harder access to) the the object variables, assuming that the
    > >object variables are implemented as private lexicals. They are usually
    > >harder to deal with than more conventional implementations. The size

    >
    > Yes; unfortunately I'm not sure if you can inherit from such class; perhaps
    > building parent so it can provide data container for it's children?


    With a standard implementation of a Perl class with objects that happen
    to be coderefs, inheritance happens like with any other Perl class.
    As usual in Perl OO, it depends on the implementation of the base
    class whether inheritance is easy, hard or impossible. There is
    nothing fundamentally different from classes whose objects are (say)
    hashrefs.

    > >of the class (in terms of number and complexity of methods) has little
    > >to do with the advantages and drawbacks of this approach.

    >
    > Now that you mention this, I can only say that my OO coderefs doesn't suffer
    > completely like blessed ones. :)


    Sorry, I don't understand this sentence.

    Anno
    --
    If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers.
    Anno Siegel, Aug 30, 2005
    #4
  5. Matija Papec

    Matija Papec Guest

    X-Ftn-To: Anno Siegel

    >Then please explain the terms: What are objects in this implementation,
    >what are methods and what are classes. I can't think of an OO system
    >that doesn't define these.


    See below.

    >I haven't read HOP cover to cover yet. Perhaps you could point out
    >what part of the book stimulated your code so others can read up on
    >the background.


    At the beginning Mark wrote that functional and OO approach are solving the
    same problems so I've tried if functional could simulate OO.

    >> This example has *some* OO qualities like object methods and inheritance; in
    >> that way it follows OO paradigm (OO paradigm in general, not that of perl).

    >
    >What are the object methods, and what are objects, and how does
    >inheritance happen? Normally inheritance goes from one class to another.
    >Without defining what classes are, it is impossible to even talk about
    >inheritance.


    Sorry, I thought this is obvious; "classes" are sub Parent and sub Child,
    object is what you get after calling either of these two ($obj), and class
    methods are defined in %$m. If $obj comes from Child, it can call all Child
    methods in addition to those defined in Parent as Child is inheriting from
    Parent (usebase => \&Parent defines this relationship).
    Beside, Child can override Parent methods but it can also call them via
    $SUPER.

    >> >Otherwise, classes whose objects are coderefs offer better protection
    >> >(and harder access to) the the object variables, assuming that the
    >> >object variables are implemented as private lexicals. They are usually
    >> >harder to deal with than more conventional implementations. The size

    >>
    >> Yes; unfortunately I'm not sure if you can inherit from such class; perhaps
    >> building parent so it can provide data container for it's children?

    >
    >With a standard implementation of a Perl class with objects that happen
    >to be coderefs, inheritance happens like with any other Perl class.
    >As usual in Perl OO, it depends on the implementation of the base
    >class whether inheritance is easy, hard or impossible. There is
    >nothing fundamentally different from classes whose objects are (say)
    >hashrefs.


    Perhaps, but possibility to inherit from class which uses scalar/coderef
    goes more often toward impossible then it would go in case when base class
    uses hashref. If it isn't much trouble, can you point to good example of
    class using coderefs and it's easily inheritable?

    >> >of the class (in terms of number and complexity of methods) has little
    >> >to do with the advantages and drawbacks of this approach.

    >>
    >> Now that you mention this, I can only say that my OO coderefs doesn't suffer
    >> completely like blessed ones. :)

    >
    >Sorry, I don't understand this sentence.


    In my example coderefs are some kind of objects and my base class doesn't
    have to worry how it could be inherited by other class, as opposed to
    blessed coderef, where their class *has to think* about possible
    inheritance.


    --
    Matija
    Matija Papec, Aug 30, 2005
    #5
    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. Alex Callea
    Replies:
    4
    Views:
    495
    David Browne
    Nov 9, 2004
  2. =?Utf-8?B?V2hpc2t5Um9tZW8=?=

    How to influence who the User is

    =?Utf-8?B?V2hpc2t5Um9tZW8=?=, Feb 13, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    364
    Alec MacLean
    Feb 13, 2006
  3. Peter Hartmann
    Replies:
    1
    Views:
    293
    Tim Roberts
    Sep 18, 2005
  4. Claudius
    Replies:
    2
    Views:
    317
    Bo Persson
    Feb 25, 2006
  5. Rich Morin

    "Design patterns of 1972", by MJD

    Rich Morin, Sep 13, 2006, in forum: Ruby
    Replies:
    0
    Views:
    99
    Rich Morin
    Sep 13, 2006
Loading...

Share This Page