In article <[log in to unmask]> [log in to unmask] (Gian Pietro Picco) writes:
 
Gian,
Here's some answers to your last posting:
 
   a) Luis guessed right. My original question wasn't about the general
   concepts of class & instance, which are the traditional ones of OOP.
   He says:
   >In Telescript one can also define "class" features, i.e., features that
   >are requested of a class itself. This means, for example, that one can
   >request an operation of a class without having to first create an
   >instance of that class.
 
   What's the purpose of such a facility? To create classes which provide only
   sets of related functions without mapping any "cyberspace" entity? Or
   something else?
 
Class operations are equivalent to static member functions in
C++. Here is a part of something I posted a while ago about class
operations
 
-- start of old post (sorry for taking up bandwith for repeating myself) --
 
Telescript does have class operations which are similar to static
member functions. You define them using the "class" feature key, for
example:
 
MyClass: class = (
public class
  foo:
    op() =
  {
    "Hi".dump();
  };
);
 
Telescript does not have class attributes or class properties. On the
surface this may appear a bit odd, since class operations cannot keep
state between calls to them, but there is a reason ...
 
Classes are immutable, which means they can't change. The problem is
illustrated by looking at an example global Telescript network where
all engines have the class MyOtherClass that has a class attribute
'changeMe'. If some process on an engine in Tokyo changes the value of
this class attribute, that means that every engine in the world would
need to have their class attribute 'changeMe' changed to reflect the
correct value. As you can guess, this is somewhat of an intractable
problem.
 
So ...., you can have class operations, which behave ubiqutously in
every Telescript engine in the world that has that class, but you
cannot have class attributes, because of the immutable problem.
 
One use of a class operation is to have a couple of operations for
instantiating the class, where each operation manipulates arguments,
provides different defaults and then calls new on itself to create a
new instance.
 
-- end old post --
 
   And:
   >Unless a feature you're defining is specifically tagged as a "class"
   features (e.g.,
   >"public class") it will be construed as an instance feature.
 
   Anyway, in the examples that come with TDE, I found "public instance"
   declarations, rather than "public class" ones. Why? Since I found these
   declarations mainly when declaring agent classes, I think it's a way to
   ensure that we are definining features which are responded by an instance
   (the agent) and not by a class.
 
It is mainly because of two things:
1) class features are not used very much (at least so far) &
2) after declaring properties in a class using "properties", the high
Telescript compiler makes you specify whether the next set of features
are public or private, class or instance. This is a bug in the
compiler which will be fixed in a future release
 
   b) Rory says:
   >In a class hierarchy A' is a subclass of A. A has a private operation
   >foo(). Objects of class A' can access the A private operation
   >foo(). If there are two objects of class A' called a1 and a2, a1 can
   >access foo, but a2 *cannot* access a1->foo()
   I think the above is more correct if we say "Objects of class A' can access
   the private operation foo() on objects of class A". Right?
 
I think that Adam de Boor got it correct in his posting (thanks Adam):
 
"what Rory was pointing out was if you've got a private method defined on A,
then a1, being of class A', can access that method on itself, but it cannot
access that method on a2, even if it is also of class A'."
 
   Some additional questions, now...
 
   1) Think about an agent A entering a place P, and meeting with an agent at
   P, say a local agent Al.
   It could be argued that, if A must be able to roam the net, seeking info on
   disparate sources of information, it cannot own as built-in the knowledge
   about the services it can invoke on the various servers it visits.
   In other words, one can say that when A enters P, in principle it couldn't
   have a clue about the services (i.e. the methods, right?) offered by Al.
   A mechanism must be present to "register" services and ask about them, just
   like analogous mechanism do exist for, say,  RPC and CORBA. Does an
   analogous mechanism exist in Telescript, (I guess using packages?) or it up
   to the programmer implement it?
 
In this respect, Telescript is no better or worse than other object
oriented languages.
 
This question brings up at least two problems:
1) how does an agent find the service it wants to interact with ? and
2) how does an agent know how to interacting with the service once it arrives ?
 
The first problem is that agents need to be able to easily find where
the services are. This is type of functionality provided for by yellow
pages. It allows applications to register what services they provide
and the means for reaching them (eg a ticket). In the initial
Telescript service, General Magic supplied a white pages directory to
allow agents to find subscribers and services provided by the
Telescript region. This needs to be extended to move it more toward a
yellow pages service directory.
 
The second problem is interacting with the object that provides the
service, eg a place or agent. In Telescript, you can dynamically
discover the interface of an object by querying the "interface"
attribute of its class, although this feature is not available in the
alpha version of the TDE. This is equivalent to the facilities that
CORBA provides you.
 
