http://qs1969.pair.com?node_id=234117


in reply to "Perl Idioms for Java" Underway at Sourceforge.net

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

Replies are listed 'Best First'.
Re: Re: "Perl Idioms for Java" Underway at Sourceforge.net
by djantzen (Priest) on Feb 10, 2003 at 14:29 UTC

    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]

In Section Perl News