pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Feedback needed for documentation

[Dinu G. <gh...@da...>]

Zachery Bir:

> It's a blank ZWiki Web. It's open for all to edit. I've given everyone 
> the ability to create and edit wiki pages, add documents and images 
> (patches, etc), and subscribe to wiki pages.

Great - thanks! For the paranoids among us: could you also make
a daily archive and upload it somewhere, perhaps? Maybe, SF would
be a natural place, but I don't know if that works smoothly.

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"It is by the goodness of God that in our country we have these three
unspeakably precious things: freedom of speech, freedom of conscience,
and the prudence to practice neither." (Mark Twain)

Re: [Pyobjc-dev] Feedback needed for documentation

[Zachery B. <zb...@ur...>]

On Tuesday, May 13, 2003, at 05:53 AM, Richard Chamberlain wrote:

> If a wiki is the way people decide to go and no-one else is willing, I 
> will by all means set something up on my server.

I've just set one up at:

   <http://pyobjc.urbanape.com/>

It's a blank ZWiki Web. It's open for all to edit. I've given everyone 
the ability to create and edit wiki pages, add documents and images 
(patches, etc), and subscribe to wiki pages.

ZWikis are a little bit different, if you're used to traditional 
c2.com-style wikis.

To get started, you can browse the help.

   <http://pyobjc.urbanape.com/HelpPage>

Zac

Re: [Pyobjc-dev] Feedback needed for documentation

[Richard C. <sun...@ma...>]

Hello,

On Tuesday, May 13, 2003, at 10:01  am, Dinu Gherman wrote:

> Just van Rossum:
>
>> Dunno, I'm not much of a wiki person myself (or rather: I have little
>> experience with them). If you want to contribute stuff, it's probably
>> best to post patches to the sf tracker. Even though sf is dog slow at
>> times, tracker items work pretty well for discussing single items. 
>> But:
>> if someone sets up a wiki, that would be great, too.
>
> Well, I don't know what a "Wiki person" really is. For me a tool
> either works or it doesn't. The only reason I can see for not
> using a Wiki is a bad connectivity.

Well I agree with Dinu that a wiki can be useful thing, and personally 
I would find it a whole heap easier to contribute to something like 
documention if I didn't have to post patches to SF. Also having a 
Pyobjc resource like a wiki would be a good thing.

I presume you guys have seen http://www.cocoadev.com?

If a wiki is the way people decide to go and no-one else is willing, I 
will by all means set something up on my server.

Richard

Re: [Pyobjc-dev] Feedback needed for documentation

[Dinu G. <gh...@da...>]

Just van Rossum:

> Dunno, I'm not much of a wiki person myself (or rather: I have little
> experience with them). If you want to contribute stuff, it's probably
> best to post patches to the sf tracker. Even though sf is dog slow at
> times, tracker items work pretty well for discussing single items. But:
> if someone sets up a wiki, that would be great, too.

Well, I don't know what a "Wiki person" really is. For me a tool
either works or it doesn't. The only reason I can see for not
using a Wiki is a bad connectivity.

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"Consistency is the last refuge of the unimaginative." (Oscar Wilde)

Re: [Pyobjc-dev] Feedback needed for documentation

[Just v. R. <ju...@le...>]

Dinu Gherman wrote:

> Sorry to be so insisting... Is there such a Wiki or not?

Given the lack of response, I think there's not...

> I don't think a mailing list is appropriate to really work
> on some text.

Dunno, I'm not much of a wiki person myself (or rather: I have little
experience with them). If you want to contribute stuff, it's probably
best to post patches to the sf tracker. Even though sf is dog slow at
times, tracker items work pretty well for discussing single items. But:
if someone sets up a wiki, that would be great, too.

Just

[Pyobjc-dev] Subclassing NSCell?

[Mitch C. <mit...@ea...>]

Does anyone have examples of subclassing NSCell from within a
Cocoa-Python Document-based application?  I'm trying to do this with
Python 2.3b1 and PyObjc-0.9.

I can create instances of the subclass, defined roughly as

from AppKit import *
class MyCell(NSCell):
	...

and can install these instances as data cells for NSTableColumns in an 
NSTableView.
All cool.  But if I try to override drawInteriorWithFrame_inView_, as 
follows,
I get a segmentation fault on the first attempt to draw cell contents.  
What's more,
I don't get the output from the print statement.

     def drawInteriorWithFrame_inView_(self, cellFrame, controlView):
         print "drawInteriorWithFrame_inView_"
         return super(MyCell, 
self).drawInteriorWithFrame_inView_(cellFrame, controlView)