Once it knows the object's interface, an agent can be programmed to
invoke the services the object provides, ie it's features.
 
However, the hardest problem is that when programming using RPC, CORBA
or Telescript, you must have an understanding of not only the
syntactic, but also the semantic aspects of the interface that you are
using.
 
As you know this is an area of hot debate. I've heard some rumours of
KQML being used in this context. Has anyone any information on this ?
 
   2) At p.17 of the Language Reference: "Locking an object doesn't lock its
   properties"
   This means that locking doesn't prevent the object itself from
   automodifications, rather it prevents modifications coming from other
   objects, right?
 
Locking the object means that it is isolated and that is makes all
references to it protected. Therefore, if this locked object is the
responder of any feature request and this feature requires some change
to any property, then the engine will throw ReferenceProtected, or
some ObjectLocked type of exception (I can't remember the exact
exception)
 
However, if other objects have references to the locked object's
properties, then the object can manipulate these objects because they
aren't locked.
 
I hope that makes sense !!!
 
   3) I found the definitions of protected vs. readonly in LR and PG quite messy.
   Summing up, is it correct to say that objects which are protected attributes
   (of another object) can't be MODIFIED, while objects which are readonly
   attributes can't be SUBSTITUTED?
 
Your reading is correct. I'll pass your comments onto Jim White.
 
   4) A folkloristical question. Why arrows in the inheritance trees are reversed?
 
Hhhmmm. That's a deep question, that probably has a deep historical
answer like it was something to do with the word processor that Jim
White was using for the first draft of the language. Maybe he couldn't
get the arrows to go the other way :-)
 
   5) At p.9 of the LR: "A block, the typical method [...]"
   What's the meaning of typical? It's the only method... maybe it refers to
   the possibility to insert Low TS expressions?
 
Typical method merely implies that most methods are implemented using
blocks (eg written in Telescript itself). A minority of methods are
implemented as predefined in the engine itself, or as an out methods
in C or C++.
 
Interface features such as operations are implemented using
methods. Each implementation of an operation has one method. A method
consists of one outer block and potentially numerous embedded blocks for
loops and if statements. A block consists of variables and
statements. The variables are only valid within the scope of the
block.
 
   6) At p.15 of the LR: "A reference is voided, among other reasons, if it
   would span too great a distance in the place hierarchy established by the
   predefined classes"
   I read this phrase many times. If the meaning I understood is correct, you
   are not sure to have a reference due to the depth of the place hierarchy.
   Are you kidding? :-)
 
The object model allows processes to have references to objects that
that particular owns. It also allows the process to have references to
objects that other processes own, as long as those processes (agent or
place) are occupants of the same place or are your immediate
superplace.
 
To make that a bit clearer here's an example place hierarchy in some
arbitrary Telescript engine:
 
EnginePlace
  Place P1 (occupied by Agent A1)
    Place P2 (occupied by Agent A2)
 
This can be described as follows: EnginePlace contains one place P1.
Place P1 is occupied by an Agent A1 and another place P2. Place P2 is
occupied by an agent A2.
 
The object model specifies the following:
A1 is allowed have a reference to P1 or anything P1 owns (immediate superplace)
A1 is allowed have a reference to P2 or anything P2 owns (also an occupant of P1)
A1 is *not* allowed a reference to anything in the EnginePlace
A1 is *not* allowed a reference to anything in A2
 
This is what is meant by the paragraph at the top of page 15:
"An operations's requester and responder can be owned by one agent or
place, by two occupants of one place, or by a place and an occupant."
 
I suppose the next question if why ? The answer is that it is a
security mechanism. Places can only be accessed by agents which enter
that place (places can check them in the "entering" operation). Agents
in a place can only be accessed by other agents who are occupants of
the same place and go through a meeting protocol (agents can check
them in the "meeting" operation).
 
Process can not be tickled by other processes which are occupying
places way up or way down the place hierarchy
 
   7) P.67 of the LR: "[...] a trip can result in an agent's duplication"
   I'm just curious about that. Why?
 
When an agent "go"s, it is packed up into a bag-of-bits
(effectionately known as a BOB). It is sent using a PIP TR request to
the destination network and expects a PIP ACK back. It is possible
that the remote communications infrastructure will take too long
before sending the ACK back, or the ACK returns too late. In these
cases the originating communications infrastructure times out and
resends the BOB. When this happens the agent is marked as "possible
duplicate".
 
Hope that helps
/Rory, with help from Luis Valente
--
Rory Ward,
Telescript Bard,
General Magic,
730 N. Mary Avenue,
Sunnyvale CA 94086 USA.
Phone: (408) 774 4296
Magic: [log in to unmask]
Plink: [log in to unmask]