[Q] DependentsArray has weakreferences

Diego Gomez Deck DiegoGomezDeck at ConsultAr.com
Sun Mar 10 20:38:43 UTC 2002


>Hi Diego...
>I would like to weigh in with a few comments on this topic.  Well done
>on putting rSt together.  I would like to help if there is anything you
>need.  Dialect independent serialization, async messaging, reference
>management.   more follows...

ok... that's great... just choose the topic and tell me so we don't work in 
the same part...

async messaging: I don't like this feature... the mail goal in rST is 
transparency and async-messaging do not match with Smalltalk message sends 
(at least not match easily) .

> > The framework knows nothing how the objects are used... only pass 
> remote-references to object that pass by-reference and copies for the 
> other objects.  The remote-references objects (proxies) send every 
> message that receives to the other side, more or less thats all (there 
> are a gc work, but it's not relevant for this discussion)... When you 
> receive a remote-refence (proxy) object you don't realize it, after all 
> you only want to send messages.
> >
>Perhaps this is where we can effect a solution.  Certain message sends
>are by their nature passing a weak reference.  These are the
>#addDependent: and #when:send:to:, and their corresponding removal
>If you introduce a WeakRemoteObserver object, then those messages sent
>to a RemoteObjectProxy should know which message sends are really
>pass-by-weak-reference and use the appropriate Transporter.
>#(#addDependent: #when:send:to:)

The decision to user weak-references is in the method, not in the message 
send... suppose that the other side is vast (I plan to port rST to 
different Smalltalks), vast user strong-references to dependents....

In my opinion, you can't assume the implementation....

This "problem" (in my opinion) reflects an invalid (or not ever valid) 
assumption on dependents mechanism and not a problem in the way that rST 
works... of course, if Squeak will work in this way forever I must to 
work-around this.... meanwhile I prefer to discuss if Squeak need an 
strong-dependencies mechanism.

>I have recently been through a few cycles on my attempts at remote
>objects and the most important thing I realized is that remote proxies
>are not transparent from all aspects.  Typically it is more useful to
>view these references as potentially broken (network/broker failures)
>and that the context of use (the send) of a reference will dictate the
>transformation that an argument will undergo.  (weak-reference,
>strong-reference, copy).

Ever that you call an object the object can produce an error.... when all 
the objects are local you have the same problem.... if you need that the 
model continues if a view fail, you can do the same locally....

As you see, I'd like that rST become invisible.

>Finally, messaging should be asynchronous,
>which completely changes the ways we would interact with a remote

Read on top of this email....

>I hope this helps provide a different view of the issues.

yes... of course.... thanks....


Diego Gomez Deck

More information about the Squeak-dev mailing list