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.

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.

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?

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

Quote:

---

Originally Posted by Kleid-0

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.