[% setvar title Merge Perl and C#, but have default Main class for scripting. %]
To see what is currently happening visit http://www.perl6.org/
Merge Perl and C#, but have default Main class for scripting.
Maintainer: Timothy Covell <email@example.com> Date: 29 Sep 2000 Mailing List: firstname.lastname@example.org Number: 352 Version: 1 Status: Developing
Several Perl6 RFCs have stated that "everything should become an object". I agree with this idea. I would go further and state that perl should become an OO language at its core but still retain a procedural front-end.
First, let me state that I am not a language architect. However,
First, let me state that I am not a language architect. However, I am a fan of Perl and like what I see of the core C# _language_. What I propose is to move Perl in the C# direction. The KEY difference is that Perl would have an defacto Main class whose defacto main method which would be indestinquishable from a legacy procedural based script. Of course, one is free to override the builtin Main class with his own Main class and his own main method, and thus work in a pure OO mode.
To those would would direct me to use Python or Ruby instead, I would counter with a couple of points. First, Perl's syntax is more in line with C, C++, ObjC, Java, and C#. Second, Perl's syntax is more powerful (safer too) than that of indentation based languages. Third, since C# and Java can be implemented as a subset of C++, I imagine that Perl6 could also be implemented thus. Fourth, due to the aforementioned similarities, defining an intermediate language (a.k.a. bytecode) would be simpler. Fifth, I like Perl, but wish it could do versioning and objects better. Lastly, I don't want to have to get locked into the Microsoft or Sun "Cathedral" platforms.
Finally, to those who think that object orientation is crazy, I would suggest that you look at Perl5 and PostgreSQL. Perl5 as we all know has OO extentions. And, as I am sure that most of us know already, PostgreSQL is an open source RDBMS that is more properly called an "object-relational" database. At it's heart each entry is an object and has an object id. Yet, it retains the traditional RDBMS/SQL interface.
As previously stated, I am not a systems programmer nor a language architect; I am a systems administrator. Thus, I cannot offer an implementation. However, I think that this idea holds water.
RFC 73: All Perl core functions should return objects
RFC 159: True Polymorphic Objects
RFC 161: Everything in Perl becomes an object.
RFC 171: my Dog $spot should call a constructor implicitly