Talk:Entity

Entity-oriented syntax

While discussing types on the dev list, both saga and I figured out that we'd like to have a psyctext syntax extension that goes like

Attention: [_source->nick] has changed [_target->nick]'s [_context->_topic].

I am not entirely happy with -> but . doesn't look too sexy either so I also considered : or just >, but that's just a detail.

Note: As the dot-sytax is no uglier than any of the others and could possibly expedite parser implementation in some interpreted languages that use dots for their object syntax, lynX has had his arm twisted into finalizing dot-syntax for entities.

Why such a syntax? Well essentially I noticed a lot of variables in the current protocol that merely describe some other entity's copy of the same variable. Yet, it is not necessary to have a syntax like joe->_nick for arbitrary entities - in all circumstances it is enough to refer to any of the entities provided in the MMP routing layer.

Also having the _members of a _context addressable this way and implying a foreach for them in psyctext would model several of _list outputs. Like this:

I'm [_nick] and in my [_context:_nick] you can meet [_members:_nick].

Another example which is particularely rich in semantics as it implements a photographic list of friends for the social network surfing thing which is currently stuck right there at not having photo information at hand.

[_nick]'s friends: [_members->_photo]

Also makes me wonder if profile outputs should be foreach's over all attributes of an entity, using some [_source:].

This has all to do with state. I would like state to be persistent, object-oriented and relayable. Relayable means that if you change to a new client your identity can bring you up to date with the entire multicast state of your friends.

A possible syntax on how to specify entity-oriented variables could indeed be:

=_target:_nick Jack

One could define the default intended entity to be one of _source_relay, _source or _context in that order (see also Routing).

And yes, we probably also need to be able to address relayed entities.

saga sees the entities as a sort of namespace just like the types, so the entities should be types. I didn't really understand how that can work. But he also provided a syntax suggestion for relaying state. Not very beautiful, but it would work within the frame of type extension so that persistent state becomes just an application of types rather than a core feature of PSYC.

=_relayList _uniform psyc:...Seppl { _nick Seppl _color #383838 _photo ... }
            _uniform psyc:...Anton { _nick Anton _color #383838 _photo ... }

See also: Talk:Scenario, Talk:State, Talk:Syntax.

Implementation thoughts

Any object oriented syntax would be appropriately expressive for this application, but performing indirection (in those languages that support it) will be easier if the native object syntax of that language happens to be used in PSYC in an appropriate way. So the first criteria of entity-orientation syntax is what languages want to use indirection. See "Advantages of Lambda Closures"[1].

When using indirection, it's important to provide a root for the name space so that malicious packets can't explore or, worse, modify system variables. Interpret "_source->nick" as "entity->_source->nick" so that Mallory can't read or modify "server->resource".

When indirection is not used, entity-orientation adds another layer of complexity to state management as the parser has to dereference the variable.