Note:  I also get the segfault if I comment out the return statement.

If I create an instance from an interactive Python shell and invoke
drawInteriorWithFrame_inView_ manually, with None for both arguments, I 
at least get the
print statement output.

Thanks for guidance!

--
Mitch

Re: [Pyobjc-dev] problem saving as rtfd

[Marcel W. <ma...@me...>]

On Monday, May 12, 2003, at 07:51  Uhr, Ronald Oussoren wrote:

>
> On Monday, May 12, 2003, at 08:43 Europe/Amsterdam, Marcel Weiher 
> wrote:
>
>>
>>>         plaintext = ""
>>>         cyphertext = NSData.alloc()
>>
>> Minor nit:  you shouldn't really have a partly initialized instance 
>> flying around.
>
> This is *not* a minor issue. Some Cocoa classes will cause crashes if 
> you do anything with them before calling init, and that includes 
> releasing them. PyObjC tries to protect you from this, but this is 
> still bad form.

Yes, actually doing anything with the object other than sending some 
sort of init message  *would* be bad.  However, the original poster 
didn't do that, and for the object in question, it actually makes no 
difference whatsoever, since only the sequencing matters (unless the 
code is seriously messed up).  It cannot tell what if anything happened 
between the alloc and the init.   It can be the very next thing, it can 
be a million years later.

	id object = [[NSObject alloc] init];
and
	id obj = [NSObject alloc];
	sleep( 365 * 24 * 3600 );
	obj=[obj init];

are completely equivalent as far as the object is concerned.  Of 
course, the latter is definitely odd looking, and there is no good 
reason for not initializing it immediately, whereas there are very good 
reasons *for* doing the initialization immediately, which is why I did 
bring it up.

Of course, with a bridge involved, you may have to be more careful 
because the bridge might have reasons for touching the object that 
aren't obvious from the code.

Marcel

-- 
Marcel Weiher				Metaobject Software Technologies
ma...@me...		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.

[Pyobjc-dev] Best way...??

[Gary R. <gro...@tr...>]

Hi,

In the tutorial.html file, the process of creating a PyObjC app without
Project Builder is described.

In the TableModel2 example, the readme.txt file describes how to use Project
Builder, starting with creating a new "Cocoa Application" in PB.

In Project Builder itself, there is a choice to create a Cocoa-Python
application under "New...". This seems to result in a substantially
different setup than the TableModel2 example does.

Is there any technique that is "safest" in terms of using well-tested code
out of the above three? Is there a worst technique?

I'd kind of like to use PB, but it's much more important to me to use
well-tested, highly maintained code.

--Gary

-- 
<http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org>

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454

Re: [Pyobjc-dev] Passing selectors as parameters

[Just v. R. <ju...@le...>]

Just van Rossum wrote:

>     def awakeFromNib(self):
>         ...
>         return self

Whoops, that's a turd left from an earlier version. Of course you
shouldn't return self (or anything) from awakeFromNib()...

Just

Re: [Pyobjc-dev] Passing selectors as parameters

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> >     I have an NSListView whose double-click actions I would like to 
> > handle.  NSListView.setDoubleAction_( action ) requires a selector.  
> > My problem is that I'm not sure how to pass a method as a selector.  I 
> > would like to pass a class "instance" method (i.e. "def 
> > didDoubleClick( self ):") that belongs to the class I use as the 
> > listview's data source.  What is the correct way to do this?  I have 
> > tried a number of ways, and have searched for answers but have found 
> > no working solution yet.
> 
> You can use MyClass.didDoubleClick_ (e.g. a reference to an unbound
> method, although bound methods also work).

(Note that PyObjC then uses the method to get at the selector, ie. the method
name, it does not otherwise use the method.)

> Another option is the
> method name as a string ("didDoubleClick_").

Except you need to use the ObjC spelling then: "didDoubleClick:". I just
tried, the underscore notation doesn't work.

> You can use 'setTarget_(obj)' to set where the message should be send
> to.

Here's a snippet from the TableModel example (as of today, I checked in some
changes):

    def awakeFromNib(self):
        ...
        self.tableView.setTarget_(self)
        self.tableView.setDoubleAction_("doubleClick:")
        # this also works, but you still need to set the target:
        #self.tableView.setDoubleAction_(self.doubleClick_)
        return self

    def doubleClick_(self, sender):
        # double-clicking a column header causes clickedRow() to return -1
        print "doubleClick!", sender.clickedColumn(), sender.clickedRow()


