Hi all,
Have any of you used C#? I mean in depth? I just inherited a C#
project at my job and I must say I'm impressed. I had previously
written it off as just Java++.
I bring this up because they have some things that might be nice in
Smalltalk as well.
One of the things I figured out a good use for this weekend is
"extended properties". You can define properties on your own classes
that will show up in the property browser when your class is dropped
onto a form, but what an extended property does is show up in *other
components* property windows. The use case here for me was, I need
any component on my form that implements the "configuration" interface
to get registered with a configuration management class so that I
don't have to hard code which components are persisted. This was not
nearly as easy as it sounds since in C# I can't just modify Component
to send a new e.g. "persist configuration" event.
But with an extended property I just make a ConfigurationManager class
and say that it extends it's property to any class that implements my
config interface. The nice thing about it is, due to how the code is
generated by the RAD, components buried deep in forms can't find out
what component they are contained in inside their own constructors,
but an extended property is applied at the top level form (well,
actually at the location the property extension class is) so the code
looks like (in smalltalk syntax):
TopForm>>initialize
configManager register: someComponent
instead of how a property would normally be applied:
SomeComponent>>initialize
self registerWith: configManager "doesn't work because I can't get a
handle configManager. It's an instance variable in TopForm which I
can't reference until long after this method finishes".
Maybe I am just new to RAD development and RAD's have always been this
way, but the C# environment feels to me like it takes OO design to the
RAD level as well. That is, in this environment I write most of my
code to create components that can have the specific information put
in from the RAD, so that all code I'm responsible for is always
generic. Specifics are always entered in the RAD. The environment
lets me do things like, if I notice that an information grid always
has (1) a fancy title bar, (2) a "view" to connect to a back end
database and (3) a filter, I can create a "control" that consists of
these units, set it up to only display the properties that I want to
expose from these child components and there after only drop this new
component on my forms. Extending reuse to the RAD realm.
Bill, did Dolphin have something like this? I didn't get so far in
it, but I never saw anything like it in my explorations. I'm sure it
could be done with code, but this was build totally graphically
(except setting up properties), and from a business point of view the
biggest concern is keeping the lines code we are responsible for
managing as low as we can. In the best case we would only have
business logic.
Another nice thing that aids in this area is the way the inheritance
is set up: "Component" is the root class for things that show up in
the toolbox (the place you find things to drop on your form) but
components go in a special box under the form (called the component
tray) because they have no visual representation. A "control" is a
subclass of component that does have a graphical display so it can be
placed directly on a form. This lets you hook up "presenter" style
components (i.e. things that have no graphical representation) to
"view" style controls (i.e. things that do) completely in the RAD.
The "not as good":
C# has something they call "design mode" that basically means the code
you write runs inside the IDE to let you fully extend the IDE with
your new components. A consequence of this is when ever you make a
component (or change an existing one) you have to recompile your
project before it shows up anywhere. Another consequence is that if
you have a typo you lock up the whole IDE and you can't set
breakpoints and things without running a separate IDE pointing at your
main one to debug it. In other words, a Smalltalker really feels the
pain of the difference between design time and runtime, but it's
better then nothing.
So what do you all think? I think a system like this in Smalltalk
could be really powerful. We would have to take a different strategy
to implement of course [1] but I think we could make a system with
unprecedented productivity. Or maybe I'm just infatuated with this
new toy. :) But there must be something good here we could learn
from.
Thanks,
Jason
[1] My initial thought here is, a form running "in the wild" gets its
signals from the VM (or whatever), but one that is being designed
would need the designer to stand between it and the normal mechanism
and change how the events are sent a little, or not forward them at
all in some cases. E.g. if you click a button in the application it
does what it is supposed to do, but in the designer clicking a button
would have totally different behavior. C# deals with this situation
by having a property called "DesignMode" that components must check in
functions that need special behavior under the designer, but that
doesn't strike me as very elegant. I like the idea of the design
environment controlling what the form components see so that
components are written without thinking about such issues.
I also hope we can come up with something more sophisticated then the
code generation they have done or the XML generation and run time
loading of it that I understand will be in .Net 3.0. Serializing the
objects the same way they are serialized when one saves the image
would probably work, so long as there is no issue with "resurrecting"
a given object multiple times for different forms. Dolphin did
something to this effect, no?
