Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Interfaces of the data value and data module

Sign in to follow this  



As always this entry is mirrored at my other blog.

as promised yesterday today I'll show you the interface to the data value and the data module. In fact, as I stated yesterday, the data value interface is quite small since it only has to identify the type and to provide basic getter and setter functions.

I was thinking about the most flexible way of usage for the interface. Since it is this tidy and tiny, the actual data getter and setter must be simple, too. I finally decided to make usage of strings (Note: ScxmlString is actually a typedef of std::string). The reason is simple: Everyone can handle strings with too much hassle and almost every type of data can be described using a string. An integer is as easy to put into a string as is a float. An array of numbers can be put into a string used a separator.

Furthermore, as I said yesterday, the datamodel itself is 90% linked to the script module (since the script module would be responsible for the expression parsing). This implies that the developer who's implementing the script module interface, would also make sure that the implementations of the different types of data values (integer, strings, floats, even objects) can easily be handled by the script module. This means, that the derived class may include access functions that bypass the get/set functions that make usage of strings. A derived integer class easily can implement a get and set function that makes usage of an integer. The script module only has to determine the data value type and cast the interface accordingly.

Thus, the interface of the data value in its basic form looks like this:

class IDataValue
/** \brief Identifies the type of the data.
* \return a string containing the identifier.
virtual const ScxmlString& type() = 0;

/** \brief Access the data.
* \return a string containing the data value.
virtual const ScxmlString& get() = 0;

/** \brief Set the data.
* \param a string containing the data value.
virtual void set(const ScxmlString& _value ) = 0;

My first draft of the data module interface looks as simple as the interface for the data value. Currently only 3 functions are defined: a function to set data, a function to get data and a function to remove data.

Here it is:

class IDataModule
/** \brief Get data as a string from the data module.
* \return true, if the named date exists within the data module. False, if not.
* \param _name Name of the data to fetch.
* \param _out This variable will store the fetch result.
virtual IDataValue* getData(const ScxmlString &_name) = 0;

/** \brief Set data.
* Data that is set in this way will be set to the data module.
* \return true, if the data could be set; false otherwise.
* \param _name Name of the data. This name must be unique. If the name is not unique, it will replace the data value that has been stored using that name before.
* \param _val Content of the data.
virtual bool setData(const ScxmlString &_name, const IDataValue*_val ) = 0;

/** \brief Remove a data entry.
* The named data will be removed from the data module.
* \return true, if the data could be removed. false otherwise.
* \param _name Name of the data.
virtual bool removeData(const ScxmlString &_name) = 0;

These 3 function would enable the developer to manage a set of data values within the data module. The identifiers (names) must be unique but that's part of the script module (or the implementation that makes usage of the datamodel interface).

Nevertheless, the interface for the data module is not complete. At least, that is my opinion ;) On monday or latest tuesday I'll tell you what is still missing and how that stuff is looking like.

Until then: Have fun,
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!