Overview
Features
Download
Documentation
Community
Add-Ons & Services

Type safety for properties?

Please post support and help requests here.

Type safety for properties?

Postby rbock » 01 Jun 2008, 18:22

Hi,

one of the things that let me drop libCurl in horror was the missing type safety. The so-called easy interface provides a function which basically accepts everything during compilation, and then simply crashes during execution when these arguments were not good...

This is why I searched for networking frameworks once more and stumbled over Poco. Great framework! We ended up replacing not only libCurl but also libXML++ and log4cxx.

But: One thing that bugs me is the way to get/set properties of Poco::Configurable objects!

IMHO it would be much better to have specific functions for each property. This way, a lot of mistakes could be detected by the compiler instead of running into an exception.

For example, the line satisfies the compiler but causes an exception at runtime:

fileChannel->setProperty("rotiation", "100");

It would be much harder to do it wrong with a specific property function like this:

void setRotationSizeInBytes(const unsigned int bytes);


Thanks and regards,

Roland
rbock
 
Posts: 7
Joined: 30 May 2008, 14:05
Location: Germany

Re: Type safety for properties?

Postby guenter » 01 Jun 2008, 19:06

The reason for the Configurable class is that we want to be able to configure properties in a generic way in configuration files (see the Poco~058~~058~Util~058~~058~Application samples). I agree that it would be nice to have type-safe setter functions in the various channel implementations. However, the usual way to configure logging is via a configuration file, so we had not much use for these functions. If someone wants to add them, go ahead.
guenter
 
Posts: 1105
Joined: 11 Jul 2006, 16:27
Location: Austria

Re: Type safety for properties?

Postby alex » 01 Jun 2008, 21:46

> For example, the line satisfies the compiler but causes an exception at runtime:

> fileChannel->setProperty("rotiation", "100");

A more robust way to do it would be
Code: Select all

fileChannel->setProperty(FileChannel::PROP_ROTATION, "100");


> It would be much harder to do it wrong with a specific property function like this:

> void setRotationSizeInBytes(const unsigned int bytes);

This could certainly be implemented in addition to existing interface.

Alex
alex
 
Posts: 1086
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: Type safety for properties?

Postby rbock » 02 Jun 2008, 18:21

Hi,

we are using a type-safe configuration framework. Thus, it seems a bit weird to create strings from the numbers in order to set the properties (:wink:)

I'll take a look at comparable code (Günter pointed me to FormattingChannel for reference) and probably provide you with some new methods.

Regards,

Roland
rbock
 
Posts: 7
Joined: 30 May 2008, 14:05
Location: Germany

Re: Re: Type safety for properties?

Postby alex » 02 Jun 2008, 20:32

> we are using a type-safe configuration framework. Thus, it seems a bit weird to create strings from the numbers in order to set the properties (:wink:)

Well, I'm not quite sure what to make of 'type-safe configuration framework' statement. While you are right when you say that in some instances it may be surprising to have a runtime failure, sometimes it is indispensable to be able to load configuration at runtime. And there is no other way to load a number from a configuration file (or get it from command line) than as a string of characters which then must somehow be converted into a number. The conversion obviously may fail - this problem hits in the heart of dynamic/static paradigm difference. I believe that neither is perfect (or, to put it another way, each has it's up and down sides). In medio stat virtus - we try to find a healthy balance.

> I'll take a look at comparable code (Günter pointed me to FormattingChannel for reference) and probably provide you with some new methods.

I'm not sure what Guenter is aiming at, but your proposal for setRotationSizeInBytes(const unsigned int bytes) is fine with me in principle - const is unnecessary, though, and unsigned will likely cause compiler warnings and create a need for casts. Anyway, I would not mind adding a set of functions along that line to the current interface and modify the current implementation to use those. So, setProperty(string, string) would still remain in the interface, it would just be implemented in terms of setRotationSizeInBytes(), setRotationSizeInKBytes(), setRotationSizeInMBytes etc , which would also be available for direct invocation in type-safe scenarios. Or, even better would be something like this:

Code: Select all

enum Unit
{
  BYTES = 1,
  KILOBYTES = 1024,
  MEGABYTES = 1048576,
//...
}

void setRotationSize(int size, Unit unit = BYTES);


Alex
alex
 
Posts: 1086
Joined: 11 Jul 2006, 16:27
Location: United_States


Return to Support

Who is online

Users browsing this forum: Baidu [Spider] and 1 guest