On 9/4/04 7:31 PM, Simon Cozens wrote: > [EMAIL PROTECTED] (John Siracusa) writes: >> Anyway, what it'll give me is "official" support for this type of thing. > > Call me a crazy man, but I *like* the lack of official support. > > I actually count it as a Good Thing that perl can be made to do cool stuff > without Larry having to explicitly declare that it's OK.
On 9/4/04 7:32 PM, Luke Palmer wrote: > Basically what you're saying is that "official" support for this will be > better than PAR in some way, since it's official. [...] > > In this case, I don't see any reason for this to be "core". It has no > effect on the way the rest of the language will go, it introduces no > idioms, it has nothing to do with the language at all. If you can > adjust @INC like you can in Perl 5, you can do everything you need to do > to support this in a module. This gets back to my lone Perl 6 RFC. (Remember those? Ah, we were so young and foolish then...) To paraphrase: Yeah, it was cool that Perl 5 could be used to do OO programming in a nearly limitless variety of ways (see Damian's book), but it was most definitely not an ideal situation. In Perl 6, Larry made some decisions about how OO was going to work. You can still go your own way (even more so, in fact) but Perl 6 will definitely benefit from having an "official" way to do objects and classes. And when there's an official way, you'll certainly see less wheel reinvention than in Perl 5. This is a good thing. The "use" and "require" directives are another example. They're standard, and useful enough that there is very little call for for weird alternatives. A lesser language would simply provide "require" (or even just #include :) and leave more complex semantics to "the community." Then you'd end up with 50 different "use"-like thingies, and reading anyone's code would have to start with deciphering how their "used" or "with" or "import" directives work. And those would all have to be bootstrapped with the anemic built-in features anyway, making everything uglier. Getting back to Perl 5 OO, it's in the same boat. Before reading anyone's OO Perl 5 code, you're almost certainly in for a trek into whatever pet OO "helper" system he's using: "use base"? "use fields"? Class::MethodMaker? Params::Validate? Class::Contract? All of the above? None of the above? The standardized "class", "method", "submethod", and so on in Perl 6 will be an absolute breath of fresh air. To bring it home, I think packaging and distribution is important enough to warrant a standard, core-supported implementation. Yes, it's great to be able to roll your own solution, but forcing the issue by providing nothing but the most basic features required to bootstrap a custom solution leads to too much variety and confusion. For some features, familiarity and standardization are more important. Furthermore, every "non-core" implementation will necessarily be uglier than the built-in system. Only through a built-in can you simply run "perl MyApp.pmx" (where "MyApp.pmx" is a directory) and have things Just Work(tm). No non-core, community solution is going to be able to pull that off. Again, it's like use() and require(), or OO in Perl 6 -- provide a good, common, standardized set of features and the community won't waste its time re-implementing it over and over and over. But fail to provide it and you end up with a bazillion different Ways to Do It. Sometimes that's good--survival of the fittest and all that--but sometimes it's not an overall win. Pulling the Larry quote from the RFC: "Although the Perl Slogan is There's More Than One Way to Do It, I hesitate to make 10 ways to do something." I think the "specially structured dir of files" and its single-file packaged (and precompiled) variants are important enough to be standardized, or "core", or whatever you want to call it. I also think that the official implementation will have significant advantages in terms of simplicity, since no one else can change what's in the perl executable itself. (Well, they can, but forking perl itself is a bad thing, right? Yet another example of when having a standard is more important that community diversity and TMTOWTDI :) Finally, platform independent execution of any packaged or precompiled single file will *require* cooperation (core support) from the perl executable itself. PAR is neat, but it doesn't even match up that well with JAR, which allows the same file to work everywhere Java works. I just don't see a way to achieve this level of transparency and elegance without core support. -John
