Aren/haiku
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
56583ffb3a
haiku/headers/private/debugger/value/ValueNode.h

147 lines
4.1 KiB
C
Raw Normal View History

* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 21:15:21 +03:00
/*
Debugger: Cleanups, no functional change. - Remove out-of-place accessor to type lookup info on ValueLoader. Instead, adjust CreateChildren() and CreateChildrenInRange() to take a TeamTypeInformation parameter. This can then be used by value nodes that need to be able to look up type information in order to properly publish their children, such as BList and BMessage. Refactor subclasses and callers accordingly
2015-06-07 20:27:13 +03:00
* Copyright 2015, Rene Gollent, rene@gollent.com.
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 21:15:21 +03:00
* Copyright 2009, Ingo Weinhold, ingo_weinhold@gmx.de.
* Distributed under the terms of the MIT License.
*/
#ifndef VALUE_NODE_H
#define VALUE_NODE_H
#include <String.h>
#include <Referenceable.h>
Debugger: Cleanups, no functional change. - Remove out-of-place accessor to type lookup info on ValueLoader. Instead, adjust CreateChildren() and CreateChildrenInRange() to take a TeamTypeInformation parameter. This can then be used by value nodes that need to be able to look up type information in order to properly publish their children, such as BList and BMessage. Refactor subclasses and callers accordingly
2015-06-07 20:27:13 +03:00
class TeamTypeInformation;
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 21:15:21 +03:00
class Type;
class Value;
class ValueLoader;
class ValueLocation;
class ValueNodeChild;
class ValueNodeContainer;
enum {
VALUE_NODE_UNRESOLVED = 1
};
class ValueNode : public BReferenceable {
public:
ValueNode(ValueNodeChild* nodeChild);
virtual ~ValueNode();
ValueNodeChild* NodeChild() const { return fNodeChild; }
virtual const BString& Name() const;
virtual Type* GetType() const = 0;
virtual status_t ResolvedLocationAndValue(
ValueLoader* valueLoader,
ValueLocation*& _location,
Value*& _value) = 0;
// returns references, a NULL value can be
// returned
// locking required
ValueNodeContainer* Container() const
{ return fContainer; }
void SetContainer(ValueNodeContainer* container);
* Extend ValueNode to be able to indicate that a node needs child creation requests delayed until its location/value have been resolved. Update VariablesView to make use of that flag. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42333 a95241bf-73f2-0310-859d-f6bbb57e9c96
2011-06-28 04:20:32 +04:00
virtual bool ChildCreationNeedsValue() const
{ return false; }
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 21:15:21 +03:00
bool ChildrenCreated() const
{ return fChildrenCreated; }
Extend ValueNode API. - Add several new optional hook functions to ValueNode. These allow implementing subclasses to specify that they're a container type that can export a range of items (i.e. arrays, lists, etc.), and expose several operations on said ranges of child items.
2013-04-20 06:57:55 +04:00
Debugger: Cleanups, no functional change. - Remove out-of-place accessor to type lookup info on ValueLoader. Instead, adjust CreateChildren() and CreateChildrenInRange() to take a TeamTypeInformation parameter. This can then be used by value nodes that need to be able to look up type information in order to properly publish their children, such as BList and BMessage. Refactor subclasses and callers accordingly
2015-06-07 20:27:13 +03:00
virtual status_t CreateChildren(TeamTypeInformation* info) = 0;
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 21:15:21 +03:00
virtual int32 CountChildren() const = 0;
virtual ValueNodeChild* ChildAt(int32 index) const = 0;
Extend ValueNode API. - Add several new optional hook functions to ValueNode. These allow implementing subclasses to specify that they're a container type that can export a range of items (i.e. arrays, lists, etc.), and expose several operations on said ranges of child items.
2013-04-20 06:57:55 +04:00
// optional virtual hooks for container type value nodes such as
// arrays that may contain a variable (and potentially quite large)
// number of children. The calls below should be implemented for such
// node types to allow the upper layers to be aware of this, and to be
// able to request that only a subset of children be created.
virtual bool IsRangedContainer() const;
Extend ValueNode interface for ranged containers. Add an IsContainerRangeFixed() hook which specifies whether or not the container in question can only display elements within a fixed lower/upper bound, i.e. B{Object}List.
2013-05-21 02:18:57 +04:00
virtual bool IsContainerRangeFixed() const;
// indicates that the user can't
// arbitrarily go outside of the
// specified/supported range.
Extend ValueNode API. - Add several new optional hook functions to ValueNode. These allow implementing subclasses to specify that they're a container type that can export a range of items (i.e. arrays, lists, etc.), and expose several operations on said ranges of child items.
2013-04-20 06:57:55 +04:00
virtual void ClearChildren();
Debugger: Cleanups, no functional change. - Remove out-of-place accessor to type lookup info on ValueLoader. Instead, adjust CreateChildren() and CreateChildrenInRange() to take a TeamTypeInformation parameter. This can then be used by value nodes that need to be able to look up type information in order to properly publish their children, such as BList and BMessage. Refactor subclasses and callers accordingly
2015-06-07 20:27:13 +03:00
virtual status_t CreateChildrenInRange(
TeamTypeInformation* info,
int32 lowIndex, int32 highIndex);
Extend ValueNode API. - Add several new optional hook functions to ValueNode. These allow implementing subclasses to specify that they're a container type that can export a range of items (i.e. arrays, lists, etc.), and expose several operations on said ranges of child items.
2013-04-20 06:57:55 +04:00
virtual status_t SupportedChildRange(int32& lowIndex,
int32& highIndex) const;
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 21:15:21 +03:00
status_t LocationAndValueResolutionState() const
{ return fLocationResolutionState; }
void SetLocationAndValue(ValueLocation* location,
Value* value, status_t resolutionState);
ValueLocation* Location() const { return fLocation; }
Value* GetValue() const { return fValue; }
// immutable after SetLocationAndValue()
protected:
ValueNodeContainer* fContainer;
ValueNodeChild* fNodeChild;
ValueLocation* fLocation;
Value* fValue;
status_t fLocationResolutionState;
bool fChildrenCreated;
};
class ValueNodeChild : public BReferenceable {
public:
ValueNodeChild();
virtual ~ValueNodeChild();
virtual const BString& Name() const = 0;
virtual Type* GetType() const = 0;
virtual ValueNode* Parent() const = 0;
virtual bool IsInternal() const;
virtual status_t CreateInternalNode(ValueNode*& _node);
virtual status_t ResolveLocation(ValueLoader* valueLoader,
ValueLocation*& _location) = 0;
// returns a reference
// locking required
ValueNodeContainer* Container() const
{ return fContainer; }
void SetContainer(ValueNodeContainer* container);
ValueNode* Node() const { return fNode; }
void SetNode(ValueNode* node);
status_t LocationResolutionState() const
{ return fLocationResolutionState; }
ValueLocation* Location() const;
// immutable after SetLocation()
void SetLocation(ValueLocation* location,
status_t resolutionState);
protected:
ValueNodeContainer* fContainer;
ValueNode* fNode;
ValueLocation* fLocation;
status_t fLocationResolutionState;
};
class ChildlessValueNode : public ValueNode {
public:
ChildlessValueNode(ValueNodeChild* nodeChild);
Debugger: Cleanups, no functional change. - Remove out-of-place accessor to type lookup info on ValueLoader. Instead, adjust CreateChildren() and CreateChildrenInRange() to take a TeamTypeInformation parameter. This can then be used by value nodes that need to be able to look up type information in order to properly publish their children, such as BList and BMessage. Refactor subclasses and callers accordingly
2015-06-07 20:27:13 +03:00
virtual status_t CreateChildren(TeamTypeInformation* info);
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 21:15:21 +03:00
virtual int32 CountChildren() const;
virtual ValueNodeChild* ChildAt(int32 index) const;
};
#endif // VALUE_NODE_H
Reference in New Issue Copy Permalink