Newbie: Generalizing classes

  • Thread starter Thread starter John Spiegel
  • Start date Start date
J

John Spiegel

Hi all,

I'm putting together some generic function classes, a somewhat specific case
I'm working toward is C# code to support ASP.NET pages. But my question is
more general...

I'd like to build a class that handles common functions that pages may want
to use. There may be other options like style sheets, but this is partially
educational as well as intending on having practical use. Let's say I'd
like to be able to have one chunk of code that changes the Text property of
WebControls. If C# weren't strongly typed, I could do something like:

protected void ChangeText( Control, NewText )
{
Control.Text = NewText;
}

Is this possible or am I looking at having a constructor for each class of
control I might want this to support?

protected void ChangeText( Label Control, string NewText )
{
Control.Text = NewText;
}
protected void ChangeText( TableCell Control, string NewText )
{
Control.Text = NewText;
}
....

TIA,

John
 
Hi, I haven't tried this, but isn't it possible just to check if
objObjectToChange is derived (or implements) webcontrols with something like
if (objObjectToChange is WebControl)
objObjectToChange.Text = strNewText;

And maybe you have to put this in try{}catch{}, just in case :)
Sunny
 
Hey Drebin and Sunny,

Thanks for the input. Sunny, in my case, using "is" would help to detect
what it might be, but as far as I can tell from the test I've done, I'm
still having to cast it. It's a shame (for what I'm trying, at least) that
casting can't(?) be handled a bit differently like:

protected void SetText(WebControl oControl)
{
Type MyType = oControl.GetType();
((MyType)oControl).Text = "My Text";

//Instead of
((Label)oControl).Text = "My Text";
}

Oh well. You can't have it all, where would you put it?

- John
 
John Spiegel said:
Thanks for the input. Sunny, in my case, using "is" would help to detect
what it might be, but as far as I can tell from the test I've done, I'm
still having to cast it. It's a shame (for what I'm trying, at least) that
casting can't(?) be handled a bit differently like:

protected void SetText(WebControl oControl)
{
Type MyType = oControl.GetType();
((MyType)oControl).Text = "My Text";

//Instead of
((Label)oControl).Text = "My Text";
}

Oh well. You can't have it all, where would you put it?
Click to expand...

I can't see how casting would help you there - the point of casting is
to actually tell the compiler something useful. In the example you
gave, it wouldn't do that at all, as the compiler doesn't know in
advance what MyType is, so can't know that it's got a Text property.

What you *could* do is use reflection to find a Text property and set
the value of that appropriately, but that's about it.

I sometimes think it's *sort* of a shame that you can't "apply"
interfaces after the event, where casting to the interface would check
that the runtime type implemented all the methods/properties etc that
were needed for the interface. It could do all the work the first time,
remembering in a table associated with the interface that the
particular type could then always be cast appropriately. Just a little
dream - and probably one with *lots* of downsides.
 
Hey Jon,
I can't see how casting would help you there - the point of casting is
to actually tell the compiler something useful. In the example you
gave, it wouldn't do that at all, as the compiler doesn't know in
advance what MyType is, so can't know that it's got a Text property.
Click to expand...

Good point. I hadn't really considered it from the point of view of the
compiler. I was (incorrectly) thinking more from a standpoint if it was
evaluated at run-time, it could make the programmer's life easier in the
sense that as long as he knew anything his code passed in would have a given
property or method. Of course, then the programmer has to get it right and
takes more responsibility that is otherwise the compiler's.

Gee, does it show I've been using a weakly-typed language before now? <g>

- John
 
inline
Jon Skeet said:
I can't see how casting would help you there - the point of casting is
to actually tell the compiler something useful. In the example you
gave, it wouldn't do that at all, as the compiler doesn't know in
advance what MyType is, so can't know that it's got a Text property.

What you *could* do is use reflection to find a Text property and set
the value of that appropriately, but that's about it.

I sometimes think it's *sort* of a shame that you can't "apply"
interfaces after the event, where casting to the interface would check
that the runtime type implemented all the methods/properties etc that
were needed for the interface. It could do all the work the first time,
remembering in a table associated with the interface that the
particular type could then always be cast appropriately. Just a little
dream - and probably one with *lots* of downsides.
Click to expand...

That would be interesting, tho i don't know if a interface would be a proper
concept to use in this case. An interface implies a contract, that it does
provide these methods and hopefully, with the full intent they were created
for, this would simply show that the object has a set of requirements(ie.
the object doesn't gaurentee it does, it doesn't guarentee they even do what
you suspect, it just simply happens to), and i find the concepts to
conflict. Not that that is definatly a reason against having the capacity,
just makes me wary of using the term interface in its current usage.

A simplification of reflection checks would be nice, however, perhaps even
an inline method of checking (object o has method M or whatever, cleaner
syntax for C# i'd hope).

Just something to add up there with runtime managed parameter checking
(attributes specifying a parameter cannot be null, or an integer must fall
within a specific range, instead of writing checking code over and over
again and perhaps allowing a few cases where the compiler warns of an error,
this may be possible using context attributes...havn't tried it, but thats a
pain), constructor specifications, static method specs, and all those other
things.
 
Back
Top