Some time back, samurai asked if there were any options for incorporating a dash of Perlishness into Java, and at that time the answer was "no". Well with the passage of time that answer has changed, and I am pleased to announce the Perl Idioms for Java project over at Sourceforge.

So far we have implemented foreach, grep, join, map, pop, push, shift, split and unshift, a (very) rudimentary form of autovivication, and a class representing Perl's notion of truth. If only I could convey my glee at the realization that a java.lang.Boolean initialized to "false" is true according to Perl's semantics :^P

We haven't released any files officially, however the source code is available for your perusal under CVS here, and comments on implementation or theoretical points are most welcome. Enjoy!

"The dead do not recognize context" -- Kai, Lexx

Replies are listed 'Best First'.
Re: "Perl Idioms for Java" Underway at Sourceforge.net
by simon.proctor (Vicar) on Feb 10, 2003 at 13:54 UTC
    A great Perlism to try and implement is its syntactic sugar and any effort along those lines (for me at least) is a welcome effort.

    However, after looking at your code I wonder how useful some of your idioms (specifically your implementation of foreach) are compared to that of generics which is slated for 1.5?

    Given that not many people would upgrade to 1.5 right away I think I've kind of answered my own question :).

    I was also wondering about your class structure. The *accepted* method would be some form of delegate object but one that conforms to an interface. That said, the STRATEGY pattern here would surely have helped tremendously? You could still use your base Block() class but then subclassed it for each Perl idiom.

    A final point/question, are you expecting the user of your API to undertake all the Thread handling? There are areas where I can see you're going to have problems unless you make this absolutely clear.

    I do have more points but they are more related to Java than Perl which I think is a little *too* OT :).

    Please don't get me wrong - this is interesing work :).

    Update: made a boo boo - thought you weren't using anonymous classes when I think you are. Still nm :)

    The stuff about anonymous classes.
[reply]

      I haven't looked at the upcoming generics framework, so I have no idea about it's usefulness here. That said, I'll be the first to admit that several of the methods are of dubious value, particularly pop, push, et al which are essentially just wrappers around equivalent Java methods. The Collections framework is really very good once you get past its sheer verbosity.

      The idea behind the Block is that you create an anonymous inner subclass that contains the code you want to execute. To be honest I'm not completely sure what it would look like with a delegate class in there, but my goals were: 1) to mimic the Perl functions not just in behavior but in user interface, and this was the only way I could think to duplicate a bare block; 2) keep the interface simple otherwise the point would be lost, hence a single Block class; 3) give the feel of a builtin function.

      With respect to threading, I take it you're referring to the use of static instances of Context? I will probably end up synchonizing the relevant methods to deal with that, which isn't a perfect solution but I really don't want to require the programmer to create an instance of the class just to encapsulate that one thing.

      "The dead do not recognize context" -- Kai, Lexx
[reply]
        With regard to the threading comment, you also test if a variable (list) is null and if it is - create a new ArrayList.

        You should synchronise on the list which may mean not accepting null list variables.

        As to anonymous classes, its 6 of one and half a dozen of another. They do provide the means of creating nice customisable blocks of code - I think its too easy, sometimes, to get caught up making everything defined types and using patterns (etc) but they are there. Additionally, I was thinking about your switch statement and how you are using integer vars to decide what to do. I was kind of hinting that it may be possible to keep your annonymous front end syntax and make the backend a little more complex and eliminate the switch statement as well as allow you to add more perlisms at a later stage. Note, I don't say it *is* possible, only that it *may be* possible :).

        Finally, your code would look even better on 1.5 as static imports will allow (if there are no namespace collisions) for you to ignore the class name ie: 
        Math.abs()

        [download]
        becomes 
        abs()

        [download]
        So your looping methods will look more perl-ish still (hurrah!).
[reply]
[d/l]
[select]
Re: "Perl Idioms for Java" Underway at Sourceforge.net
by diotalevi (Canon) on Feb 10, 2003 at 15:36 UTC

    Interesting. I'm doing something similar for LotusScript (a Visual Basic clone) in my day job. I've gotten as far as getting hashes, basic autovivification, join, split, push, pop. It's all the most basic of functions but otherwise a pain in this language.

    Added I should add that I'd provide a link if I were able to. Send me an e-mail if you want to see the code.

    Seeking Green geeks in Minnesota

[reply]

Back to Perl News