Laurent Sansonetti
lsans****@apple*****
Mon Jun 19 21:25:12 JST 2006
Hi all, I recently had a long discussion with colleagues (that are using PyObjC) about the current messages dispatchers in RubyCocoa. You know that right now you can do: 1/ obj.aaa_bbb_(123, 456) 2/ obj.aaa_bbb(123, 456) 3/ obj.aaa(123, :bbb, 456) 4/ obj.aaa(123, :bbb => 456) # only in the unstable branch One of the problems about 2/ 3/ and 4/ is that they can lead to ambiguities in (very rare) cases [1]. Some people are afraid about this, and would prefer to see only 1/ supported. I did my best to defend the current syntaxes... Hisa-san and I discussed about this and we agreed to: - make 1/ the default message dispatcher - enable 2/, 3/ and 4/ only if a flag is enabled - enable this flag by default in the SF source tree (to keep backward compatibility AND the friendly syntaxes) Apple won't enable the flag by default, will tell people that if they want a more-friendly syntax they can do it, but it's not supported by Apple anymore The flag in question should be discussed. Here are some propositions: OSX.additional_convention OSX.additional_syntax OSX.friendly_syntax ... Please tell us what you think about this! This flag idea looks very simple but if someone comes with a better solution it will be cool. Also please suggest better flag names. Thanks, Laurent PS: Jonathan, I am sorry to not have replied you in the list, I am damn busy right now on other things :/ [1]: Omitting the trailing underscore can lead to confusions, for ex: [MyClass +foo] [MyClass +foo:(id)foo] Calling MyClass.foo() can be ambiguous for the user, which method is he calling? Basing on the given number of arguments is also ambiguous, we could pass an exploded array (*[]) and we would call different methods based on the array value. The symbol/value/symbol/value and the inline hash syntax looks fragile for some people, and can also lead to confusions (people could think that the order of parameters is not important as they are named).
