On 16/02/2008, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
> On Sat, 16 Feb 2008 18:09:27 +0100, Igor Stasenko wrote:
>
> > On 16/02/2008, Klaus D. Witzel wrote:
> >> On Sat, 16 Feb 2008 13:56:54 +0100, Igor Stasenko wrote:
> ...
> >> > index and handle is the result of previous calls to primitives which
> >> > should return a HydraInterpreter instance from now.
> >>
> >> Still unclear: your user (a developer) has an index, say an element from
> >> (1 to: n), for which you want to return her/him a HydraInterpreter
> >> instance from now on?
> >>
> >
> > Right.
>
> </phew> and no further comment on index dilemma :)
>

Forgot to notice, that this would require registering HydraInterpreter
in special objects array, to be able primitives to deal with it.
If this is acceptable, then i will do the changes in VM and
primitives. If not, then i'll keep primitives untouched, but refactor
classes to use HydraInterpreter instances instead of handles.
Can't make a decision, if making HydraInterpreter a special object
worth doing or not. Meanwhile i'll start implementing a HydraStream.

> ...
> >> > ..erm.. do you mean by HydraInterpreter  as an interpreter at VM side,
> >> > or as an object?
> ...
> >> BTW: isn't the HydraInterpreter name misleading (and causing confusion
> >> in
> >> the above). How about using another name, without "interpreter" in it,
> >> because your "as an interpreter at VM side" is something else.
> >>
> > Hmm, i don't know.
> > We have HydraVM , which runs multiple interpreters and
> > HydraInterpreter "represents" one of them.
> > If you having better naming suggestions, just say it.
>
> It doesn't interpret anything (it is as dead as a handle is dead), so I'd
> say HydraImageReference (like MethodReference etc).
>

Image is quite dead too - it's just a bunch of bytes sitting in memory.
See, when you do:

Smalltalk garbageCollect
Smalltalk version

it seems more logical than:

SmalltalkImage garbageCollect
SmalltalkImage version

so, i'd say that if you wanna do something with image/memory you
should ask interpreter to do it for you, not image.

In that way:
interpreter doit: 'Foo bar'
seem more logical than
image doit: 'Foo bar'

also consider that under the hood, it's actually an interpreter
instance, which in own turn refers to it's image and make it running,
but in addition it having own state and behavior not quite relevant to
image (object memory).


> /Klaus
>
> P.S. any time frame for the next step(s) ?
>

-- 
Best regards,
Igor Stasenko AKA sig.