[Pythonmac-SIG] NSTableView and NSOutlineView backgrounds

[Drew McCormack]

> though to make your char-to-char comparison more fair you should to 
> replace the Python "NSOutlineView(self, " with "self." .. I believe 
> Dinu was using it for readability or something but it shouldn't be 
> necessary, even for that, because he named it MyOutlineView.  Besides, 
> your ObjC code won't even compile because the (seemingly useless, 
> inherited from Dinu's Python) path variable isn't declared anywhere.
I guess I left out ' id '. 3 more chars.

>
> Also, don't the newer compilers complain when you declare variables in 
> the middle of code?  Wouldn't you have to put a "NSRect bounds;" at 
> the top of the block?  Obviously you could just do [NSBezierPath 
> fillRect:[self rectOfRow: row]] .. which is probably how I'd have done 
> it in the first place.
No, you can declare a var anywhere, and if you use 'id', it doesn't 
even take up that much room. I do agree that nothing at all is better 
than 'id' though. Obj-C has the advantage that you can use static 
typing if you need it. This can help document the code, if nothing else.

>
>> This leads me to something that I think is better in Obj-C than 
>> python: the smalltalk method naming. I like python a lot, and use it 
>> when I can. It is a concise language, and there are countless modules 
>> available which you can't find in Obj-C. But I find remembering 
>> method signatures, particularly the number or order of arguments, 
>> much more difficult in python than Obj-C. I have to continually go 
>> back to docs to jolt my memory. You don't have that problem in Obj-C, 
>> because you remember the method name, and it tells you what the 
>> arguments are. You often also avoid in-code comments, because the 
>> method calls are self documenting.
>
> Yes, Python methods are typically a lot shorter than ObjC methods, but 
> there's obviously nothing stopping you from naming them like 
> drawRow_clipRect_ :)yp
Sure, and in Obj-C I can do this:
-(void)cryptic:arg1 :arg2 :arg3 {}

[obj cryptic:a :b :c]

It can be just as brief if it needs to be. I find the drawRow_clipRect_ 
a bit of an ugly hack, albeit unavoidable. It's just not pretty ;-)

> Along the same lines, ObjC doesn't have a short way to say anything 
> (no operators).  Probably my favorite feature of Python are strings, 
> lists and dicts, with all the great __setitem__/__getitem__ stuff to 
> go with it.  In ObjC, a+b never means anything useful, unless a and b 
> are primitive C types.. that's obnoxious, because you'd have to say 
> a.add_(b) or something like that... Imagine writing an equation like 
> that.
Well, I have a different view of operator overloading. I think it is 
generally unnecessary, and can even have negative effects. The problem 
is, a lot of people don't know what is happening behind the scenes. If 
you have a matrix expression in C++ like this

a = b * c + d

you are creating two temporary objects. This has lead to the dismal 
performance of C++ in number crunching in the past.
At least in Objective-C, it is explicit:

id temp = [b multByMatrix:c];
id temp2 = [temp addToMatrix:d];
[a assignToMatrix:temp2];

This immediately draws attention to problems, and could lead to 
optimizations, like this:

id temp = [b multByMatrix:c];
a = [temp addToMatrix:d];

I'm not at all convinced by the C++ doctrine that everything must 
behave like a built in type. I think objects are fundamentally 
different, and there is no reason to think they should respond to '+' 
or '*' operators. Methods like 'add' and 'mult' are just as good in my 
mind.

>  Sure, in ObjC you can use int, long, float, double.. but what about 
> equivalents to Python's long or complex?
??
typedef struct _Complex {
	double real, imag;
} Complex;

>   What about doing arrays/matrices (Numeric), etc.  You can't create a 
> NSDictionary like {a:b}.
Python built-in data structures are powerful and concise. Agreed.

> Operators and other syntax is extremely important, more so than a 
> forced message passing syntax.  If you want message passing syntax 
> just use keyword arguments all over the place:
>
> def cryptic(method, with, arguments):
> 	pass
> cryptic(method='foo', with='bar', arguments='baz')
Sure, you can do it, but you don't. It is ugly, and it is not the 
'python way'. In the same way, you can just write Obj-C methods the way 
I demonstrated above, but that is not the 'Obj-C way'.

>
> If Python had any sort of "ordered dictionary" and the kwarg parsing 
> could use it then you would basically have smalltalk style message 
> passing syntax (if you wanted it).  If Python acted like this then I'm 
> sure PyObjC probably would've ended up more like self(drawRow=row, 
> clipRect=rect) then self.drawRow_clipRect_(row, rect).  I find myself 
> wanting the "ordered dictionary" type for all sorts of things, for 
> example in a class declaration, where it could be potentially useful 
> to a metaclass to know the order.
>
> In any case, yes, ObjC isn't that bad.  I like it more than most 
> things, but I prefer Python, primarily for syntax reasons.
Where I prefer python is:
indented form
built in data structures
excess of packages and modules

Where I prefer Obj-C/Cocoa:
Possibility of static typing (makes large programs more readable, and 
catches a few bugs at compile time)
Design of libraries. Cocoa is beautifully designed and stable. I have 
the feeling python's libs have evolved in a less stable way. With each 
new release of python, things get replaced, indicating they weren't 
that well done the first time round.

Drew