Re: [Pyobjc-dev] Why syntax?

[Bill Bumgarner <bbum@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

[Pyobjc-dev] [Slightly OT] jython com.apple.cocoa vs. cpython pyobjc [was: Why syntax?]

[Steven D. Majewski <sdm7g@mi...>]

Since I brought up jython cocoa access vs. pyobjc:

Both bridges do:
 [1] some automatic conversion to and from equivalent types, for
    example, python and java strings or python strings and NSStrings.
 [2] automatic mapping of equivalent protocols or interfaces, for
    example, in pyobjc, NSArray instances returned from objc methods
    can be treated like python sequences, for example:
	>>> allbundles =  runtime.NSBundle.allBundles()
        >>> print allbundles[0]
        >>> for x in allbundles: print x

 However, in jython to Cocoa access, there are two bridges: Python
  to Java and Java to Objective-C, so you don't always get the
  benefit of automatic conversion or mapping. for example:


Jython 2.1a1 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> from com.apple.cocoa.foundation import *
>>> for x in NSBundle.allFrameworks(): print x
...
Traceback (innermost last):
  File "<console>", line 1, in ?
AttributeError: __getitem__

# You need to get an objectEnumerator to do the equiv:

>>> for x in NSBundle.allFrameworks().objectEnumerator(): print x
...
NSBundle </System/Library/Frameworks/Foundation.framework> (loaded)
NSBundle </System/Library/Frameworks/JavaVM.framework> (loaded)
NSBundle </usr/lib/java> (loaded)
NSBundle </usr/lib> (loaded)
>>>


-- Steve Majewski

Re: [Pyobjc-dev] Why syntax?

[Steven D. Majewski <sdm7g@mi...>]

On Fri, 13 Apr 2001, Andrew Zeldis wrote:

> Is there an archive of your 3-years-ago conversation about this?  Maybe
> it would be easier to just forward that to me...  Although this is
> definitely helping me understand ObjC more!

There WAS an archive at python.org among the retired sigs section,
but now when I try to pull up the archive page, I get a "404 Not Found".

But I read thru it a while ago, and I think you've already heard the
gist of it.

I think it may be worthwhile revisiting this issue later --
 [1] since jython can access cocoa classes, it might be worthwhile
    trying to make the syntax more uniform ( however, there are
     other differences between jython and pyobjc access to Cocoa
     classes, so it's probably never going to be source portable,
     and since Java has overloaded polymorphic methods jython has
     some extra language support for dispatching to the right method.)
 [2] I would like to add more introspective capabilities to pyobjc
    objects -- right now, you can't get any info by doing a dir()
    on an object as you can with native python objects. As was noted
    earlier in this thread, there's no list of methods being maintained
    by the bridge -- you just try calling a method, and if it's not
    there (I think it calls respondsToSelector: )  it'll return an error.
    Introspection CAN be added outside of the runtime (I've been
    playing with the Neo ClassInspector from Python/objc), but if it
    was added to the runtime, it would add some of the support for
    more intelligent method dispatch.


 Right now I'm concentrating on getting what's there working, on figuring
out how it works (Bill was using pyobjc back in the Next days, but I'm
still learning Cocoa, objective-c and pyobjc plumbing. ) and documenting
what's there.
 I think a redesign and a reimplementation is quite likely in the
future: this is version 0.6, and I'ld consider anything < 1 to
indicate experimental and quite likely to change.

 On other big issue it that objc-objects run into the python object-class
barrier. i.e. Eveything in Python is an object but not all objects are
members of classes. Like lists and dictionaries, pyobjc objects that
represent objective-c classes or instances aren't python classes or
instances. It would obviously be much easier and less awkward if
that was not the case.

-- Steve Majewski

Re: [Pyobjc-dev] Why syntax?

[Andrew Zeldis <azeldis@we...>]

Oh, sorry about the moderation.  I keep accidentally posting from the 
wrong account.

Is there an archive of your 3-years-ago conversation about this?  Maybe 
it would be easier to just forward that to me...  Although this is 
definitely helping me understand ObjC more!

I have to say I'm disappointed to find out ObjC parameters are ordered - 
I thought the naming made that unnecessary.  Order-agnosticism would 
seem to me one of the main benefits of having names.

Re: [Pyobjc-dev] Why syntax?

[Bob Savage <bobsavage@ma...>]

>> From: Andrew Zeldis <aez@...>
>> 
>>> 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;
}