[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #4189] broken bycopy in DO
From: |
nobody |
Subject: |
[bug #4189] broken bycopy in DO |
Date: |
Fri, 04 Jul 2003 07:26:05 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030401 Debian/1.0.2-2 |
=================== BUG #4189: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4189&group_id=99
Changes by: Stefan Urbanek <urbanek@host.sk>
Date: Fri 07/04/03 at 13:26 (Europe/Bratislava)
What | Removed | Added
---------------------------------------------------------------------------
Resolution | Fixed | Later
------------------ Additional Follow-up Comments ----------------------------
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.
=================== BUG #4189: FULL BUG SNAPSHOT ===================
Submitted by: stefanu Project: GNUstep
Submitted on: Fri 07/04/03 at 00:40
Category: Base/Foundation Severity: 1 - Ordinary
Bug Group: Bug Resolution: Later
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/03 at 13: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/03 at 12: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/
- Re: [bug #4189] broken bycopy in DO, (continued)
- Re: [bug #4189] broken bycopy in DO, Richard Frith-Macdonald, 2003/07/04
- Re: [bug #4189] broken bycopy in DO, Alexander Malmberg, 2003/07/04
- Re: [bug #4189] broken bycopy in DO, Richard Frith-Macdonald, 2003/07/04
- Re: [bug #4189] broken bycopy in DO, Richard Frith-Macdonald, 2003/07/04
- Re: [bug #4189] broken bycopy in DO, Alexander Malmberg, 2003/07/04
- Re: [bug #4189] broken bycopy in DO, Richard Frith-Macdonald, 2003/07/04
- Re: [bug #4189] broken bycopy in DO, Nicola Pero, 2003/07/04
- Re: [bug #4189] broken bycopy in DO, Richard Frith-Macdonald, 2003/07/04
- Re: [bug #4189] broken bycopy in DO, Richard Frith-Macdonald, 2003/07/04
- Re: [bug #4189] broken bycopy in DO, Alexander Malmberg, 2003/07/04
[bug #4189] broken bycopy in DO,
nobody <=
[bug #4189] broken bycopy in DO, nobody, 2003/07/04
[bug #4189] broken bycopy in DO, nobody, 2003/07/04
[bug #4189] broken bycopy in DO, nobody, 2003/07/04