> Note that the names of action methods should end with an underscore.

Just

Re: [Pyobjc-dev] Passing selectors as parameters

[Ronald O. <ous...@ci...>]

On Monday, May 12, 2003, at 10:01 Europe/Amsterdam, Sean Gilbertson 
wrote:

> Hello all,
>
> 	I have an NSListView whose double-click actions I would like to 
> handle.  NSListView.setDoubleAction_( action ) requires a selector.  
> My problem is that I'm not sure how to pass a method as a selector.  I 
> would like to pass a class "instance" method (i.e. "def 
> didDoubleClick( self ):") that belongs to the class I use as the 
> listview's data source.  What is the correct way to do this?  I have 
> tried a number of ways, and have searched for answers but have found 
> no working solution yet.

You can use MyClass.didDoubleClick_ (e.g. a reference to an unbound 
method, although bound methods also work). Another option is the method 
name as a string ("didDoubleClick_"). You can use 'setTarget_(obj)' to 
set where the message should be send to.

Note that the names of action methods should end with an underscore.

Ronald

Re: [Pyobjc-dev] problem saving as rtfd

[Ronald O. <ous...@ci...>]

On Monday, May 12, 2003, at 08:43 Europe/Amsterdam, Marcel Weiher wrote:

>
>>         plaintext = ""
>>         cyphertext = NSData.alloc()
>
> Minor nit:  you shouldn't really have a partly initialized instance  
> flying around.

This is *not* a minor issue. Some Cocoa classes will cause crashes if  
you do anything with them before calling init, and that includes  
releasing them. PyObjC tries to protect you from this, but this is  
still bad form.

>
>>         #if the plaintext was manually encrypted then
>> it needs no further encryption
>>         #in fact further encryption could be harmful
>>         if self.encrypted == NO and
>> self.saveSwitch.state() == 1:
>>             #edited out as this code isn't running
>> 	        #at this time.
>>         else:
>>             length = len(self.text.string())
>>
>> cyphertext.initWithBytes_length(self.text.RTFDFromRange_((0,length)),l 
>> ength)
>
> That's the problem right here:
>
>
> 1. RTFDFromRange already returns an NSData, and what you are doing is  
> initializing a second NSData object with the pointer of the NSData  
> *object*.
>
> 2. RTFDFromRange is "an RTFD stream corresponding to the characters  
> and attributes within aRange".  This is a pasteboard representation an  
> not something you can directly/usefully save as a file.

3. you ignore the result of an initializer. You should always use the  
value returned by the initalizer and no longer use the value returned  
by alloc.

Ronald

[Pyobjc-dev] =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoTDVOQSVXJWwlPCVzJUgbKEI=?=

[<kur...@dr...>]

＜事業者＞ジュエリーノン　２度と配信いたしませんので配信不要の方はこのままご返信くださいkur...@dr...
＜送信者＞しんわ　http://members.goo.ne.jp/home/kurosawa9696  拒否kur...@dr... 
＜内容＞無料プレゼント　●リニューアルオープン記念！シルバーリング又は18金ピアスを男女５００名様にプレゼント！応募方法はこち
らからどうぞ
http://homepage3.nifty.com/gurozawa/

Re: [Pyobjc-dev] Passing selectors as parameters

[Just v. R. <ju...@le...>]

Sean Gilbertson wrote:

> I have an NSListView

I assume you mean NSTableView?

> whose double-click actions I would like to handle. 
> NSListView.setDoubleAction_( action ) requires a selector. My problem
> is that I'm not sure how to pass a method as a selector. I would like
> to pass a class "instance" method (i.e. "def didDoubleClick( self
> ):") that belongs to the class I use as the listview's data source. 
> What is the correct way to do this?  I have tried a number of ways,
> and have searched for answers but have found no working solution yet.

The selector is the (ObjC) method name, it's not a bound method. Also,
unless you already set a target in IB, you also need to set the target
with tableView.setTarget_(). So to make self.myDoubleAction_ the double
click action, you do

    tableView.setTarget_(self)
    tableView.setDoubleAction_("myDoubleAction:")

Just

Re: [Pyobjc-dev] problem saving as rtfd

[Marcel W. <ma...@me...>]

On Monday, May 12, 2003, at 11:06  Uhr, chris wrote:

>
> "writeToFile_atomically_updateFilenames_"
> rather than
> "writeToFile_atomically_"
>
> hence the collapse. This is the current code:

Yes.  The NSFileWrapper is not an NSData, so you need to use a 
different method.

What happens when you use the different method?

Marcel


-- 
Marcel Weiher				Metaobject Software Technologies
ma...@me...		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.

Re: [Pyobjc-dev] problem saving as rtfd

[chris <por...@ya...>]

Now I am getting this on the console and a complete
app crash:

 *** -[NSFileWrapper writeToFile:atomically:]:
selector not recognized
Traceback (most recent call last):
  File
"/Users/c/SecretText/build/SecretText.app/Contents/Resources/__main__.py",
line 20, in ?
    sys.exit(AppKit.NSApplicationMain(sys.argv))
ValueError: NSInvalidArgumentException - ***
-[NSFileWrapper writeToFile:atomically:]: selector not
recognized

Stepping through the code in the terminal the
NSFileWrapper comes back fine but it looks like it has

"writeToFile_atomically_updateFilenames_"
rather than 
"writeToFile_atomically_"

hence the collapse. This is the current code:

else:
            length = len(self.text.string())
            store = self.text.textStorage()
            cyphertext =
store.RTFDFileWrapperFromRange_documentAttributes_((0,length),None)
        
        #output the cyphertext to a file
        return cyphertext

Chris

--- Marcel Weiher <ma...@me...> wrote:
> 
> >         plaintext = ""
> >         cyphertext = NSData.alloc()
> 
> Minor nit:  you shouldn't really have a partly
> initialized instance  
> flying around.
> 
> >         #if the plaintext was manually encrypted
> then
> > it needs no further encryption
> >         #in fact further encryption could be
> harmful
> >         if self.encrypted == NO and
> > self.saveSwitch.state() == 1:
> >             #edited out as this code isn't running
> > 	        #at this time.
> >         else:
> >             length = len(self.text.string())
> >
> >
>
cyphertext.initWithBytes_length(self.text.RTFDFromRange_((0,length)),le
> 
> > ngth)
> 
> That's the problem right here:
> 
> 
> 1. RTFDFromRange already returns an NSData, and what
> you are doing is  
> initializing a second NSData object with the pointer
> of the NSData  
> *object*.
> 
> 2. RTFDFromRange is "an RTFD stream corresponding to
> the characters and  
> attributes within aRange".  This is a pasteboard
> representation an not  
> something you can directly/usefully save as a file.
> 
> 
> So, what you need is
> -RTFDFileWrapperFromRange:documentAttributes: ,  
> which returns a file-wrapper object that you can
> save.
> 
> More can be found in the fine documentation:   
> NSAttributedString  
> class reference + some concept docs "RTF Files and
> Attributed Strings",  
> referenced from the NSAttributedString class
> reference.
> 
> Marcel
> 
> -- 
> Marcel Weiher				Metaobject Software Technologies
> ma...@me...		www.metaobject.com
> Metaprogramming for the Graphic Arts.   HOM, IDEAs,
> MetaAd etc.
> 

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

[Pyobjc-dev] Passing selectors as parameters

[Sean G. <pr...@cf...>]

Hello all,

	I have an NSListView whose double-click actions I would like to 
handle.  NSListView.setDoubleAction_( action ) requires a selector.  My 
problem is that I'm not sure how to pass a method as a selector.  I 
would like to pass a class "instance" method (i.e. "def didDoubleClick( 
self ):") that belongs to the class I use as the listview's data 
source.  What is the correct way to do this?  I have tried a number of 
ways, and have searched for answers but have found no working solution 
yet.

Thanks,
	Sean

Re: [Pyobjc-dev] problem saving as rtfd

[Marcel W. <ma...@me...>]

>         plaintext = ""
>         cyphertext = NSData.alloc()

Minor nit:  you shouldn't really have a partly initialized instance  
flying around.

>         #if the plaintext was manually encrypted then
> it needs no further encryption
>         #in fact further encryption could be harmful
>         if self.encrypted == NO and
> self.saveSwitch.state() == 1:
>             #edited out as this code isn't running
> 	        #at this time.
>         else:
>             length = len(self.text.string())
>
> cyphertext.initWithBytes_length(self.text.RTFDFromRange_((0,length)),le 
> ngth)

That's the problem right here:


1. RTFDFromRange already returns an NSData, and what you are doing is  
initializing a second NSData object with the pointer of the NSData  
*object*.

2. RTFDFromRange is "an RTFD stream corresponding to the characters and  
attributes within aRange".  This is a pasteboard representation an not  
something you can directly/usefully save as a file.


So, what you need is -RTFDFileWrapperFromRange:documentAttributes: ,  
which returns a file-wrapper object that you can save.

More can be found in the fine documentation:    NSAttributedString  
class reference + some concept docs "RTF Files and Attributed Strings",  
referenced from the NSAttributedString class reference.

Marcel

-- 
Marcel Weiher				Metaobject Software Technologies
ma...@me...		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.

[Pyobjc-dev] problem saving as rtfd

[chris <por...@ya...>]

Hello all, First of all I'd like to thank you for such
a great tool. Now on to my problem I'm having a
problem saving a file as rtfd. everything goes fine
but when I open the result in TextEdit it is
unformatted, the formatting information being clearly
visible as if it where part of the text. Does anyone
know what's going on here? Thank you in advance.

Chris

file infomation set in targets:

Name: rtfd
Role: Editor
OS Type: rtfd
extensions: rtfd
signature: rtfd

the saving function:

    def dataRepresentationOfType_(self, aType):
        # return an NSData containing the document's
data represented as
        # the type identified by aType.
        
        passphrase = self.keyString.string()
        cypherChoise =
self.cypherOptions.titleOfSelectedItem()
        
        plaintext = ""
        cyphertext = NSData.alloc()
        
        #if the plaintext was manually encrypted then
it needs no further encryption
        #in fact further encryption could be harmful
        if self.encrypted == NO and
self.saveSwitch.state() == 1:
            #edited out as this code isn't running
	        #at this time.
        else:
            length = len(self.text.string())
           
cyphertext.initWithBytes_length(self.text.RTFDFromRange_((0,length)),length)
        
        #output the cyphertext to a file
        return cyphertext
	
sample output for bold "hello world" copied from
TextEdit:

rtfd

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Re: [Pyobjc-dev] Calling methods on nil

[Marcel W. <ma...@me...>]

On Sunday, May 11, 2003, at 11:20  Uhr, bb...@ma... wrote:

> On Sunday, May 11, 2003, at 11:49 US/Eastern, Marcel Weiher wrote:
>>> Having done ObjC development since 1989 -- 4 or 5 years prior to 
>>> diving into Python -- you might be surprised to learn that I very 
>>> strongly prefer the behavior of Python's (and Java's) 'message to 
>>> nil throws' behavior vs. ObjC's 'message to nil silently eaten'.
>>
>> Having done ObjC development since 1987, I much prefer the coding 
>> simplicity the current behavior gives, while I don't recall the 
>> problems you report being anything but an extremely rare occurrence.
>
> Difference in experience then --

