Ronald Oussoren wrote:
>> In fact, if you are right that
>> there is now some kind of translation table that could make PyObjC
>> method names even better, that would be really brilliant.
>
>I was too optimistic about that, looking at the section about methods
in the Swift book (page 339 and onwards) Swift by default treats the
second and later arguments of a method as function parameters with
“external names” (see page 221 for a definition of that), which similar
to required keyword parameters in Python 3, that is:
>
> func splitBy(separator: String, maxCount: Int) -> Array { …}
>
>as a method on a String-like class is more or less similar to the
following Python definition:
>
> def splitBy(separator, *, maxCount): …
>
>And that cleanly translates into:
>
> -(NSArray) splitBySeparator:(NSString*)separator
maxCount:(NSInteger)maxCount;
Yep, it's not runtime translation, its syntactic swizzling being done in
the parser. MacRuby did [1] the same thing IIRC, allowing Ruby users to
write methods using familiar Ruby method name + keyword args syntax, but
obviously what looked like the method's name was only part of it and the
'keyword' args were 100% positional and order-sensitive: the parser just
stripped out the 'keywords' and reassembled the real ObjC signature.
It also meant, of course, that you could safely have several methods
with identical-looking 'names' in the same class, even though Ruby
doesn't support method overloading, because they weren't really
identical names at all and therefore didn't actually mask each other.
That alone should rule out a translation table approach, since Python
would only give you the last splitBy(...) method in your class; every
other splitBy(...) would be masked by it, regardless of what their
selector names are.
Whether you could dive into Python's lexer/tokenizer/parser/AST and do
the same sort of swizzling as MR there, I don't know.
And I really wouldn't like to say if it'd be a wise choice or not: the
current syntax is ugly, but you can throw rocks at it and it's still
guaranteed to work, whereas once you start mucking with something as
complex and knotty as Python syntax, who knows what you might step on?
HTH
has
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
