RE: Tomcat or PHP in ST ?

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Colin Putney
> Sent: Monday, May 14, 2007 6:59 AM
> To: [email protected]
> Subject: Re: Tomcat or PHP in ST ?
>
>
>
>
> On May 13, 2007, at 5:41 PM, prunedtree wrote:
>
> > The issue is mainly that it uses dialect-specific code
> > (thisContext...), not the semantics it uses.
>
> Well, that's a bit misleading. thisContext was part of Smalltalk-80,
> and is described in the Blue Book. It's only dialect-specific in that
> some dialects don't conform to the Blue Book.
>
> > There are going to be some limits to continuation support in
> > strongtalk simply because strongtalk supports callbacks, and thus you
> > can get volatile frames on the stack. Expecting that you can blindly
> > serialize anything in a system that interacts with the external world
> > doesn't sound like a good idea.
>
> Blindly? Seaside's implementation of continuations is suited the
> platform it runs on. On Squeak, activation contexts are uniform, and
> the implementation is simple. If Strongtalk supported thisContext,
> I'd expect the implementation would be more complicated, in order to
> deal with calls in and out of foreign code.  That's fine. If only
> stacks with purely Smalltalk contexts can be serialized, that's fine,
> too. Gemstone implemented continuations with VM support as part of
> their Seaside port. It seems to work fine.
>
> Continuations aren't that scary, and Seaside/Strongtalk would be an
> awfully nice combination.

As a matter of design, Strongtalk attempts to separate the language from the
'system/environment' and reflective code, so syntax like thisContext is not
supported, and all reflection on contexts and activations is done through
'mirrors' (an idea borrowed from Self).  So at the syntactic level this is
one of the areas where Strongtalk is not Blue-book compatible, although
there are mirror classes for reflecting on contexts and activations.

So basically, you can think of Strongtalk as being Blue-Book compatible for
non-reflective code, except where the library interfaces have been cleaned
up to improve subtyping semantics (e.g. such as use of include: for
collections instead of add:).

For reflective code Strongtalk is almost completely *incompatible* with
Blue-Book, except for a few of the most common things like
Object>>isKindOf:, although most of the same reflective facilities are
offered in other ways.  We simply didn't believe that reflective code
belongs in the normal object interfaces.

It's not clear yet what facilities the Strongtalk VM is missing that would
be needed for manipulating activations.  They can be examined, but no one
has looked into what is there for creating/modifying activations from
Smalltalk.  It may be all there, but I suspect that the mutation side of the
reflective interface is where the difficulties would lie.  I just don't have
time to go look at this; anyone who wants to can go ahead.

-Dave


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---