Design question

[Klerk]

I have a "device" (abstract class) with some "settings"( not sure if
they should be a bunch of properties or a collection). Settings maybe
readonly or read write. I have a "monitor" that polls the (actual
physical) device periodically to detect changes in settings. These
changes should be reflected in my device instance. Any changes to the
device state should be reflected in the physical device. Should also
be able to add and remove settings at runtime.

The goal is to be able to access these objects on a commandline (by
launching an Ironpython interactive session and loading the assembly)
like so...

print Device1.setting 1
Device1.setting 1 = <some value>
Device1.add(new setting)
Device1.newsett ing = <some value>

If I define all the settings as properties in Device. I have a simple
way of getting and setting their values on the commandline. With tab
completion enabled on the commandline, its a very convenient method of
getting and setting values.
The problem is I dont see how I can add new settings (or remove
settings) without replacing the properties with a collection
(arraylist or hastable). But this would break the simple way to access
info on the command line.
It would change to

print Device1.setting s["setting1"]
Device1.setting s["setting1"] = <value>

The user would have to know what settings are available.

Being new to C#, was wondering if there is some mechanism through
which I could preserve the original way of interacting on the console
and be able to add remove settings???

My second problem:
Device1.setting 1 can be changed by the user OR may change on the
device (due to reasons other than a user making changes)

So I have two ways of changing a setting
OnUserChange
set{
_setting = sendToPhysicalD evice(value)
if(_setting == error)
_setting = null
}
OnChangeInDevic e
_setting = value from poller

So I have a feeling I cant use C# Properties to describe my device
settings, which means again I cant support the kind of console
interaction I want to provide.

Or is there some way I can get this to work? If you have got this far,
thank you for your patience and any advise or suggestions would be
greatly appreciated

[Peter Duniho]

On Wed, 19 Nov 2008 01:47:54 -0800, Klerk <ce*****@gmail. comwrote:

[...]
The problem is I dont see how I can add new settings (or remove
settings) without replacing the properties with a collection
(arraylist or hastable). But this would break the simple way to access
info on the command line.
It would change to

>print Device1.setting s["setting1"]
Device1.settin gs["setting1"] = <value>

The user would have to know what settings are available.

Being new to C#, was wondering if there is some mechanism through
which I could preserve the original way of interacting on the console
and be able to add remove settings???

Not in the current C#, no. The best you can do is write an indexer, that
would allow syntax like this:

Device1["setting1"] = <value>

That's almost as concise as what you want, and not nearly as verbose as
your problematic example, so maybe that would work for you.

C# 4.0 promises better support for dynamically typed languages, in the
form of a "dynamic" type. But I don't think that there will be any sort
of dynanism in the _implementation _. That is, any way for a type to
dynamically add members at run-time (I infer from your question that
Python would allow such a thing, but I don't know Python so that's just an
assumption). So even in C# 4.0, I don't think you'd be able to have a
single type modify itself at run-time with respect to what members it has.

My second problem:
Device1.setting 1 can be changed by the user OR may change on the
device (due to reasons other than a user making changes)

So I have two ways of changing a setting
OnUserChange
set{
_setting = sendToPhysicalD evice(value)
if(_setting == error)
_setting = null
}
OnChangeInDevic e
_setting = value from poller

So I have a feeling I cant use C# Properties to describe my device
settings, which means again I cant support the kind of console
interaction I want to provide.

Well, you certainly could implement a property as you show here. While
it's usually a good idea for fields backing a property to be modified only
from within the property setter, that's not mandatory. You could in fact
treat the property as a sort of cache of the device's value, as you seem
to be getting at here.

Without dynamic member additions, true properties are probably out of the
question for you. But if you implement the design using an indexer,
you'll have basically the same idea, with a virtual getter and setter for
each named "property" (implemented via the indexer's get and set methods),
so the same basic ideas would apply.

Pete