Re: 6502 illegal opcodes questions

["mdj" <mdj.mdj@gmail.com>]

Paul Schlyter wrote:

> > Still, this didn't solve the whole problem, as many standard 1.1
> > Applets wouldn't run on Microsofts VM, which unfortunately shipped
> > standard with Windows, making Java look a lot worse than it actually
> > was.
>
> Which explains why Sun later prohibited Microsoft to implement its own JVM.
> That's when Microsoft switched to C#.

Yes. Things have been a lot better since then.

> That's nice!  But it's also a hole in the fairly strict type checking
> in Java.

How so?

> ...well then the choice is easy: do it the most efficient way... :-)
>
> Of course there's some work in ensureing that they way you chose really
> was the most efficient.

There's yet to be any evidence that it's less efficient, and perhaps
some to indicate it's more so.

Anyway when faced with choice these days I go with the most
maintainable way. CPU power is cheap and plentiful.

> > It's still frowned upon, in favour of using a constant plus
> > if/else/switch constructs to do conditional compilation.
>
> That causes a problem: a source line which shouldn't be used in some
> particular environment can also be a syntax error in such an environment.

Exactly. The point is to avoid these situations by design. There's no
good reason to have machine dependencies within the same class in a OO
language. That's poor design.

> I dondt think one can talk about namespaces at all regarding macros in
> preprocessors.  The preprocessor does not know what a namespace is. It
> hardly knows anything about the underlying source language.  Heck, you
> can even replace reserved words with macros -- try to do THAT using
> the global namespace in a normal way.....

Why? Namespaces are a natural extension present in most modern
languages to avoid collisions that occur frequently in larger programs.
Macro's being redefined by included headers from an unrelated piece of
code is a real problem in C/C++ programs.

Of course, most good programmers utilise some form of poor-mans
namespacing by prefixing their preprocessor names with something that's
likely to be unique. This illustrates the point that the feature would
be useful.

> Is there a .setName() method too?  If there is, one might be able to
> do quite interesting things with it.... :-)

Heh. Some OO languages implement a 'Pose' facility to allow you to do
this. It's possible to get the same effect in Java, but constructors
make it difficult. Don't get me started on constructors ;-)

> > But then, many people want to treat Java as if it's C++ minus features,
> > rather than the very different language that it is.
>
> These peope are wrong of course.  Java resembles C++ only
> superficially, mostly by having similar syntax.  But the semantics
> under that syntax is quite different, and more resembles
> "strait-jacket languages" like Pascal --- of course with a lot of
> features not available in Pascal.  I usually think of Java as "the
> UCSD Pascal of our times": it has portable object code which must be
> run on a virtual machine.  However, it is object oriented, it is net
> aware, and it is 32-bit rather than 16-bit.  And Java is also a
> subsystem, not a whole OS like UCSD Pascal was.

Straightjacket is a little harsh :-) If we're comparing Java to C++,
it's really C++ that's the straightjacket language, by forcing you to
make all binding decisions at compile time.

Semantically speaking Java is a lot more like Smalltalk than C++. It's
a nice bridge between the dynamic world and the static world.

To me it's more like this: C++ is C, but with stricter type checking,
and object oriented like extensions, staying within the realm of a
static language with no runtime system or typing.

Java is C++ like in syntax, but is underneath a 'real' OO language,
allowing dynamic binding, loading, etc, within a C++ like typing
system. It's actually far more flexible than it first appears, but you
have to think like an OO programmer.

The only time the typing system annoys me is when I want to do
something REALLY OO, with some fairly heavy reflection. The lack of
syntactic sugar in the reflection API is at times most tedious, and
results in code being very hard to read where it should be simple and
concise.

To this day, I don't miss the implicit conversion between integer and
boolean type that C/C++ programs use. This is the only area where
Java's type checking is stricter. Other differences are feature
removals as mentioned previously

Matt