Home arrow static arrow Java Programming [Archive] - Boolean hashCode
Warning: Creating default object from empty value in /www/htdocs/w008deb8/wiki/components/com_staticxt/staticxt.php on line 51
Java Programming [Archive] - Boolean hashCode
This topic has 30 replies on 3 pages.    « Previous | 1 | 2 | 3 |

Registered: 04/03/99
Re: Boolean hashCode  
Aug 2, 2004 2:03 PM (reply 30 of 30)

jsr-84 passes a map to the service provider for implementation specific properties.

I can't pretend to be familiar with the JSR in question, so I'll have to take it on spec. Sure, it sounds like that may be a case where you'll have to use a map of objects. It doesn't sound like an attractive interface to me, however, and I'm suspicious that there may well be a more natural way to provide the facility.

In most cases I've seen maps being passed
across APIs, they are used in this manner.

Well, that's entirely untrue for me. In most cases where I've seen maps being passed across the API they are mapping strings to objects of one known type.

And we're not just talking about Map, we're talking about the all Collection classes, and indeed the rest of the standard library. Here's an example in the JAAS Subject class,
public Set getPrincipals()

Which would be preferable as
public Set<Principal> getPrincipals()

I've seen my share of real world abuses of that particular method. People have a tendancy to assume that it returns strings for some unholy reason. God knows why, but they do and it's very clearly documented.

Sure, that's a better API if that's what you want to do. So ?

I'm in the habit of writing software that does what I want it to do. Give an
example of something you want to do.

I want the user to obtain a list, not have to convert it into a Foo (hidden list) and pass it to my API. Specifically, I want to standardize my API to play nicely with other libraries, because the less glue code my users have to write, the fewer bugs there will be.

While I'm talking about users, incidentally...

I've never had a user ask for something to
operate on a list of strings,

My users are twofold - my colleagues, who expect me to write standard parts of an application and use it in a reasonable intuitive way, and our clients who use that software. Sure, I've never had a customer ask for a list of Client objects, but yes, I've had plenty of colleagues expect me to make the equivalent of a List<Client> available to them. Saying "no, you need to use a Foo (hidden list)" would stink to high heaven of Not Invented Here syndrome.

Here's a fairly typical example of where I would like to be using them. Here's a typical method after generification:
public Collection<User> getUsers();

Here's a call to that code.
if( users.contains(client) ) {   //...}

Now, why should my colleagues have to hassle me to write a contains method on my client method, and indeed since the thing I'm returning palpably IS a collection, why should I not use inheritance to express that ? Not doing so is just plain contrary to OO techniques. Sure, if the thing I was returning wasn't a collection I'd use something else, but it IS one.

<snip macros>

I dislike macros. That may well be more prejudice than reasoned argument, but I have a huge distaste for mixing my languages, even more so when one or more of the languages is not a widespread standard.

If you like macros then you have a completely different philosophy of design to me - and I'm unsurprised that we're disagreeing on a relatively trivial point like generics.

Begin rant.

I suspect that we work in very different environments. Most of my code gets a lot of other peoples grubby fingers on it, and I have to work with a lot of legacy code that has very variable quality. In short, I have to live with my mistakes, and I have to live with other peoples mistakes. Generics for me does indeed offer an additional level of expressiveness at the API level. It does allow me to say "this is a list of User objects" and force the person calling into that code to take account of that.

Unit tests with macros, on the other hand, offer me an additional set of tasks that won't get the attention they deserve (every company claims to use unit testing, very few do it wholeheartedly) and another tool to watch break.

End rant.

This topic has 30 replies on 3 pages.    « Previous | 1 | 2 | 3 |