list literal gotcha and suggestion

Reinier Zwitserloot reinier at
Thu Oct 8 15:41:28 PDT 2009

That wasn't ad hominem. Ad Hominem means: claiming a logical argument  
is fallacious because the person who made the argument is lacking in  
some regard or other. As logical arguments are independent of the  
person making it, such a claim is obviously itself fallacious, which  
is why its listed amongst the logical fallacies*.

You were thus wildly off the mark, and I take offense to your  
insinuation that I "stooped"  to anything. Furthermore, your remarks  
are in fact toying with the spirit of ad hominem, as they insinuate my  
arguments cannot be trusted simply because I'm making them.

*) Possibly you meant ad hominem in the informal sense, but I don't  
see anything I my previous post that can even be construed as  
insulting your character. Another alternative is that you believe I  
insinuated your arguments regarding the feasibility of the {}-for-all- 
types syntax were somehow not right based purely on the notion that  
the syntax doesn't fit with your usual sentiments. I'm having a hard  
time reading that in my own message, but if that's the case - that's  
not how the comment was intended.

  --Reinier Zwitserloot
Like it? Tip it!

On 2009/08/10, at 22:41, Neal Gafter wrote:

> On Thu, Oct 8, 2009 at 10:42 AM, Reinier Zwitserloot <reinier at 
> > wrote:
> A strange proposal from Neal "we should add closures so we can make
> these changes via API instead of via a language change" Gafter,  
> indeed.
> Well, as long as we're stooping to ad-hominem, I should point out  
> that I wasn't proposing anything.  You said that you don't know how  
> to use a single syntax for all of these collections without either  
> requiring casts or target typing, and concluded that it therefore  
> isn't possible[1].  I showed you how to do it[2], including  
> answering your follow-on questions.  I was doing so not because I  
> think that is how I believe this feature should be designed[3].  Nor  
> because I think this feature is even worth having at all.  I did so  
> because the participants in this list have a wide range of language- 
> design skills, and most probably don't realize how many of your  
> pronouncements are simply incorrect.
> None of this has much to do with the proposal that has already been  
> accepted (by Joe Darcy, not by you or me), the deliberations of its  
> expert group, its implementation, or the probability of it being  
> reviewed and checked-in to the openjdk7 "tl" workspace on schedule,  
> feature-complete, in the next 15 days.  I don't see much risk (or  
> "hope" if you prefer) of that happening.
> Cheers,
> Neal
> October 6: (Reiner) "We went over this - target typing is asking for  
> problems. If you can shed any light on how gets around these  
> problems, perhaps we can reconsider it, but if not, I don't see how  
> this changes the situation any."
> October 6: (Neal) "The same effect can be had without target  
> typing.  Essentially, one defines the {}-literals in terms of a  
> newly introduced type/class, and then define compile-time  
> conversions from that new type to each of the types you want it to  
> convert to.  Java's type inference, for example (including  
> constructor type inference), can be described this way, and that's  
> how it works inside the compiler."
> Sep 30: (Neal) "I agree that a solution along these lines [API- 
> based] is a better approach for these literals."

More information about the coin-dev mailing list