clipka wrote:
> - even though it does appear to be mainstream indeed, it doesn't seem to 
> fit the bill of "Non-OO ... (imperative) language".

It's not OO. There's a library to make it look like it's OO. When you use 
that library, each object is represented as a global procedure. It can kind 
of sort of look OO, but it isn't.

> As for Ada: When I think "mainstream", I don't usually think avionics, 
> weapon systems or spacecraft - or any other embedded or real-time 
> application, for that matter.

OK. When I say "mainstream", I mean a language that's actually used for 
actual development by people other than those at the same company where the 
language was invented. I rule out things like Blue and Sing# and such, the 
experimental languages crafted for a specific program to be written in.

I would say anything where you can go to Amazon and buy a textbook and then 
download the compiler would have to be mainstream. If you have to download 
the whitepaper that describes the language? That's not mainstream.

> As I said, it depends on the runtime. If for instance the runtime would 
> store object references as a combination of a "data address" and a "type 
> identifier", it would be more than problematic to add data fields (due 
> to inability to move the object on the heap),

I think we can safely rule out upgrading running executable code for systems 
that don't have automatic memory management.

> or to "upgrade" only some 
> objects to the new implementation; 

Nah. You'd just patch the type in the pointers that point to the new objects.

> if the runtime instead stores object 
> references as pointers to memory blocks including both the data and a 
> virtual method table, data size may still not grow, but implementation 
> could be changed for individual objects of a type; and a runtime that 
> happens to use chained references for garbage collection would have all 
> the necessary power to actually relocate objects on the heap, thus 
> allowing for arbitrary changes to the data structure. With such a 
> runtime, your "object network" can be arbitrarily complex. Similar 
> flexibility can be achieved by adding a level of indirection between the 
> reference and the actual data.

The problem you might be missing is the existence of return addresses on the 
stack that index into the code you're changing. If your objects sit around a 
long time in various networks, and you can't tell which bits of running code 
are using which objects (as in, have methods of those objects on the stack 
for that thread), then you're going to have a hard time replacing the 
objects without clobbering code that's already running. You're also going to 
have a hard time running the old code in one thread and the new code in 
another thread both using the same shared object.

I guess you could make the upgrades of an entire class at once, but you'd 
have to make sure nobody is executing any methods in that class when you did 
it. (I'm also implicitly assuming for good reason that few people are going 
to want to upgrade a single-threaded process while it's running.)

It's sort of like trying to reorganize a SQL table while there's 
transactions in progress on it. Messy.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message