Chacham's Journal: Verbiage: Beginning to learn Java

I'm reading Learning Java, which i recently purchased, and was typing in the examples from the book. As the book is a monster to hold, i ended up upgrading the ebook for $4.95. Dual screens with one for the PDF and the other for the IDE make it oh so much easier to type in. I also have been reading it on the macbook while in the tub. Nothing like cozying up with a language manual, eh? :)

It's hard enough to learn Java itself. I remember it from the 90s when it was slow, clunky, crashed browsers, and promised way too much. But, it's matured, and for better or worse, it's out there. So, i'm now learning it despite my own prejudice, and now an then mentally mumble, "oh, how stupid."

The stupidities seem to have more to do with preference, and by no means is it language specific. For example, calling an offset an index, leading to the 0/1 bugs that foil so many, camelCasing, and repeating context inside the name. I'm likely to do my own thing for my own code, to keep it enjoyable. I'm even tempted to declare all arrays with one extra element and just starting from 1. Though, some array methods start from 0 regardless, so, i may not be able to hold onto that fantasy for very long.

This is also my first language where i'm learning proper inheritance. One rule that i wondered about is, if class B is a subtype of class A, a variable of class A can refer to an instance of class B, but not vice-versa. I thought that was backwards because B is A plus other stuff. The box isn't bug enough! If anything, i thought, it should be exactly the opposite. A variable of type B should be able to point to an instance of type A, because it fits, though there may be some defaults required.

But now, i finally got to an explanation from the book, albeit about casting, "Casts in Java affect only the treatment of references; they never change the form of the actual object. This is an important rule to keep in mind. You never change the object pointed to by a reference by casting it; you change only the compiler's (or runtime system's) notion of it." Aha! The reason a variable of type A can hold an instance of type B is that from a usage standpoint, B has everything A has, so who cares about the rest. Conversely, a variable of type B cannot hold an instance of type A because it does not have everything required. To use MBTI terminology, Java is for Ps, i am a J. (I just wish they keep away from databases, which is clearly J territory.) I almost feel enlightened. And from Java, no less.

Now to continue reading. I've been successful int trying to do one chapter a(n office) day. Currently in chapter 6.