Obviously.  It begs the question:  why are you experiencing these 
problems?  It can't really be message-eating nil by itself, because 
then I should be experiencing those same problems.  But I am not.

>  I have spent a good part of my career mentoring teams to help them 
> achieve success.

Good for you!  Maybe that is why you are experiencing those problems 
and I do not, because you help with success and I only help with 
failure...

>   This is typically done in environments where the project is under 
> "schedule stress".  More often than not a major source of stress is 
> "strange or intermittent failures".

Lucky you!  I only wish my major sources of stress were something I had 
control over.

My sources of "stress" are usually somewhat more external, like a 
customer whose customer is about to pull the plug on them because their 
3rd attempt at delivering a content management system also failed, and 
now they've come to us and we have 3 days to get the system running 
when we had planned for another couple of months.  With the added 
stress that my master's thesis for university is due that same week 
(that was fun!)  Or arriving at a trade show to find that the equipment 
you've been provided doesn't actually work, and you have to re-write 
the RIP software for tomorrow morning...well, actually for later 
today...things like that.

> If you have a construct like...
>
>     [[[[foo bar] baz] bob] fred];
>
> ... and any one of -bar, -baz, -bob, or -fred unexpectedly returns nil 
> when it shouldn't, debugging is a nightmare.

Really?  Actually, debugging such deeply nested expressions with gdb 
really is a pain, but this also has nothing to do with nil-eating or 
not nil-eating.  It has to do with deeply nested expressions and the 
difficulty of setting breakpoints within such an expression.

