Re: gdb.objc/objcdecode.exp test error..

Tom Tromey
2009-10-13T00:44:46Z

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

[...]

Joel> I really think that allowing the above shortcut is a mis-feature
Joel> that we should consider removing. We could possibly think about
Joel> introducing another syntax meaning all "create" methods in all
Joel> classes, if it really is needed by ObjC developers.

Joel> Another, more compromising approach, might be to start searching
Joel> ObjC method only when we did not find a symbol with that name.
Joel> In other words, do a pure C/C++ match first, and if nothing found,
Joel> then try objective-C. We could conditionalize that to the current
Joel> language being objective-c, but I have the feeling that this is
Joel> contrary to the spirit of the current code.

I tend to think that the results should depend a bit on the current
language.

If the current language is C, I think we should require full
qualification of the name. So, "break foo" would just find a function
named "foo", but "break x::y" would look at various C++ functions.

However, we could give languages a method that could short-circuit this
search a bit. That way something like "break func" in C++ could
consider the current context and do C++-style name lookup. I think this
would yield a natural result for C++ programmers.

If we did this, then "break create" in C mode would only find the C
function of that name, but the ObjC code would be free to make
"break create" do whatever searching ObjC programmers deem reasonable.

Whether other languages accept all the forms accepted by C is open to
debate. I think C must be a special case because it is the default
language, and we want users to be able to start gdb and set a breakpoint
without an intervening "set language".

What do you think?

Tom