Like Tree1Likes
  • 1 Post By MK27

A better perl -- translation

This is a discussion on A better perl -- translation within the Linux Programming forums, part of the Platform Specific Boards category; I think I've created a better perl language by introducing classes, introducing the 'dot' operator, having better private attributes to ...

  1. #1
    UT2004 Addict Kleid-0's Avatar
    Join Date
    Dec 2004
    Posts
    656

    A better perl -- translation

    I think I've created a better perl language by introducing classes, introducing the 'dot' operator, having better private attributes to objects (through Alias's attr operator), introducing the 'new' keyword to create objects, and having arguments for subroutines:
    Code:
    my $o = new Object;
    die "didn't work" unless $o.set(_attribute => 3.14);
    class Object {
      sub Object($classname){
        return bless {
          _attribute => 0
        };
      }
      our $_attribute;
    
      sub set($self, %s){
        $_attribute = $s{_attribute} || return 0;
        return 1;
      }
    }
    Anyone interested?
    (btw, I'm unsure if the above compiles with the new translation)

    The real perl code would look like this:
    Code:
    my $o = Object->Object;
    die "didn't work" unless $o->set(_attribute => 3.14);
    package Object;
    use Alias qw/attr/;
    sub Object{ 
      my $classname = shift;
      return bless {
        _attribute => 0
      };
    }
    our $_attribute;
    
    sub set{
      my $self = attr shift;
      my %s = @_;
      $_attribute = $s{_attribute} || return 0;
      return 1;
    }
    Anyone interested?
    I think packages make objects/classes seem like shrimp food. I think objects/classes should be treated like royalty, and that's why I replaced
    Code:
    package Object;
    with
    Code:
    class Object{}
    . Plus the 'dot' operator looks much more better than having to use '->' to access objects.

    So., is anyone interested in using this style of perl? If so, I could post the code that translates the class-perl to the real perl.

  2. #2
    UT2004 Addict Kleid-0's Avatar
    Join Date
    Dec 2004
    Posts
    656
    Update: I added the extends operator for creating sub/super-classes/inheritance.

    Here's a sample of the "New Translation" of perl:
    Code:
    class Object{
      sub Object($classname){
        return bless {
          _object_property => 500
        };
      }
      our $_object_property;
    
      sub toString($self){
        return "Object state: >$_object_property<";
      }
    }
    
    class Entity extends Object{
      sub Entity($classname){
        my $self = new Object; 
        $self->{_entity_property} = 300;
        return bless $self;
      }
      our ($_entity_property);
    
      sub toString($self){
        return "Entity state: >$_entity_property<\n",
          $self.SUPER::toString($self);
      }
      sub understand($self){
        $_entity_property .= ' {understood}';
        return $self;
      }
      sub comprehend($self){
        $_entity_property .= ' {comprehended}';
        return $self;
      }
    }
    
    package main;
    my $e = new Entity;
    print $e.understand.comprehend.toString, "\n";
    The output of the program:
    Code:
    Entity state: >300 {understood} {comprehended}<
    Object state: >500<
    and here's the real perl:
    Code:
    use warnings;use strict;package Object;our @ISA=qw//;use Alias qw/attr/;
      sub Object{my $classname=shift;
        return bless {
          _object_property => 500
        };
      }
      our $_object_property;
    
      sub toString{my $self=attr shift;
        return "Object state: >$_object_property<";
      }
    
    
    package Entity;our @ISA=qw/Object/;use Alias qw/attr/;
      sub Entity{my $classname=shift;
        my $self = Object->Object; 
        $self->{_entity_property} = 300;
        return bless $self;
      }
      our ($_entity_property);
    
      sub toString{my $self=attr shift;
        return "Entity state: >$_entity_property<\n",
          $self->SUPER::toString($self);
      }
      sub understand{my $self=attr shift;
        $_entity_property .= ' {understood}';
        return $self;
      }
      sub comprehend{my $self=attr shift;
        $_entity_property .= ' {comprehended}';
        return $self;
      }
    
    
    package main;
    my $e = Entity->Entity;
    print $e->understand->comprehend->toString, "\n";
    I think classes, the 'dot' operator, and the 'extends' operator make this change in perl worth it.

  3. #3
    Registered User
    Join Date
    Oct 2006
    Posts
    2,297
    I'm not a perl user, so I'm not exactly qualified to judge, but just on aesthetic grounds alone, the "class" style is cleaner looking. one concern I have is that the use of the "." operator could be confusing when used for both string concatenation and member access.

    how much testing have you done? have you fed it code from a variety of developers to compare its output with different styles of input? do you have a converter to do the reverse operation - "real perl" to "class" style?

  4. #4
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,176
    O_o

    Perl already has arguments. Did you mean named arguments?

    Perl also has a fairly large "OOP in Perl" community following. I'm not saying that a "PerlWithNativeClasses" to Perl "translator" wouldn't be accepted by some. In fact, I'm sure it would be if you do an excellent job. However, it isn't going to be accepted by any Perl hacked if your "translator" doesn't produce canonical Perl "OOP" code as that community defines such which it doesn't.

    Soma

  5. #5
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Kleid-0 View Post
    I think I've created a better perl language by introducing classes, introducing the 'dot' operator, having better private attributes to objects (through Alias's attr operator), introducing the 'new' keyword to create objects, and having arguments for subroutines:
    I am a big perl user, and I'll admit right off there is very little chance I'd be interested because I'm already mostly happy with perl OOP, but I'll try to comment without just completely poo-pooing the whole idea (just the parts, lol).

    "Introducing classes"

    The concept of class in perl is slightly informal, since it is not a keyword, but nb, it is not alone in this regard, -- javascript also has no "class" keyword. There are, in fact, advantages to this, especially since what a "class" amounts to is a subtype of a package (a perl class is a perl package with certain specific characteristics). I think you have it backwards in believing that a lot of the syntax associated with, eg, C++, necessitated by the fact it is a purely compiled language, would represent an "improvement" if implemented in languages which use some form of runtime interpreter.

    Put another way: if you created a compiler that would turn perl scripts into stand-alone executables, and this required (it probably would, to be optimal) some more restrictions reflected in more C++ like syntax, but this resulted in much higher performance, I can see how that might be worth it. But since you are not doing that, the only purpose I could see to this would be for people who's OOP background is C++, and this syntax would make them more comfortable. Fine and dandy, but that is not an improvement to the language itself, it is just a crutch for people who learned OO somewhere else.

    "introducing the 'dot' operator"

    This serves absolutely no purpose what-so-ever, as there is already the -> operator. Furthermore, it is a little bit dunder-headed in that the . operator in perl is concatenation. So: you are going to override that and sacrifice clarity/introduce pointless confusion for ____? More syntax that is like some other language you are more familiar with? Why use perl at all in that case? Overriding operators for a completely unrelated purpose in any language is a bad practice, I think, even if their original purpose is not applicable in context.

    "better private attributes"

    This is a real issue with perl, although there are ways to do it -- are you aware of inside-out objects (now, there's a good idea)? I presume you are aware of Moose, which seems to have had a very mixed reception. I tried it (or the light version, Mouse) somewhat for a while, but once the excitement about a new OO system wore off, I stopped. Maybe (just teasing ) you could call this YAPOOI-- Yet Another Perl Object Oriented Interface.

    "introducing the 'new' keyword"

    This is a great example of what I meant by the advantages of a formally class-less OO system. You can (it is the conventional norm) use "new" for constructors, but you don't have to. Ie, you can have constructors that aren't called "new". That's a good, not bad, thing. Removing the possibility is not an improvement.

    arguments for subroutines

    I think you mean a parameter list, since perl subs do take arguments (it's called the "argument stack"). A lot of perl programmers have feelings about this, and perl 6 (which is a different beast than perl 5) does have them. I'm someone who totally likes the argument stack idea. I don't know of other languages that work that way, but perhaps they exist. Anyway, if you know how to use it (that's the language!) it's not an issue and it is easy to write communicative code if you want. You can also do things like take manditory args first, such that the call can then just leave off optional ones, and variations on that theme (eg, pop a mandatory anon callback off the top of the stack, shift some scalars/references from the bottom, leave options in the middle). You can transform the argument stack into a hash in one stroke:

    Code:
    sub whatever {
        my %args = ( @_ );
    }
    Very common. I don't see the point of a formal signature in that light, except for compile time call checking, which as I hope I implied earlier, is not so meaningful or useful (in fact, it's restrictive) for languages with runtime interpreters because of all the things that can happen (aka, be done) at run time. So for me: I vote no parameter lists in perl!!! Please!

    "the extends operator for creating sub/super-classes/inheritance"

    It is already a snap to implement inheritance, multiple inheritance, mixins, polymorphism, etc etc. in perl so what's the point of complicating this by introducing (again) a keyword from another language??? Especially considering there is already 'base', 'parent', and '@ISA'.

    Java, C++, python -- all these things already exist. Perl is perl. This is like writing a library for using sigils in java, or whitespace scoping in C++, so that they could look more like perl or python. Why bother? There is not one ring to bind them all.

    Maybe a lot of this boils down to the difference between a language where you can shoot yourself in the foot (C/C++) and one where you can shoot yourself in the hand instead (perl). If you can't shoot some appendage while programming, why bother ?

    That said, TIMTOWTDI, your idea is true to that philosophy, and don't let my opinion stop you. I have a big general purpose perl oriented project in the pipe (single process async http server with a nodejs like interface) and I am really dreading the flack I will doubtless have to face over some reasonable, conventionally predictable criticisms of it. But I labour on none-the-less, and even if I end up being the only one who loves it, at least we can be alone together, lol. Have you pitched this at http://www.perlmonks.org/ ? You should. But put your stiff upper lip on first.
    Last edited by MK27; 04-23-2012 at 11:09 AM.
    gardhr likes this.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. translation api
    By herWter in forum C Programming
    Replies: 4
    Last Post: 12-11-2008, 01:29 PM
  2. translation!!
    By impossible in forum C++ Programming
    Replies: 14
    Last Post: 05-31-2008, 05:17 PM
  3. C to C++ translation help?
    By bill.thompson65 in forum C++ Programming
    Replies: 5
    Last Post: 10-21-2007, 12:56 PM
  4. translation
    By VOX in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 07-05-2005, 06:21 PM
  5. Translation
    By GaPe in forum C Programming
    Replies: 10
    Last Post: 04-04-2002, 08:45 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21