in reply to Re: "Perl Idioms for Java" Underway at
in thread "Perl Idioms for Java" Underway at

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
  • Comment on Re: Re: "Perl Idioms for Java" Underway at

Replies are listed 'Best First'.
Re: Re: Re: "Perl Idioms for Java" Underway at
by simon.proctor (Vicar) on Feb 10, 2003 at 14:48 UTC
    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:
    So your looping methods will look more perl-ish still (hurrah!).