>>> When everything is working correctly 'message to nil silently eaten' 
>>> is a great convenience.  When something somewhere unexpectedly 
>>> returns nil, it becomes an incredibly nasty pain to try and figure 
>>> out exactly where the problem might be.   By the time it crops up, 
>>> you may be many cycles through the run loop away from where the 
>>> problem actually is.
>>
>> Hmmm...this sounds like you are working too much with mutable state, 
>> in which case nils are just one symptom, and doctoring about with 
>> this one symptom is just hiding the deeper problems.  If you move 
>> away from mutable state, you will also find that you don't have 
>> problematic values (of which nil is just one prominent example) 
>> causing problems when the cause of the problem (of the problematic 
>> value) has long since disappeared from the call-stack.
>>
>> If you use a more "functional" programming style, pulling values and 
>> evaluating expressions when needed instead of pushing values and 
>> stashing computed values, you will likely find that you don't get 
>> this type of problem-propagation.
>
> No -- that is not the problem.

Objection:  if you are "...many cycles through the run loop away..." 
then you are *definitely* having a problem with propagating incorrect 
values in mutable state.  Unless you have found a magical method of 
keeping temporary variables around between event-loop cycles 
(cyrogenics? ;-)

> There is the potential for the problem to arise *anywhere* a method is 
> invoked/called/messaged where the developer has not previously 
> validated that the target is non-nil.

