in reply to Functional Inside Out Closure Objects

I, like many people (See the number of Class::* modules on CPAN), have sought to make oop easier in perl.

Personally, I never really thought of OOPerl as hard, ugly yes, primative maybe, clobbered on, for sure, but not really all that hard. :P

It is my understanding that when closures are used that the different version of a closure share the same code but just use a different set of lexicals. So I think that the overhead for an individual object should just be the set of lexicals plus the references to the CODE objects. Is this a correct understanding of how closures work?

This is pretty much my understand of closures as well. Although I cannot say for sure that it is correct :)

My second question about overhead is the use of the "goto" in the methods

You could likely get rid of the goto if you wanted to. Instead of evaling your code like this:

# create method my $eval = "sub $class\:\:$name { goto \$hash{\$_[0]}}\n"; eval $eval;
You could just do some symbol table mangling like this:
*{"${class}::$name"} = $ref;
The result should be the same, but no goto.


Replies are listed 'Best First'.
Re: Re: Functional Inside Out Closure Objects
by fletcher_the_dog (Friar) on May 20, 2004 at 16:25 UTC
    Actually, this would not be the same. ${class}::$name would point to the CODE ref for the last object that was created. With the way I have it, the goto jumps to the CODE ref for the particular instance that the method is being called on.

      Nevermind me, I am still half asleep. You are right, I was reading the source wrong. However, in light of my new understanding of your module, I would tend to agree with dave_the_m that this is creating a rather large overhead for your module. Not to mention that you may find yourself having to deal with the nested closure memory leak issue.

Re: Re: Functional Inside Out Closure Objects
by sth (Priest) on May 20, 2004 at 17:19 UTC

    Personally, I never really thought of OOPerl as hard, ugly yes,

    Ugly? why?


      To start with, perl's object system was a bolt-on to the existsing module system, which is both ugly (because it kind of exposes the soft underbelly of objects) and cool at the same time (you can do some crazy stuff with modules/typeglobs, and you can now do them with objects too :)

      How it handles inheritance is another.

      package Foo; @ISA = qw(Bar);
      This takes the idea of inheritance and converts it into a "magic" laden assignment statement. This exposes too much of the details of how perl manages inheritance, which IMO is ugly. Maybe I am a purist, but I think that declaring inheritance should be part of the class declaration, or at the very least have its own keyword.

      Constructors in perl are nothing special, which at first glance is cool, but it does lead to some ugly code when calling base class constructors in subclasses. I personally like the C# syntax for these things:

      class Bar { string name; public Bar (string name) { = name; } } class Foo : Bar { Hashtable attributes; public Foo (string name, Hashtable attributes) : base(name) { this.attributes = attributes; } }
      Also, the idea that an object is just a blessed reference IMO is another double edged sword. It makes encapsulation a big issue/problem. (Sure I know you can do Inside-Out objects and closures, etc etc etc, but all of them just add to the already touchy syntax.) Now I know the idea is that you shouldn't mess with the internals because you were not invited, and that it then becomes a social problem. But I would rather not have the social problem at all and have strong encapsulation.

      All this said, I love perl, so I have worked with/around all this stuff in my own way, but it doesn't change the underlying ugliness of it. And yes, some might call this elegance, and I will be the first to admit that there is a fair amount of elegance in how minimally invasive the adding of objects to perl was, but when you get deep into the thick of it, there is some real ugliness there no matter what.

        This takes the idea of inheritance and converts it into a "magic" laden assignment statement.
        Huh? use base was invented to address those concerns. Check it out.