[bug #4189] broken bycopy in DO

[nobody]

=================== BUG #4189: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4189&group_id=99

Changes by: Richard Frith-Macdonald <rfm@gnu.org>
Date: Fri 07/04/2003 at 11:59 (GMT)

------------------ Additional Follow-up Comments ----------------------------
Oops, accidentally resubmitted old page.
Anyway -

1. Actually I'm not sure about this ... It used to be flagged as an extension, 
but exactly how GNUstep and NeXT differed at the time is unclear.

2. I'm not very concerned about what particular inferences are taken from 
'official' or 'recommended' ... I think the point is clear.

3. Fine ... get it working first and optimise later ... 

4. Not really a case to agree/disagree ... it's what the NeXTstep objc 
documentation saya and what the compiler does.  We can certainly ask the gcc 
people to change the compiler (it would be a good thing in my opinion) ... or 
better still, you could submit a patch to the compiler to change this.  At the 
very least it would be nice if the compiler warned about differences in the use 
of bycopy or byref etc in protocols and in classes.




=================== BUG #4189: FULL BUG SNAPSHOT ===================


Submitted by: stefanu                 Project: GNUstep                      
Submitted on: Thu 07/03/2003 at 22:40
Category:  Base/Foundation            Severity:  1 - Ordinary               
Bug Group:  Bug                       Resolution:  Fixed                    
Assigned to:  None                    Status:  In Test                      

Summary:  broken bycopy in DO

Original Submission:  if i have a method with bycopy return value on server 
side, i am getting remote objects on clients side insetad of copies. i have to 
explicitly cast on client side to some protocol with same method defined as 
bycopy to make it work. sometimes it is not possible to cast. The server side 
should be responsible and decides what objects are passed by copy or by 
reference.

This bug is related to one former - DO is using selector information from local 
runtime instead of distant runtime. this is wrong and makes it difficult to 
develop and debug DO applications.

Follow-up Comments
*******************

-------------------------------------------------------
Date: Fri 07/04/2003 at 11:59       By: CaS
Oops, accidentally resubmitted old page.
Anyway -

1. Actually I'm not sure about this ... It used to be flagged as an extension, 
but exactly how GNUstep and NeXT differed at the time is unclear.

2. I'm not very concerned about what particular inferences are taken from 
'official' or 'recommended' ... I think the point is clear.

3. Fine ... get it working first and optimise later ... 

4. Not really a case to agree/disagree ... it's what the NeXTstep objc 
documentation saya and what the compiler does.  We can certainly ask the gcc 
people to change the compiler (it would be a good thing in my opinion) ... or 
better still, you could submit a patch to the compiler to change this.  At the 
very least it would be nice if the compiler warned about differences in the use 
of bycopy or byref etc in protocols and in classes.


-------------------------------------------------------
Date: Fri 07/04/2003 at 11:42       By: CaS
This works for me in the current CVS, but a few points are worth noting ...

1. Use of the type information from a remote system is a GNUstep extension and 
is not portable.

2. The official (OpenStep/MacOS-X)way of dealing with this is to use the 
setProtocolForProxy: method of NSDistantObject

3. The DO code is very inefficient if setProtocolForProxy: is not used, since 
it requires a round trip to determine type information, even when a typed 
selector is available locally.

4. DO kewords like bycopy and byref are only meaningful in protocols (they are 
ignored in class interfaces and implementations) ... so the bycopy return value 
on the server side must be declared in a protocol to which the
class of the server instance conforms.


-------------------------------------------------------
Date: Fri 07/04/2003 at 11:33       By: stefanu
After a small talk on #gnustep i reopen this bug. 

Btw. current CVS is broken, so DO in several applications does not work 
properely or at all (segfaults).


-------------------------------------------------------
Date: Fri 07/04/2003 at 11:26       By: stefanu
To reply...

1.i do not think so. using type information from remote system is more logical.

2. it's not official way to use setProtocolForProxy:, but *recommendation* for 
performance reasons, so it should work without that.

3. yes it is, however, i should care about performance and optimalisation, 
after i have working application.

4. i disagree. having bycopy only in protocols is dumb, and if DO system 
fetches infromation from remotes object, it knows that arguments/return value 
is bycopy without needing any protocols.

Protocols are NOT core of DO, but are only helpers.


-------------------------------------------------------
Date: Fri 07/04/2003 at 10:21       By: CaS
This works for me in the current CVS, but a few points are worth noting ...

1. Use of the type information from a remote system is a GNUstep extension and 
is not portable.

2. The official (OpenStep/MacOS-X)way of dealing with this is to use the 
setProtocolForProxy: method of NSDistantObject

3. The DO code is very inefficient if setProtocolForProxy: is not used, since 
it requires a round trip to determine type information, even when a typed 
selector is available locally.

4. DO kewords like bycopy and byref are only meaningful in protocols (they are 
ignored in class interfaces and implementations) ... so the bycopy return value 
on the server side must be declared in a protocol to which the
class of the server instance conforms.



CC list is empty


No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4189&group_id=99

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/