Well, otherwise it is even worse.  You have the chance of an exception 
messing you up despite the fact that there may not actually be a 
problem.  For example, to be safe, the simple line of code above would 
have to check for nil before every message send:

[[[[foo bar] baz] bob] fred];

if ( foo!=nil ) {
	id temp1=[foo bar];
	if ( temp1 != nil ) {
		[temp1 baz];
		... and so on ...
	}
}

Why?  Well, if nil is a problem in the code-snippet, then it is 
obviously unexpected.   Otherwise, it would either be handled or 
ignoring it would be OK.  However, if it is unexpected, then you can't 
say which message-send will return nil "unexpectedly"...

[snip]

>> Also, I believe very strongly in "intention-revealing" code.  That 
>> is, the code should reflect the problem, not the technology.  Things 
>> like constant checking of types/nil-values/exceptions typically have 
>> nothing to do with the problem domain, and do little but obscure the 
>> solution.  I certainly notice that my Java code is a lot more verbose 
>> and a lot less maintainable than my Objective-C code.
>
> It would seem that "intention revealing" would mean writing code that 
> shows that the developer intended to deal with the fact that something 
> could potentially be nil in a valid situation by actually checking for 
> it.

That turns out not to be the case.  "Intention revealing" means that 
you reveal what the *intent* of the code is.  Error-handling is 
*implementation*, because I am sure it is not your intention to cause 
errors...well, I *hope* it isn't ;-)

[snip]

Anyway, I am fairly confident that this discussion has outlived its 
usefulness.  I have no problem with you preferring "raising-nil" if 
that helps you and your colleagues/clients.  I just want to point out 
that the problems you seem to have experienced are not universally 
shared, and it is therefore quite reasonable to come to different 
conclusions.

Marcel

-- 
Marcel Weiher				Metaobject Software Technologies
ma...@me...		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.

Re: [Pyobjc-dev] Calling methods on nil

[<bb...@ma...>]

On Sunday, May 11, 2003, at 11:49 US/Eastern, Marcel Weiher wrote:
>> Having done ObjC development since 1989 -- 4 or 5 years prior to 
>> diving into Python -- you might be surprised to learn that I very 
>> strongly prefer the behavior of Python's (and Java's) 'message to nil 
>> throws' behavior vs. ObjC's 'message to nil silently eaten'.
>
> Having done ObjC development since 1987, I much prefer the coding 
> simplicity the current behavior gives, while I don't recall the 
> problems you report being anything but an extremely rare occurrence.

Difference in experience then -- I have spent a good part of my career 
mentoring teams to help them achieve success.  This is typically done 
in environments where the project is under "schedule stress".  More 
often than not a major source of stress is "strange or intermittent 
failures".

If you have a construct like...

     [[[[foo bar] baz] bob] fred];

... and any one of -bar, -baz, -bob, or -fred unexpectedly returns nil 
when it shouldn't, debugging is a nightmare.

