[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #4068] DO uses typed selector from local instead of distant object.
From: |
nobody |
Subject: |
[bug #4068] DO uses typed selector from local instead of distant object. |
Date: |
Sun, 22 Jun 2003 05:17:06 -0400 |
User-agent: |
Mozilla/4.5 (compatible; OmniWeb/4.2-v435.2; Mac_PowerPC) |
=================== BUG #4068: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4068&group_id=99
Changes by: Richard Frith-Macdonald <rfm@gnu.org>
Date: Sun 06/22/2003 at 09:17 (GMT)
------------------ Additional Follow-up Comments ----------------------------
I'm not sure about this ... DO has to handle arguments both locally and
remotely, so the argument types on both ends of the connection must match
Where there is no type information at the local end, DO fetches it from the
remote end, so the simple assertion that DO uses the local runtime rather than
the remote end is not the case. I think we need more specific
examples/testcases of exactly what the problem is.
I seem to recall an email conversation about an objc-runtime problem with
selector types for forwarding. Is this the same problem in a different guise?
=================== BUG #4068: FULL BUG SNAPSHOT ===================
Submitted by: stefanu Project: GNUstep
Submitted on: Sun 06/22/2003 at 08:22
Category: Base/Foundation Severity: 7
Bug Group: Bug Resolution: None
Assigned to: None Status: Open
Summary: DO uses typed selector from local instead of distant object.
Original Submission: Distributed Objects in -base uses information about typed
selectors (for building method signatures and invocations) from local runtime
instead of distant object. This is ugly behaviour and causes, for example,
segfaults due to type mismatches or selector nonexistence.
Follow-up Comments
*******************
-------------------------------------------------------
Date: Sun 06/22/2003 at 09:17 By: CaS
I'm not sure about this ... DO has to handle arguments both locally and
remotely, so the argument types on both ends of the connection must match
Where there is no type information at the local end, DO fetches it from the
remote end, so the simple assertion that DO uses the local runtime rather than
the remote end is not the case. I think we need more specific
examples/testcases of exactly what the problem is.
I seem to recall an email conversation about an objc-runtime problem with
selector types for forwarding. Is this the same problem in a different guise?
CC list is empty
No files currently attached
For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4068&group_id=99
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/