On 5-aug-04, at 20:48, Gustavo Niemeyer wrote:
> Hello Ronald,
>
>> I'm in favor of @decorators. It's easy to notice them when the are
>> present and they are clearly special. The '[decorator] def ...' and
>
> Why are they special? Why should they be more important than any other
> part of the function definition?
>
>> 'decorate(decorator) def ...' are very magic, and are IMHO unfriendly
>> to newbies (you must metion them in any introduction to python,
>> because
>> otherwise users would complety mis the signicance of the decorations).
> [...]
>> @objc.signature("v@:@i")
>> def saveSheetDidDismiss_returnCode_contextInfo_(self, sheet,
>> returnCode, contextInfo):
>> pass
>>
>> The argument to objc.signature is fairly magic and I do try to
>> abstract
>> it away (such as with the introduction of objc.accessor), but that's
>> not always possible. If decorators were not allowed to have arguments
>> I'd have to introduce temporary functions that wouldn't help in
>> readability.
>
> Is special syntax in the language really required in this case,
> considering you're already doing something "fairly magic" anyways?
>
> What is objc.signature() doing?
The argument is fairly magic, in that most people wouldn't know how the
interpret it. The function itself is easy enough: it creates a custom
method object. The meta-class for Objective-C classes extracts the
method signature from that method object and uses it build the right
method description on the Objective-C side of the bridge.
A special syntax for descriptors is not stricly necessary, we are after
all already using them with Python 2.2 and Python 2.3 code. It does
make life a lot easier, the method names used in my example are not
particularly long, I sometimes uses much longer names (because I have
to [*]). Having 3 copies of such a name increases the likelyhood of
errors, and makes it harder to spot that all 3 names are the same.
To stretch a point: class syntax is also not necessary, instead of a
class definition you can call type() with the right arguments. Does
that mean we should do away with classes?
>
>> The generic example PJE is introducing in PEAK also seem a good
>> usecase
>> for decorators with arguments.
>
> Any pointers?
>
> I'd really like to "see the light" of complex decorators, as oposed
> to KISS, and use the current language features to implement that.
Whoops, I used the wrong word, I meant 'generic functions' instead of
'generic example'. He's doing something like this:
@when("isinstance(db, OracleDB")
def storeInDB(db, object):
pass
@when("isinstance(db, BerkelyDB")
def storeInDB(db, object):
pass
The 'when' decorator converts the function into a generic function that
uses the expressions to dispatch to the right function implementation
at runtime.
Ronald
[*] "have too" because I haven't found a good way to automaticly
convert Objective-C method names in sensible shorter names. Objective-C
has segmented method names, like smalltalk. This looks a little like
keyword arguments:
@interface MyModel : NSObject
{}
-(int)sheetDidEnd:(NSSheet*)sheet returnCode:(int)code
contextInfo:(void*)context;
@end
This looks like a method with 2 keyword arguments, but really isn't.
The method name is 'sheetDid:returnCode:contextInfo:'. I convert that
to a python identifier by replacing colons by underscores. That's an
easy to remember rule, which means I don't have to replicate the vast
amount of Cocoa documentation, but you do end up with some ungainly
method names.
The only way I see to fix this is to introduce segmented method in
Python, but I don't think that would fly :-) :-)
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