pyobjc-dev

Re: [Pyobjc-dev] Why syntax?

[Bob S. <bob...@ma...>]

>> From: Andrew Zeldis <ae...@ma...>
>> 
>>> A secondary problem is that key/value arguments are not ordered.
>> 
>> Also, I didn't realize ObjC methods were ordered...  Does this mean
>> then that it's wrong to think of them as key/value or named parameters,
>> but as a single method name where variables are "interpolated"?
>> 

Yes. There is a single method name, not key/value pairs.

>> Is there a possibility of more than one selector containing the same
>> "keys" in a different order?
>> 

Yes.

result (test program follows):

Apr 12 20:52:32 testTool[583] cat bat hat
Apr 12 20:52:32 testTool[583] cat hat bat

testTool has exited with status 0.

--test program--

//  testthing.h

#import <Foundation/Foundation.h>

@interface testthing : NSObject { }
- (void) testBy: (NSString *)who wearing:(NSString *)with weilding:(NSString
*)what;
- (void) testBy: (NSString *)who weilding:(NSString *)what wearing:(NSString
*)with;
@end

//  testthing.m

#import "testthing.h"

@implementation testthing
- (void) testBy: (NSString *)who wearing:(NSString *)with weilding:(NSString
*)what {
    NSLog([who stringByAppendingFormat:@" %@ %@", with, what]);
}
- (void) testBy: (NSString *)who weilding:(NSString *)what wearing:(NSString
*)with {
    NSLog([who stringByAppendingFormat:@" %@ %@", what, with]);
}
@end


// main.m

#import <Foundation/Foundation.h>
#import "testthing.h"

int main (int argc, const char * argv[])
{
    testthing *tthing;
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    tthing = [[[testthing alloc] init] retain];
    [tthing testBy: @"cat" weilding:@"bat" wearing:@"hat"];
    [tthing testBy: @"cat" wearing:@"hat" weilding:@"bat"];
    [pool release];
    return 0;
}

Re: [Pyobjc-dev] Why syntax?

[Bill B. <bb...@co...>]

On Thursday, April 12, 2001, at 06:04 PM, Andrew Zeldis wrote:
> On Thursday, April 12, 2001, at 05:11 PM, Bill Bumgarner wrote:
>
>> One key difference between Java and ObjC is that ObjC doesn't require 
>> us to know the method signatures-- the names-- prior to actually 
>> invoking the method.  We can
>
> I've been under the impression that all available selectors were 
> somehow compiled or registered with the ObjC runtime before anything 
> else happened.  Is it possible to define new selectors during runtime, 
> post-load?  If so, I can see how the dynamicicity (?) of ObjC would 
> muck this up, but as I understand it all possible selectors will be 
> available for discovery if the object is available.

All selectors are defined as a bundle/library is loaded.  However, it is 
trivial to define new selectors at runtime (though that is rarely done 
because there is rarely a need).  One particular twist on the complexity 
is that all of the methods available for a particular object are not 
necessarily possible to determine at runtime.   In particular, an object 
may delegate, forward, or proxy some certain set of method invocations 
to other classes, instances, or runtimes at runtime based on a 
dynamically changing set of criteria.

I.e. in ObjC, like SmallTalk, Python, or other similarly purely dynamic 
languages, anything *can* go.   Not that it generally *does* go...


>> A secondary problem is that key/value arguments are not ordered.   
>> I.e. Ignoring for a moment that "win.init(contentRect=frame, 
>> styleMask=15, backing=2, defer=0)" drops the "With", the order with 
>> which the key/value arguments are passed to the init() function cannot 
>> be known.   As such, it makes reconstructing the method really hard;  
>> nearly impossible.
>
> Oh yes, I assumed that using "with" in the method name was a standard, 
> and so could be dropped - like getBlah and setBlah in jython...  Is 
> that true?

Not true;   initWith or stringWith is generally a standard when applying 
state to an object based upon the presence of some other object.  
However, the "With" is merely a naming convention.

> Also, I didn't realize ObjC methods were ordered...  Does this mean 
> then that it's wrong to think of them as key/value or named parameters, 
> but as a single method name where variables are "interpolated"?

Exactly;  the syntax implies interpolation and is derived directly from 
the SmallTalk heritage of Objective-C.   It really isn't that the 
methods are ordered, but that the method name is entirely defined by the 
stuff proceding the colons.  I.e. the method:

+ (NSTimer *)timerWithTimeInterval:(NSTimeInterval)ti target:(id)aTarget 
selector:(SEL)aSelector userInfo:(id)userInfo repeats:(BOOL)yesOrNo;

Has the literal name "timerWithTimeInterval: target: selector: userInfo: 
repeats:".

