bugGNUstep - Bugs: bug #4189, broken bycopy in DO

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #4189: broken bycopy in DO

Submitted by:  Stefan Urbanek <stefanu>
Submitted on:  Thu 03 Jul 2003 10:40:07 PM UTC  
 
Category: Base/FoundationSeverity: 1 - Wish
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

Sun 05 Jun 2005 05:29:43 AM UTC, comment #6:

NBo further activity, so I closed this.

Richard Frith-Macdonald <CaS>
Project Member
Fri 04 Jul 2003 11:59:29 AM UTC, comment #5:

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.

Richard Frith-Macdonald <CaS>
Project Member
Fri 04 Jul 2003 11:42:11 AM UTC, comment #4:

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.

Richard Frith-Macdonald <CaS>
Project Member
Fri 04 Jul 2003 11:33:36 AM UTC, comment #3:

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).

Stefan Urbanek <stefanu>
Project Member
Fri 04 Jul 2003 11:26:02 AM UTC, comment #2:

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.

Stefan Urbanek <stefanu>
Project Member
Fri 04 Jul 2003 10:21:53 AM UTC, comment #1:

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.

Richard Frith-Macdonald <CaS>
Project Member
Thu 03 Jul 2003 10:40:07 PM UTC, 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.

Stefan Urbanek <stefanu>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 10 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sun 05 Jun 2005 05:29:43 AM UTCCaSOpen/ClosedIn Test=>Closed
Fri 04 Jul 2003 11:42:11 AM UTCCaSSeverity3 - Normal=>(Error - Not Found)
  StatusPostponed=>(Error - Not Found)
  Open/ClosedOpen=>(Error - Not Found)
Fri 04 Jul 2003 11:33:36 AM UTCstefanuSeverity1 - Wish=>(Error - Not Found)
  Open/ClosedIn Test=>(Error - Not Found)
Fri 04 Jul 2003 11:26:02 AM UTCstefanuStatusFixed=>(Error - Not Found)
Fri 04 Jul 2003 10:21:53 AM UTCCaSSeverity4 - Important=>(Error - Not Found)
  StatusNone=>(Error - Not Found)
  Open/ClosedOpen=>(Error - Not Found)

Back to the top


Powered by Savane 3.1-cleanup1