[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] DSF: ExprMetaGetVarInfo
|
On Wednesday, April 27, 2011 18:19:45 Marc Khouzam wrote:
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Vladimir Prus
> > Sent: Wednesday, April 27, 2011 10:06 AM
> > To: CDT General developers list.
> > Subject: [cdt-dev] DSF: ExprMetaGetVarInfo
> >
> >
> > Folks,
> >
> > looking at current code, and I not entirely grasping why
> > there is ExprMetaGetVarInfo
> > class. It appears to be created only in
> > MIVariableManager.queueCommand, when the
> > command is ExprMetaGetVar. The latter, in turn, is only used
> > in MIExpressions.getExpressionData.
> > As soon as queueCommand gives us ExprMetaGetVarInfo, we
> > create ExpressionDMData out of it.
> > Would it not be more direct to have
> > MIVariableManager.queueCommand directly create
> > ExpressionDMData?
>
> The idea was to keep MIVariableManager and MIExpressions
> separated from each other. Each meta varObj command
> has its matching info command, and that is mostly how the
> two classes communicate. It may be that in the case
> you mention it was not strictly necessary, I'm not entirely
> sure. However, I think that it makes the design more
> consistent and flexible.
I am afraid I fail to see what we gain by this design. We had
to add some additional properties, and we ended up adding
them to both ExpressionDMData and ExprMetaGetVarInfo. So,
ExprMetaGetVarInfo does not insulate MIExpressions from changes,
it is just an extra object to modify.
I have similar questions about other meta commands, but given
that say ExprMetaGetValueInfo is just a string, it does not
cause as much problems -- although it seems that eliminating
it would simplify the code as well.
- Volodya
--
Vladimir Prus
Mentor Graphics
+7 (812) 677-68-40
