> Well, select() and map() don't have to be specific to> Lists (although they may be in ruby, I'm not sure.) They> both simply rely on iteration. I really think that the> features are semantically equivalent. It's the classic> trade off: language or libraries?I meant that these operations must be defined on each type that you want to use them...

> Well, I'm no ruby expert, but I'd do this:> > x.select{|s| s.strip.length > 0 }.map{|s| s.downcase }> > You just compose the methods you want together in whatever> manner you like, just like in regular old code. No syntax> to learn beyond the block/closure syntax, which is> generally applicable (i.e. it doesn't apply only to> Lists.)> >...

> > While I see your point regarding having a specific> > function for rejecting some part of an list, it doesn't> > answer the question of how do I do abstract operations> on> > list.> > I think it does answer that question. By having methods> that take closures, rather than adding additional language> syntax, it's very easy to answer the...

> If you look at the Ruby version, you> don't even have to know how to program to immediately see> that you have a list of names and are trying to reject the> empty ones. It might as well be plain English.As someone who is not familiar with Ruby, I can tell you that is not correct.

I am writing a program that will periodically announce the death various jobs and technologies. This should result in the 'death' of many blogs.

> > Does this update provide support for heavyweight> > components in JInternalFrames? I'm waiting anxiously> for> > this feature.> > That is in J7(b19), but not in J6_10 as far as I can see.> Bug 4811096.Thanks.

> Of course executing untrusted code is risky, but this is> not an argument against macros. BTW executing logs is not> such a common technique (I never heard of it); a typical> technique is to execute configuration files, but this is> fine since they should be edited by trusted users> (programmers, sysadmins) and you can always restrict the>...

Does this update provide support for heavyweight components in JInternalFrames? I'm waiting anxiously for this feature.

> > AS I understand it, macros can write macros and I don't> > see anything that prevents them from acting like> viruses.> > I see a bit of paranoia here. I do not think this is an> issue.But the more general issue of executing things like logs. Do you not see a risk? My understanding from previous discussions was that there was a known risk...

> > > On a side note, it's also a core concern of> > > computer security specialists.> > > > I do not follow you. Are you referring to the security> > risk> > of evaluating untrusted code? But macros affect the> user> > program, not code of unknown origin.> > He's referring to the fact that the machine's> unwillingness to distinguish between...

> Not clear what you mean. Anyway, if your language does not> support the code==data concept, you have to reinvent it> somehow. For instance, consider GUI builders, where you> write an XML representation of our widgets (remember, XML> is nothing else than a verbose implementation of> s-expressions) and there is a framework which is able to>...

Whenever I've read articles about LISP, there's often a focus on the idea that LISP doesn't make much distinction between code and data. This is generally touted as a really awesome feature but that always leaves me a little puzzled.Back when I was getting my degree my favorite CS professor hammered it into our heads that as far as the machine...

> > > The world is not class-oriented. We do stuff on> things> > > based on what those things provide, not on what those> > > things are called.> > > > What does a wheel provide?> > What kind of wheel?That's kind of the point but lets say, 'steering wheel'.

Howard, I said before that I would like closures. However, I really haven't taken time to understand the various proposals. I spent a lot of time understanding Java generics before they were released and by and large feel it was a waste of my time.So, when I think of a closure, I think of a more concise syntax for certain anonymous inner...

> @James,> > Although you coding is very good the closure has> handicapped you when compared to the inner class.I didn't use a closure. The code I posted compiles under 1.6 but I didn't test it. It should just be a refactoring of the code you posted.