Consider it this way;  every method can be declared as a C function with 
two "hidden" parameters, self and _cmd.   Just like when calling 
strstrc(), you can't change the order of parameters to an ObjC method 
and have it mean or do the same thing!

For academice purposes, the above method could be defined as a C 
function like:

NSTimer *myCFuncThatBehavesExactlyLikeThatMethod(id self, SEL _cmd, 
NSTimeInterval ti, id aTarget, SEL aSelector, id userInfo, BOOL yesOrNo);

For those folks particularly amused by the bowels of ObjC, it is 
possible and easy to edit the runtime such that a function declared like 
the above could easily replace the implementation of a method declared 
like the way-above.   If you can't figure it out-- it ain't totally 
obvious, don't feel bad, send email and I'll post an example.

> Is there a possibility of more than one selector containing the same 
> "keys" in a different order?

Yes and no;  Yes in that the methods -foo:bar: and -bar:foo: are very 
much different;  no in that there is no concept of "keys" in ObjC.  The 
method calling syntax/convention is derived purely from smalltalk and 
exists solely for clarity of reading source.

>> This was actually discussed at great length in '96 or '97 when Lele, 
>> myself and others were actively working on the ObjC module.  We 
>> determined then that the amount of work did not justify the small 
>> reward.
>
> Well, probably because I'm syntax mad, but this doesn't seem like an 
> especially small reward.  Especially if you're trying to evangelize 
> it.  Right now PyObjC looks very little like Python, *or* ObjC; if the 
> thing looked more like python we'd basically have a native gui 
> framework finished and *polished*.

I would agree if the goal were to make ObjC objects in python appear to 
transparently behave like Python objects and vice-versa.  However, the 
reality is that any intra-language bridge will *always* incur both a 
performance penalty [though ObjC is *much* faster than python] and a 
paradigm shift.

It is the paradigm shift that really matters.

In the 12 years (good GOD that long???!?!! wow! how time flies when you 
are having fun!) that I have been writing ObjC code, there have been 
numerous attempts-- some written by me, most not-- of melding ObjC with 
Perl, Python, TCL, Java, and a whole bunch of other languages.

The one thing that is abundantly clear-- the one thing that has left 
deeeeppp and lllllooooonnnnnggg scars-- is that language A is not like 
language B.   Attempting to make the two languages totally transparently 
intra-compatible is reallyreallyreally neat, but it actually does not 
serve the goal of USEFULNESS.

As much as it seems to be ttractive to be able to message between Python 
and ObJC in a wholly transparent manner, it really does not serve the 
purposes of the developer to the best degree.  In particular, it is 
useful to the developer to be able to read through a body of code and go 
"oh, that consistently weird bit of syntax involving underscores 
actually means I'm messaging into a different OO runtime".  Very 
useful.  Hugely useful;  in my experience, being able to easily 
differentiate between native and foreign invocations-- be it 
intra-language or inter-runtime-- has saved *hundrends* of hours of 
debugging time.

Not that I don't think totally transparent inter-language coding is NOT 
cool-- I do think its cool and it would be really neat to achieve.  
However, I do *firmly*-- i.e. based on lots of experience, jaded or 
not-- believe that such an achievement would not yield an environment 
that maximizes developer productivity!

> It doesn't look like the ObjC runtime provides anything more than 
> NSSelectorFromString, is that  right?  So basically it'd have to run 
> through all the permutations of the parameter names, testing each one, 
> until it matched.  Maybe a little slow, and annoying, but it doesn't 
> seem that hard...?

Not hard... except the fuzzy matching and that it is several orders of 
magnitude slower than what is in place today.... and that it would 
occasionally and in very weird circumstances invoke totally the wrong 
method in a fashion that would be incredibly hard to debug, if it was 
even reproducible (as is the case with any 
non-ordered-applied-to-ordered test).

> Anyway, now that it's building with distutils (thanks!) I think I'll 
> attempt it - just please don't say I told you so!

Go for it!  I'm certainly not such an egotist to think that my opinions 
are the end all / be all.  If you figure out a way to pull it off, I'll 
adopt your code in a millisecond!!

> Are the NSFunctions  (like NSSelectorFromString) made available to 
> Python somewhere?

Nope;   actually,  we really need to clean up the whole pyobjc module 
and:

	- remove legacy cruft

	- remove GnuObjC/GnuStep support until someone volunteers to (a) 
update it to modern standards and (b) maintain it over time

	- modernize some of the facilties within the module to map to 
low-level runtime servicves that are "new" to OpenStep 4.2 and beyond 
[OS4.2 and prior being the primary platform under which the module was 
"designed"].

b.bum