highly random

[cellio]

Drivers of school buses should set better examples. A couple days ago I watched a school bus be the third vehicle in a line of traffic that was running a red light. Sheesh. (In case you're wondering, no I was not at the head of that line. I was at the head of the line of traffic that had a green light but couldn't safely move.)

Last night was Temple Sinai's annual meeting. Doing back-to-back meetings for two different congregations led to exercises in comparative anthropology. Tree didn't really give a "state of the congregation" talk; Sinai did but they painted a picture that's a tad more optimistic than the facts really support. (Nothing untoward, mind -- just PR spin.) I wonder which is worse -- no info or sanitized info.

This Shabbat it's my turn to bake for the kiddush. I wimped out; you can get these "instant cookies" that you just break apart and stick on ungreased cookie sheets. I'm not usually that much of a slug.

Much to my annoyance, I learned today that the java compiler isn't as smart as I thought it was. Suppose your class has a method that returns an instance of your class. Suppose you subclass that and want to override this method to return an instance of the subclass. If Base.fn() returns a Base and Derived.fn() returns a Derived, you would think that the compiler would be able to tell, given code such as "Derived d = Derived.fn()", that it should use the overload that returns a Derived and not try to return a Base, right? You'd think so, and I'm told the spec says so (though I haven't checked), but apparently you'd be wrong. Bah.

We watched the season finale for "West Wing" tonight. Some interesting developments, some disappointments. The end of the CJ story was particularly annoying to me. But overall, I'm enjoying this show. We've only been watching it for a couple months. (We encountered it for the first time over Pesach.) I haven't gotten around to the season finale of "Enterprise" yet.

Dani is talking semi-seriously about buying the first season of "West Wing" on DVD. This must mean he's thinknig about getting a DVD player -- which must mean that he's inclined toward that TV upgrade. The (new) TV room is currently under some construction, but that should be done soon. Then we can do furniture.

Our D&D party (in Ralph's game) has some down time between now and the next session. Real Soon Now I need to figure out how my character is spending it. I'm really enjoying being in a D&D campaign again; it had been a long, long time (12 years or so). I like to think that I'm a better player now than I was then, just due to general maturity, though I don't actually know that.

Comments

Java...

[goljerp]

Much to my annoyance, I learned today that the java compiler isn't as smart as I thought it was. Suppose your class has a method that returns an instance of your class. Suppose you subclass that and want to override this method to return an instance of the subclass. If Base.fn() returns a Base and Derived.fn() returns a Derived, you would think that the compiler would be able to tell, given code such as "Derived d = Derived.fn()", that it should use the overload that returns a Derived and not try to return a Base, right? You'd think so, and I'm told the spec says so (though I haven't checked), but apparently you'd be wrong. Bah.

It sounds to me like you're not really overriding it. I mean, to flesh out your example a bit, you've got

public class Base {
  public Base returnMe() {
      return this;
  }
}

The derived class can't do this:

public class Derived extends Base {
  public Derived returnMe() {
      return this;
  }
}

which is, I guess, what you'd like it to do. But that could be rather strange... if another class called returnMe(), it would have to assume that it's getting an instance of Base. (Because, remember, just because it is an instance of Derived, doesn't mean that you know that it is when you're running the methods). If you want to do what you describe, you can always cast the reference... I admit it's a bit gross when you have to do things like

if (widget instanceof Base ) {((Base)widget).whatever();}
else if (widget instanceof Derived) { ((Derived)widget).whatever();}

but that's the breaks...

Re: Java...

[cellio]

But in order to call returnMe() at all, you have to have an instance already. (It's not a static method.) That means that at some point you instantiated this thing -- and that line of code augmented by Java's introspection methods ought to provide all of the knowledge necessary for the compiler to Do The Right Thing for any given call to returnMe(). But, alas, it does not, and Java programmers have to write code like your example.

(I guess technically it's not an override but an overload.)

But that could be rather strange... if another class called returnMe(), it would have to assume that it's getting an instance of Base.

True. And if the method you implement in this way is doing something like serialization/deserialization, you've got a problem on your hands. But if it's something more benign, where (in this example) Derived cares that it's the subclass and to everyone else it can just be a Base, this approach wouldn't seem to be fundamentally broken.

On the other hand, it's probably just as well that they don't pay me to program. Sometimes my view of the world is too simple-minded, with too much theory and too little down-in-the-trenches experience to inform practice.

Re: Java...

[goljerp]

technically it's not an override but an overload

Yes, that's it exactly. Java doesn't let you override in general (the + operator is an exception). That's something you can argue about as far as whether or not it's a good or bad idea, but it's built into the language.

On the other hand, it's probably just as well that they don't pay me to program. Sometimes my view of the world is too simple-minded, with too much theory and too little down-in-the-trenches experience to inform practice.

Well, there are definitely cases where Java can't (or won't) do something and I find it very annoying. This usually isn't one of them, but maybe it's because I've been forced into this situation too often to get upset about it. But there are things that still bug me - e.g. that the instanceof operator isn't "instanceOf". And I want more options between private and public than just default and package. (Like it'd be nice if there were an option to have something accessable *only* to classes which extend a base class, whether or not they're in the same package.)

At the end of the day, I still like Java better than Fortran77 (which is what I was programming in before.)

Re: Java...

[ralphmelton.livejournal.com]

I have no idea what Java actually permits, but I know that from a programming-language-theory perspective, an example like that (where Base.returnMe() returns a Base, and Derived.returnMe() returns a Derived) can work out properly. This is called "covariant subtyping".

Newer versions of the C++ standard allow that, though compiler support is not widespread enough for us to use that.

However, you cannot do this in argument lists, because of a hassle known as "contravariant subtyping". Doing that part "right" tends to be a) hard to understand, b) hard to implement, and c) not what you actually want. So languages tend to skip that part.

(Because of those issues, Java arrays are actually "wrong" from a PL point of view.)

Re: Java...

[cellio]

Thank you! I especially appreciate knowing that there is actually a name for this issue, so I can theoretically go learn more about it.

Re: Java...

[ralphmelton.livejournal.com]

I can talk more about this and loan you slides from a presentation on the topic, if you like.