Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • new has become a keyword.

    I can't see why that'd be necessary. For Perl 5 object semantics (overloading, AUTOLOAD, UNIVERSAL, dispatch) you need a thunking layer between Perl objects and Java objects already. If you want interoperability between them, you need the same thunking layer.

    In my mind, the right approach is to translate all bless REFERENCE syntax into metaobject calls, not to add new syntax. The Perl 5 data and object models are flexible enough that you can implement them in terms of Java mor

    • I agree it's not necessary to make new a keyword, and I don't think it's desirable. I wasn't thinking about making JVM objects available at the Perl level, but if you wanted to do that, I'd propose a new keyword instead: javanew, or something like that. Then Perl can be Perl, and if you want to get to JVM objects you can.

      Come to think of it, even better than a keyword might be a module. It'd have to be a very special module, though, something akin to DynaLoader.

      Anyway, great project! It's been done (and failed) before; I'd like to see it succeed.

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • But what do you do if you want to instantiate a Ruby object? Create a rubynew constructor? New constructors for every language out there? It gets unwieldy after a while.

        • Add to that the fact that adding keywords specific to an implementation diverges from the reference implementation. Library fragmentation is bad enough; as Microsoft and Sun about that sometime (though the latter has been happy to inflict it upon other languages).

          • You'd have to talk to the people putting it together. At some point, there's probably going to be some divergence. Perhaps they can also get rid of legacy stuff that's holding Perl back?

            • Perhaps they can also get rid of legacy stuff that's holding Perl back?

              I have no hope of that experiment succeeding until p5p consensus finally acknowledges that its long dalliance with DarkPAN-paralyzed stagnation has failed, miserably. (Perl 5 doesn't have classes in 2009?)

              Of course, a successful Perl 5 on the JVM (or even Parrot) might demonstrate that the sky hasn't fallen, and both people who care about running code last modified in 1995 on a release from 2009 can well and truly port it themselves (

        • In that case, I like the idea of having to go through a module, better. When you want a Java object, you have to explicitly go through a Perl module that provides that access. When you want a Ruby object, similar story, different module.

          I had no idea you were trying to provide access to objects in so many different languages...

          --
          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers