bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DO is not using method types from remote objects


From: Richard Frith-Macdonald
Subject: Re: DO is not using method types from remote objects
Date: Sun, 15 Jun 2003 10:19:01 +0100


On Sunday, June 15, 2003, at 09:38  am, Stefan Urbanek wrote:

Hi,

This is a bit larger problem with DO and selectors. Problem is that somewhere in gnustep DO wrong selector types are used. DO mechanism does not use selector types from remote object but from local runtime.

I'll refer to StepTalk CVS version from Jun 15 10:20 CET. Here is how to reproduce it:

In StepTalk script I want to send a message to a distant object. Say that we have an object Server (from StepTalk sources Examples/Server) which implements method:

- say:(NSString *)string

I have a small script:

s := NSConnection rootProxyForConnectionWithRegisteredName:'Server' host:nil.
    s say:'test'.

Thing is, that on local side I do not know selector say:. What steptalk does? When building an invocation (see [1]) to the distant object, selector is get from NSSelectorFromString. Because there is no selector, nil is returned. Steptalk tries to register the selector by using:

        sel_register_name(name);

where 'name' is [selectorName cString]. This will register selector without type definition. Then I get a method signature from target which is a distant object.:

   signature = [target methodSignatureForSelector:sel];

Signature contains the right selector type information received from remote process.

When I launch the script I get:

2003-06-15 10:27:56.482 stexec[9781] Invalid selector say: (no type information)test

And here is the problem, because on the client side i have no type information in runtime. Should not the information from method signature be used instead of getting one from runtime?

Well, it might be classified as a base library, bug ... but any workaround within the base library would need changes to the objc runtime too, because the runtime will not pass the base library enough information (specifically the object being messaged) to determine the method types associated with the selector.

Within your code, it's likely to be easy to work around, because you probably know what object the message is being sent to ... so you can use -methodSignatureForSelector: to get the type information, then register a typed version of the selector with the runtime. Once you have done that, the DO system should use the typed version of the selector and it should all work.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]