Would Tunes be interested in this Object manager...?

[Marcus Petersson]

On Thu, 18 Apr 2002, Ulrich Hobelmann wrote:

> Marcus Petersson wrote:
> > While the current object manager interface may be quite limited and
> > arcane, not anywhere close to your reflective ideals, I hope to improve
> > this with time. But perhaps it has to be limited, because you don't have
> > the warm and cozy environment that a single language offers.
> 
> That's the problem. I wouldn't call it just cozy environment, though,
> since it's more like having one consistent semantics instead of many
> diverging ones.

Of course the object manager would define its own semantics. Any language
considerations will not be allowed to get in the way. But again, perhaps
one has to settle for a semantics that is less expressive than what one
can achieve within a single language.


> I't doable interfacing, say, Scheme to a C library. but if you want to
> do really a shared project, with things written in both languages, this
> gets really ugly, I think.

Yup. But it is not my intentention to make interfaces between languages.
The interfaces go to and from the object manager:

  caller => adapter => Object manager => wrapper => target

> Having a single, nice semantics offers coziness, but also room for
> compiler optimization, and, most of all, safety (type and memory).

The object manager works at run-time (will perhaps do some work at
 load-time too, later). General code optimisation would fore-most be
handled when compiling the classes, in whatever langauge you use for
your class.

Type safety is a bigger problem, especially for parameters. These things
will have to be sorted out eventually. Type-safety for objects will be
handled at run-time (through casting between classes if possible,
otherwise error is raised, same as in dynamically typed language).


> > While objects require memory, they are not just memory. Memory management
> > is done underneath. The actual implementation will change with time, but
> 
> The idea is, that MM doesn't have to be done manually (or through 

It isn't. Releasing objects can be done manually, but it's not required.
When your object terminates, it will release all other objects it holds.

> but transparently by the language, which guarantees you safety. If you
> leave it out, you allow all kinds of sneaky memory leaks and dangling

Then you should use such a langauge to develop your class. Someone else
might be brave enough to use C or asm directly. Eventually, some memory
protection will be added to guarantee classes won't leak memory.

> If you prefer static MM, though, you might take a look at the MLKit or
> the Cyclone C dialect, which use region-based systems (which sometimes

Maybe I will.

Marcus
------------------------------------
 If you find that life spits on you
 calm down and pretend it's raining