Oh boy... you are laboring under a few ideas that a little more scope might
help clear up.
"Managed Code" by definition is not what you think it is; Managed code is
simply code that is managed by an execution environment, and that can be >a
.NET language environment, a JIT compiler, an intrepted language, or --
OS/400, i5OS, etc.
too vague and broad a definition. managed code for the programmer
means there is nothing that can be done to one object that can bleed
over or otherwise affect another object.
I applaud your enthusiasm, but I thijnk you may be experiencing a little
"tunnel vision", and accepting too much Microsoft marketing fluff. THe
defintion for "Managed Code" is absolutely a broad defintion. Microsoft is
putting a marketing twist on it, and has a nice implementation, but the
defintions they are giving out are Marketing driven, and delivered with an
almost religious fervor.
[snip]
StringBuilder sb1 = new StringBuilder( ) ;
StringBuilder sb2 = new StringBuilder( ) ;
sb1.Append( "abc" ) ;
sb2.Append( "efg" ) ;
there is nothing that is done to the sb1 StringBuilder object which
will alter the sb2 object. this is true for java code also. You cant
make this claim for an ILE language.
Again, these are language issues - they have nothing to do with the code being
"managed" or "unmanaged" - the same issues apply to code compiled for a native
processor or for a .NET virtual machine. A case in point, Burroughs 5500
machines had the capabilty to support this in hardware, back in the late
1960's. The code was "managed" by the processor to prevent unwanted errors from
creeping in.
Pascal was run on p-Code machines that also provided a well managed code
environment.
Now, an managed environment can do things like type checking - if it
undestands what the COMPILER did.
Type checking, array bounds and other limit checking are all available in
many >languages, and in fact, do not depend upon the underlying execution
environment, >at least not as much as you might think.
not true. You can pass a 10 element array to a *varsize parm of an
ILE procedure and lose all type check protection. You can also lose
your type checked protection by basing an array on a pointer and then
setting that pointer to different arrays in your program.
I said it could, not that it did. What it does do is protect you from a whole
lot of other things that you never ever know about in RPG. Look up the ILE
design specs and goals. ILE is quite a bit more than a different variant of
RPG, and in fact, is very much a cross platform thing. The code is "managed" on
the iSeries. It just does not do it is such as way as to require you to buy
Microsoft software.
Let me also point out that Microsoft, understandably, is the largest proponent
in the world of moving software off other company's "porprietary" platform and
to the Microsoft proprietary "open" platform. Of course they are, but that does
not make their platform "open" or "managed" in comparison to other platforms.
What does that is the Marketing Spin. IBM, unfortunately, just isn't great at
Marketing. Double so in the iSeries world. Maybe that is about to change.
[ more snipping ]
midrange.com
