> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4