RE: IDL attributes (was: Re: Some requirements)

Sanjiva,

(cc'ing to Jim because I am not sure whether he's subscribed to this
mailing list).

> 
> However, how are attributes retrieved in the client stub? There must
> be some method invocation I assume. If so, the skeleton must have
> such a method isn't it? So is there a fixed binding for the server
> skeleton then? Otherwise I'm not sure how the client's property or
> field would get filled when the stub user requests the value.
> 

Let's assume that we have an IDL interface like the following (the
syntax may not be entirely correct)

interface MyInterface
{
   attribute string myAttribute;
   method void myMethod(string);
}

An IDL to programming language mapping will create the appropriate class
for the above interface. An IDL to CORBA mapping may create
server/client skeletons. To the user of the client skeleton it will
appear as if it has local access to an instance of the generated class.
Any method invocations and/or communication are defined by the CORBA
standard and not by the IDL standard.

> BTW, if it gets bound to a property in C# I assume C# has a way
> to associate code to be run when a property is read? If not how does
> the property get filled?
> 

For the example above, the C# code that could be generated:

class MyInterface
{
   private string _myAttribute;

   // Get/Set property
   public string myAttribute
   {
      get { return this._myAttribute;  }
      set { this._myAttribute = value; }
   }

   public void myMethod(string arg)
   { ... }
}


The actual implementation of the properties may not be automatically
provided and, probably, they wouldn't.


Please, refer to my previous message for more examples on IDL to
programming language bindings.


Also note that an attribute may be mapped to a public data member
(depending on the language binding that is used). In such cases, no
implementation code would necessary (e.g., no get/set Java methods or
get/set C# properties). 

.savas.

Received on Wednesday, 18 June 2003 05:35:55 UTC