On Friday, September 29, 2000 4:48 PM, Perl6 RFC Librarian [SMTP:[EMAIL PROTECTED]] wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Merge Perl and C#, but have default Main class for scripting. > > =head1 VERSION > > Maintainer: Timothy Covell <[EMAIL PROTECTED]> > Date: 29 Sep 2000 > Mailing List: [EMAIL PROTECTED] > Number: 352 > Version: 1 > Status: Developing > > =head1 ABSTRACT > > 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. > > > =head1 DESCRIPTION > > 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. > > > =head1 IMPLEMENTATION > > 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. > > =head1 REFERENCES > > 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 Pardon me while I "throw" up. Wanna "catch"? You force perl into a 100% OOP mode, you ruin half of what makes it win over other programming languages: - VERY short development time - small program code - one liners - command lines that take OOP whole programs and instead you get: - the need for private/protected paranoia - the need to remember whether exit() is in sys.pm or lang.pm - code cluttered with unnecessary grammar - code cluttered with unnecessary code - chained to someone elses WTDI by more strict grammar Perl OOP needs some cleanup, not going hog wild. You want C++, use C++. Perl's OOP currently isn't "formal", it just happens to be able to do OOP mostly by accident. "An object is a thingy that just happens to know that it's a thingy." There was mostly enough in the language to allow the language to accomplish OOP without all of the grammatical foolishness of other OOP languages, even as far as polymorphism and multiple inheritance, which is more OOP than most OOPs. If you force it into a mold, you ruin the flexibility that "accidentally" gave us OOP in the first place. Maybe some syntactic sugar is needed, I'll grant that. The rest is hogwash. OOP is not the final technology in programming. In chronological terms, it's basically just a fad, waiting for the next fad to come along to take its place. In fact, OOP is already starting to fragment into two segments (C++ style with multiple, and Java style with interfaces). (Foolhardy prediction: the next fad will spring from xml.) In other words, if you tighten the noose around perl to force it to do what it already did by accident because of the flexibility of the language, you could ruin its future flexibility for the next generation of change.