>> When everything is working correctly 'message to nil silently eaten' 
>> is a great convenience.  When something somewhere unexpectedly 
>> returns nil, it becomes an incredibly nasty pain to try and figure 
>> out exactly where the problem might be.   By the time it crops up, 
>> you may be many cycles through the run loop away from where the 
>> problem actually is.
>
> Hmmm...this sounds like you are working too much with mutable state, 
> in which case nils are just one symptom, and doctoring about with this 
> one symptom is just hiding the deeper problems.  If you move away from 
> mutable state, you will also find that you don't have problematic 
> values (of which nil is just one prominent example) causing problems 
> when the cause of the problem (of the problematic value) has long 
> since disappeared from the call-stack.
>
> If you use a more "functional" programming style, pulling values and 
> evaluating expressions when needed instead of pushing values and 
> stashing computed values, you will likely find that you don't get this 
> type of problem-propagation.

No -- that is not the problem.

There is the potential for the problem to arise *anywhere* a method is 
invoked/called/messaged where the developer has not previously 
validated that the target is non-nil.   If, for whatever, reason-- 
misconnection in IB, service mysteriously down, data integrity damage-- 
the target is nil, no error will occur upon method invocation and the 
fact that said object reference was nil will now cause a problem that 
may be considerably separated from the actual source of the problem.

>> Over the last-- jeez, nearly 15 years-- I have seen novice and 
>> experienced developers-- myself included-- waste many many hours 
>> trying to track down a problem that turned out to be an unexpected 
>> nil.   Going with a 'message to nil raises' model may have required 
>> the addition of quite a few extra if () statements here and there 
>> over the years, but that route would have considerably decreased the 
>> frustration factor for quite a large number of developers.
>
> While I don't question your personal experience, I do believe that the 
> problem may lie elsewhere.
>
> Also, I believe very strongly in "intention-revealing" code.  That is, 
> the code should reflect the problem, not the technology.  Things like 
> constant checking of types/nil-values/exceptions typically have 
> nothing to do with the problem domain, and do little but obscure the 
> solution.  I certainly notice that my Java code is a lot more verbose 
> and a lot less maintainable than my Objective-C code.

It would seem that "intention revealing" would mean writing code that 
shows that the developer intended to deal with the fact that something 
could potentially be nil in a valid situation by actually checking for 
it.

     [[[[foo bar] baz] bob] fred];

The above does not reveal the developers intentions in this regard -- 
maybe the developer fully expects -baz and -fred to return nil and 
that's OK -- but -bar and -bob returning nil is something the developer 
never intended to have happen.   If an exception were thrown in such a 
case, the above would change to:

id x;

x = [[foo bar] baz];
if (!x)
     return;
x = [[x bob] fred];
if (!x)
     return;

The above is a few more lines of code, but the developer's intentions 
are exactly revealed.

b.bum

Re: [Pyobjc-dev] Questions

[Ronald O. <ous...@ci...>]

On Sunday, May 11, 2003, at 17:41 Europe/Amsterdam, Gary Robinson wrote:

> Hi,
[...]
> Obviously, I can manually add any new classes to the skeleton and not 
> run
> NibClassBuilder at all. But I have a slight fear that there may be 
> other
> side-effects when NibClassBuilder is called other than creating the
> skeleton, so that if I don't run it, I'll have problems.

Your fear is unnecessary. When NibClassBuilder is used as a script is 
only creates the skeleton, there are no other effects. I don't always 
use NibClassBuilder, but often just create the entire script by hand.

Ronald

Re: [Pyobjc-dev] Calling methods on nil

[Marcel W. <ma...@me...>]

On Sunday, May 11, 2003, at 03:49  Uhr, bb...@ma... wrote:

> On Sunday, May 11, 2003, at 05:46 US/Eastern, Ronald Oussoren wrote:
>> This is the most important reason for not having a 'nil' object that 
>> behaves ignores all method calls. Implementing such an object is easy 
>> enough, but it is too easy to mis actual errors this way. And IIRC 
>> this feature doesn't even work perfectly in Objective-C (what if the 
>> method returns anything other than an 'id', like a 
>> float/double/struct).
>
> Having done ObjC development since 1989 -- 4 or 5 years prior to 
> diving into Python -- you might be surprised to learn that I very 
> strongly prefer the behavior of Python's (and Java's) 'message to nil 
> throws' behavior vs. ObjC's 'message to nil silently eaten'.

