Re: 6502 illegal opcodes questions

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

Paul Schlyter wrote:
> In article <1149381913.929713.169160@i40g2000cwc.googlegroups.com>,
> mdj <mdj.mdj@gmail.com> wrote:
>
> > Paul Schlyter wrote:
> >
> > How so?
>
> By making it possible to give a subroutine an argument of one type
> while it expected that argument to be of another type.

Unlike C/C++, variable arguments in Java are typed. You can declare the
variable list of be of type Object (in reality, Object[]), but you
still need to cast them back to something useful. Essentially, you
handle Objects of the types that are applicable and anything else you
can either ignore, or throw a runtime error.

It's actually very typesafe.


> > 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.
>
> If you were to write your application from scratch today, that's the
> way to go of course.  But have you ever heard about legacy code?  Code
> reuse?  If not, welcome to the real world!  If an old working piece of
> code can be made to run on a new platform with only some small changes
> here and there, that might be preferable to rewriting it all from
> scratch.  If so, conditional compilation is a better way to maintain
> that code than to create two versions of what's essentially the same
> code.

:-) This is the essence of th point. It is VASTLY superior to create a
small binding to legacy code via a portable mechanism (as Java and
other languages do) than to inherit the no longer scalable features of
legacy languages. Otherwise, you end up with new code with legacy
problems!

In the real world, real code has real legacy issues. These issues cause
problems like portability, security, and developer productivity. You
have a choice: either continue with the legacy approaches, or learn
from the mistakes, wrap the code in a portable interface and move on.

In the real world, keeping your development pace agile as to not be
eaten by newer products that don't have your legacy issues is a real
problem. There are real solutions.

This is the real world effect of Microsofts design decision (pollute
the new language with old problems) versus the Java model. Still
hobbling with legacy for no reason whatsoever than a couple of very
poorly concieved design ideas. And ones that history has already shown
has a simple, clean solution.

"Those who cannot learn from history are doomed to repeat it...."

> >> 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?
>
> Because namespeces belong to the programming language, and macros know
> nothing about the underlying language.  Macros is nothing by text
> substitution.

This is the case in C/C++. Simply because C/C++ doesn't have macro
namespaces is not a particularly solid argument that namespaces in
macros is a bad idea. I mean, really, every C/C++ programmer with more
than a little experience emulates the namespace concept with prefixes?
Why? Because you need it!

> > 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.
>
> Macros by themselves don't generate external symbols though.  The linker
> never sees the macro names.
<snip>
> Note that the macros are "global" only over the source file, not over
> the entire application.

Of course, but includes include includes (lol), which include others,
which then perhaps collide with one you've already defined. The scope
over which a macro symbol exists is potentially the entire application.
It's entirely non-determinable.

Heck, you even have to use a convention to ensure a preprocessor file
is applied only once, or worse recursively.

> > Semantically speaking Java is a lot more like Smalltalk than C++. It's
> > a nice bridge between the dynamic world and the static world.
>
> The other extreme could be represented by Javascript, where all typing
> and binding is done at runtime, and where all objects are polymorphic.

Or better by a language like Ruby which doesn't suffer from the
semi-functional quirkiness of javascript.

> The most important difference here is not what Java allows you to to,
> but what Java prevents you to do.  In Java OO is mandatory while in
> C++ it's an option.  You can even do OO programming in plain C,
> although it means more work for the programmers -- e.g. the "this"
> pointer must always be passed explicitly to methods, constructors and
> destructors must be called explicitly, etc.

Indeed in plain C, you can do 'better' OO that in C++ by implementing a
real dynamic binding system ;-)

The things you're prevented from doing in Java are prevented because
they've proven to be more trouble than they're worth, and there are
other techniques which allow the same things to be implemented without
rehashing error-prone on non-portable paradigms.

They were chosen not because of the whim of some engineer who preferred
things this way, but because research had shown where the common errors
and pitfalls were.

Matt