This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: Changes to allow extensions to operator set
[Where] is a method to handle operator evaluation missing? Otherwize won't
the jumbo switch in evaluate_subexp_standard still need to be modified
as languages add additional operators.
Not so. The language vector already contains
/* Evaluate an expression. */
struct value *(*evaluate_exp) (struct type *, struct expression *,
int *, enum noside);
Ah. Is ada doing anything special with that - something that will bite
later? Looking at the existing languages - they appear to simply be
overriding select operators but nothing more.
In short, you want to object orient these suckers. Well as a matter
of fact, I actually implemented something along these lines in an earlier
iteration. It certainly can be made to work. However,
Yes.
1. To do it consistently requires a much more extensive and somewhat
tedious change to the existing machinery (which works well enough)
giving me even more opportunities to overlook something ("overlook"
== "screw up").
True. Need to look for baby steps.
2. For example, to really do it up brown you'd want to modify all the
.y files so that instead of emitting the integer codes directly, as they
do now, there'd be operator-specific emission routines for parsing, so
that, e.g., sequences like
write_exp_elt_opcode (OP_FUNCALL);
write_exp_elt_longcst ((LONGEST) end_arglist ());
write_exp_elt_opcode (OP_FUNCALL); }
became
OP_FUNCALL->write_exp_longest ((LONGEST) end_arglist ());
or some such thing.
Yes, eventually. In an as yet un-scheduled future round.
3. Personally, I find that this is one of those gray cases where the OOP
style gains little in clarity. That is, we have choice of writing (A) an
enumeration type and a few big functions of the form
<type> <func> (<args>) {
<prologue>
switch (<op>) {
case A:
<A code>
case B:
<B code>
}
}
This, I think, is easier short term.
and of writing (B) LOTS of little functions of the form
<type> <func_X> (<args>) {
<prologue>
<X code>
}
This, I think, is easier long term - it's clear exactly which methods
need to be implemented to make the new object functional - no chasing
after all those switch statements to figure out if/where each needs to
be changed.
It took me some time to understand why the OO style really was better
and how come Java omiting enum's was a good thing.
plus a big dispatch vector (of struct operators, in your case) naming them.
Perhaps I am overinterpreting your suggestion, but I see a lot of effort
for little gain in clarity (maybe <0) in going from the current style (A)
to style (B). In fact, for these reasons, I went so far as to tear up my
original, more bject-oriented version of this extension mechanism and
go back to the mechanism I submitted, as a simpler and more conservative
solution.
sed would quickly create the initial table.
Now if and when David Carlton gets his way and we eventually re-do GDB
in C++, it might be time to revisit this decision, since C++ would
remove the tedious table building and welter of names.
Not if, when. GDB's beeing re-done OO regardless of the C++ schedule.
Can you please move evaluate_exp to the new expresion descriptor (is
anything else missing?); modify:
+ OP_OBJC_NSSTRING,
+
+ /* First extension operator. Individual language modules define
+ extra operators they need as constants with values
+ OP_LANGUAGE_SPECIFIC0 + k, for k >= 0, using a separate
+ enumerated type definition:
+ enum foo_extension_operator {
+ BINOP_MOGRIFY = OP_EXTENDED0,
+ BINOP_FROB,
+ ...
+ }; */
+ OP_EXTENDED0,
+
+ /* Last possible extension operator. Defined simply to specify a
+ minimum range for the representation. */
+ OP_EXTENDED_LAST = 0xff
to provide a an explicit and finite number of extended operators
OP_EXTENDED_0, OP_EXTENDED_1, ... (I'm assuming Ada will contain enum {
OP_ADA_... = OP_EXTENDED_0, ... }); add a note that this is an interum
and it will go away.
Andrew