Having done ObjC development since 1987, I much prefer the coding 
simplicity the current behavior gives, while I don't recall the 
problems you report being anything but an extremely rare occurrence.

> When everything is working correctly 'message to nil silently eaten' 
> is a great convenience.  When something somewhere unexpectedly returns 
> nil, it becomes an incredibly nasty pain to try and figure out exactly 
> where the problem might be.   By the time it crops up, you may be many 
> cycles through the run loop away from where the problem actually is.

Hmmm...this sounds like you are working too much with mutable state, in 
which case nils are just one symptom, and doctoring about with this one 
symptom is just hiding the deeper problems.  If you move away from 
mutable state, you will also find that you don't have problematic 
values (of which nil is just one prominent example) causing problems 
when the cause of the problem (of the problematic value) has long since 
disappeared from the call-stack.

If you use a more "functional" programming style, pulling values and 
evaluating expressions when needed instead of pushing values and 
stashing computed values, you will likely find that you don't get this 
type of problem-propagation.

> Over the last-- jeez, nearly 15 years-- I have seen novice and 
> experienced developers-- myself included-- waste many many hours 
> trying to track down a problem that turned out to be an unexpected 
> nil.   Going with a 'message to nil raises' model may have required 
> the addition of quite a few extra if () statements here and there over 
> the years, but that route would have considerably decreased the 
> frustration factor for quite a large number of developers.

While I don't question your personal experience, I do believe that the 
problem may lie elsewhere.

Also, I believe very strongly in "intention-revealing" code.  That is, 
the code should reflect the problem, not the technology.  Things like 
constant checking of types/nil-values/exceptions typically have nothing 
to do with the problem domain, and do little but obscure the solution.  
I certainly notice that my Java code is a lot more verbose and a lot 
less maintainable than my Objective-C code.

Marcel

-- 
Marcel Weiher				Metaobject Software Technologies
ma...@me...		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.

Re: [Pyobjc-dev] Calling methods on nil

[Martina O. <Ma...@Oe...>]

Hi Bill -

> When everything is working correctly 'message to nil silently eaten' 
> is a great convenience.  When something somewhere unexpectedly returns 
> nil, it becomes an incredibly nasty pain to try and figure out exactly 
> where the problem might be.   By the time it crops up, you may be many 
> cycles through the run loop away from where the problem actually is.

Agreed.

> In the context of PyObjC, I consider 'message to nil throws' to be a 
> feature (and not just because it is the Python way).

Unfortunately Cocoa uses the "message to nil ignored" pattern without 
documenting it. For example, the AddressBook methods which return 
arrays of people, groups etc. may return nil instead of an NSArray. As 
these details are not mentioned in Apple's documentation, they are a 
trap for PyObjc programmers.

One way to fix this might be to translate Cocoa's nil to Dinu's Null 
class. But this might break existing programs which now compare Cocoa 
return values to None. Also there might be round-trip problems (what 
happens if you stored a Python None in an NSMutableArray. When you 
retrieve it later, will you get None or a Null object?). Probably there 
will be more problems of this kind, similar to what we have seen with 
other conversions in the bridge.

Therefore I prefer the existing behaviour. However, I suggest to 
document it more detailed than now (list known examples of Cocoa 
returning a "to be ignored" nil), and to add explicit tests for nil to 
the example and tests where appropriate.

ciao
Martina

[Pyobjc-dev] Questions

[Gary R. <gro...@tr...>]

Hi,

I've gotten great help so far from this list so I thought I'd continue
asking questions. Thanks!!! Maybe I'll be able to contribute to the
documentation as I come to understand things better.


This question is about the mechanics of working with Information Builder and
PyObjC.

Suppose that I create an Information Builder representation of my app, then
use NibClassBuilder.py to create a skeleton Python. All well and good, but
later in the development process I will almost certainly have reason to add
new classes in Interface Builder. If I run NibClassBuilder.py I'll lose the
Python code I write in the skeleton.

Obviously, I can manually add any new classes to the skeleton and not run
NibClassBuilder at all. But I have a slight fear that there may be other
side-effects when NibClassBuilder is called other than creating the
skeleton, so that if I don't run it, I'll have problems.

So a it would be useful to have "official" suggestions for how to handle
this. 

--Gary

-- 
<http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org>

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454