On Fri, 15 Feb 2008 23:57:58 +0100, Igor Stasenko wrote:

> On 15/02/2008, Klaus D. Witzel wrote:
>> On Fri, 15 Feb 2008 16:56:45 +0100, Igor Stasenko wrote:
>>
>>
>>  > On 15/02/2008, Klaus D. Witzel wrote:
>>  >> On Fri, 15 Feb 2008 13:56:37 +0100, Igor Stasenko wrote:
>>  >>
>>  >>  ...[snipped a lotta rock'n roll]...
>>  >>
>>  >> > For this reasons, i'd like to operate with interpreters using  
>> handles
>>  >>  > instead of indexes.
...
>>  > you can use them in doits,
>>
>>
>> But I did ! (sms := HydraSMS doitAt: 2)
>>
>
> Primitives accept only handles. So you should use
> #pritimiveInterpreterInstanceAt
> or HydraVM interpreters at: to obtain a handle.

I don't care; I'll be using the same as your #doit:at: is using, whatever  
object that is :)

>>
>>  > i'm just wanted to say, that in objects it
>>  > better to keep handles, not indexes.
>>
>>
>> I cannot see any reason for this. The collection is created and  
>> populated by+after startup.
>>
> HydraVM>>#interpreters returning a freshly populated collection each
> time you calling it.

No objection.

> Actually this method was for convenience to iterate through all
> interpreter instances.

No, not for convenience. Do you think that Hydra is usable for  
*whatsoever* without the developer being able to enumerate all existing  
interpreter instances?

Form your discussion with Keith you have instances of HydraInterpreter.  
Now look at this

  | notWantedByIgor |
  notWantedByIgor := HydraInterpreter allInstances.
  notWantedByIgor at: 2

>
>>  BTW: can you run a snapshot of a Hydra-infected .image (which may  
>> contain
>>  your handles) with a non-Hydra interpreter .exe?
>>
> Yes, i can. A handles not anything special but just integers at language  
> side.
> In same way, as SocketHandle is just bytearray in ST, but pointer to
> structure for VM.

Good to know, can save lots of headache at debug time :)

>
> Okay, a little more reasoning, and i will change primitives to use
> indexes instead of handles.

Not necessary, not for me. It is perhaps possible that you interpret too  
much into my #doitAt:, I thought I'd index your collection as is done by  
your #doit:at:, in the way you provide it now (unless you no longer  
support your own code for #doit:at: ;-)

> The only reason why its better is only for speed reasons: all
> primitives should check if handle is valid, so it you have 100 images,

You cannot do anything with Hydra when you *not* check that your handle is  
valid (anything other than potentially crash the system or so).

> it can take to iterate through list of 100 intems to verify that
> handle is valid.

There's always some price to pay, when you want to maintain control over  
your asynchronous computations. Another possibility would be to base  
absence(dead), presence(alive), other state(busy,idle) of your interpreter  
instances on events. Have you considered using events for that, would that  
be easy to implement in Hydra?

> But for security reasons, i'm still thinking that handles are better.

Can you implement your #doit:at: using only your "better" handles, without  
enumerating the interpreter instances?

>