C# methodologies

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?
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

Jason,

I need to read this more carefully later.  My gut reaction is that it
is a nice idea, but that I would not modify the VM or language over it.
Morphic has used extensions for a long time.  I have *no* objection to
graphical tools that notice and utilize such things.  I draw the line at
things like the Tweak compiler; it makes about as much sense to me as
building Squeak's underscore dependence into the compiler and sources -
an optional editor feature (bug to some) becomes a major headache for
cross-dialect compatibility.

Dolphin was always going to grow something like what I think you have
in mind, but it has yet to materialize.  I have some automated view and
code generation tools, and they have been helpful in various situations.
 Unless there is a huge reason to do otherwise, I recommend writing
productivity tools *in* Smalltalk, not *into* Smalltalk.  That way, one
preserves the concept of an integrated system with a simple language and
ever more advanced tools, all built the same way.

Bill



Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

Hi Bill,

I think you misunderstand me a little.  What I propose (are more
accurately; what I'm toying around with) does not require anymore VM
support then Morphic has now, perhaps not as much (I don't know what,
if anything it has).  And certainly no changes to the language.  What
I was talking about with graphic objects behaving differently
depending off they are designed or not doesn't need extra VM support:
the Graphic designer or RAD system is an application that simply
happens to run widgets inside itself (one could think of it as
emulated and indeed that might be the easiest way to implement it) and
modifies how events appear to the applications running under it.  Once
the applications are "in the wild" they get the events directly from
the "world" or what ever system is in place.

I don't know much about Tweak and I didn't know they had a compiler.
What I have seen is that they use what C# calls attributes to signal
what events a method handles.  If those attributes work the same way
in Smalltalk as they do in C#, then I would expect this to be
potentially less efficient [1] but I would have to see how it actually
works.

So just to re-iterate:  I don't want to change Smalltalk in anyway nor
do any VM hacking.  I'm simply pondering how far one could go with an
application that happens to be for building GUI applications (written
in stock Smalltalk-80 of course).

[1] In C# the [attributes] are just meta data that gets attached to
whatever it references.  To make use of this meta data one would have
to query the entity (e.g. method, class, interface, whatever) to see
what attributes it has.  Because of this they are most useful for
design time.

On Jan 14, 2008 2:48 PM, Bill Schwab <[hidden email]> wrote: _______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

Jason,

I probably did misunderstand you.  Dolphin's ViewComposer does some of
what you describe, but I suspect that Object Arts would be the first to
agree that it could be done better.  It might be interesting to look at
WindowBuilder (if we can find a copy of Smalltalk Express or something
else that has it and then get it to run), Dolphin Community Edition, and
Squeak/Morphic.  I think the correct solution merges a code generator
with a visual editor, the nature of which might change with the views
(e.g. Morphic, wx, etc.).  I have long done the code and view generator
in a "batch" mode to generate GUIs based on various meta data sources.
There is a Dolphin solution that approaches it from the view, IIRC,
generating code to match it.  I should dig around for it and add it to
our list of examples.  Throw anything else you want in with it, stir,
and plan a GUI editor.  Is that closer?  BTW, just because I advocate
against volatile changes to the language, please do not feel like we
have to stick to ST-80.  I would very much like to see Squeak more fully
embrace exception handling, as well as provide shortcuts to avoid the
overhead (such as using #at:ifAbsent: vs. having to catch errors from
#at:). Squeak does it in some places and not others.  If you want to
call that "Smalltalk 95" or so, I'd let you get away with it.  Dolphin
and VW do some related things quite wel, and IMHO, Squeak should "learn"
from them.

More in a bit - gotta run.

Bill



Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

On Jan 14, 2008 9:23 PM, Bill Schwab <[hidden email]> wrote:
> Jason,
>
> I probably did misunderstand you.  Dolphin's ViewComposer does some of
> what you describe, but I suspect that Object Arts would be the first to
> agree that it could be done better.  It might be interesting to look at
> WindowBuilder (if we can find a copy of Smalltalk Express or something
> else that has it and then get it to run), Dolphin Community Edition, and
> Squeak/Morphic.

I'm still go looking for documentation on Morphic from time to time to
try to figure out what the advantage is.  So far my impression is that
it was a good idea from Self that just doesn't translate well to
Smalltalk.  And it sounds like the API is terrible.

>  I think the correct solution merges a code generator
> with a visual editor, the nature of which might change with the views
> (e.g. Morphic, wx, etc.).  I have long done the code and view generator
> in a "batch" mode to generate GUIs based on various meta data sources.

At this point I'm not so big on generating views from "batch" mode,
but the system I envision would be in pure Smalltalk so it wouldn't
know or differentiate between receiving messages from code or from a
designer application.  I certainly wouldn't go out of my way to stop
people from doing something they want to do.

> There is a Dolphin solution that approaches it from the view, IIRC,
> generating code to match it.  I should dig around for it and add it to
> our list of examples.  Throw anything else you want in with it, stir,
> and plan a GUI editor.  Is that closer?

Well, that's probably further then I had thought about at this point.
I just noticed the C# ability to let one go very far in application
development purely in the visual builder and think that would be nice
to have in Smalltalk.

Of course there are times one needs extreme flexibility in building a
system but the vast majority of applications don't require nearly that
much work.  When I look at the free software world around us one thing
that sticks out to me is that these guys who do this in their precious
spare time are writing their graphical applications in C (!!!).  Why
is that?  Why wouldn't one use Smalltalk to slap together a GUI in a
day?

I want to change that.  I want to make a graphical building system
that lets one build GUIs so fast that nearly everything in use on
Linux could be duplicated in such a short time that the productivity
can't be ignored.  The Smalltalk and Lisp communities always talk
about how much more productive we are (and I believe that), but we're
not showing it.

>BTW, just because I advocate
> against volatile changes to the language, please do not feel like we
> have to stick to ST-80.  I would very much like to see Squeak more fully
> embrace exception handling, as well as provide shortcuts to avoid the
> overhead (such as using #at:ifAbsent: vs. having to catch errors from
> #at:).

I really like #ifAbsent: and use that pattern in my own code.

By "stock ST-80" I just meant not adding any language extensions.  The
libraries need to always be advancing.  For example, Smalltalk has
resumable exceptions.  Having known about them from Lisp I thought
that was good that they have them.  But when one looks at how they
look when used it leads to some pretty ugly hard to understand code.
One thing I would like to explore at some point is adding Lisp-style
restarts to Smalltalk so this would not only look better but be (imo)
state of the art.

> Squeak does it in some places and not others.  If you want to
> call that "Smalltalk 95" or so, I'd let you get away with it.  Dolphin
> and VW do some related things quite wel, and IMHO, Squeak should "learn"
> from them.

Agreed.
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

Jason,

Morphic's API certainly leaves room for improvement.  My main interest
in it is that it works and can get us to whatever we decide to do next.
Given that, it seems reasonable to consider it as one of our view
hierarchies of interest.

The more you describe what you want to do, the more I think about
WindowBuilder.  I appears to be alive and well via Instantiations and
VA, but it should also live in Smalltalk Express.  If we can get that to
run, you will quickly get an idea of what it can do.  The following
might work (subject to AV checks, etc.):

   http://www.smalltalk.org/versions/SmalltalkExpress.html

The patches probably refer to some changes to get it to run on "high"
color depth video systems (aka, almost anything in use now<g>).


The "other" Dolphin-based generator I mentioned can be found here:

   http://www.cjd77.com/smalltalk/PresenterGenTool.htm


I share your surprise at the way the rest of the world writes software.
I could draw political analogies for it, but suffice it to say that I
doubt the situation will change much.  All of us found Smalltalk, and
others will too, provided dialects continue to exist and remain viable.

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> [hidden email] 01/15/08 1:11 PM >>>
On Jan 14, 2008 9:23 PM, Bill Schwab <[hidden email]> wrote:
> Jason,
>
> I probably did misunderstand you.  Dolphin's ViewComposer does some of
> what you describe, but I suspect that Object Arts would be the first
to
> agree that it could be done better.  It might be interesting to look
at
> WindowBuilder (if we can find a copy of Smalltalk Express or something
> else that has it and then get it to run), Dolphin Community Edition,
and
> Squeak/Morphic.

I'm still go looking for documentation on Morphic from time to time to
try to figure out what the advantage is.  So far my impression is that
it was a good idea from Self that just doesn't translate well to
Smalltalk.  And it sounds like the API is terrible.

>  I think the correct solution merges a code generator
> with a visual editor, the nature of which might change with the views
> (e.g. Morphic, wx, etc.).  I have long done the code and view
generator
> in a "batch" mode to generate GUIs based on various meta data sources.

At this point I'm not so big on generating views from "batch" mode,
but the system I envision would be in pure Smalltalk so it wouldn't
know or differentiate between receiving messages from code or from a
designer application.  I certainly wouldn't go out of my way to stop
people from doing something they want to do.

> There is a Dolphin solution that approaches it from the view, IIRC,
> generating code to match it.  I should dig around for it and add it to
> our list of examples.  Throw anything else you want in with it, stir,
> and plan a GUI editor.  Is that closer?

Well, that's probably further then I had thought about at this point.
I just noticed the C# ability to let one go very far in application
development purely in the visual builder and think that would be nice
to have in Smalltalk.

Of course there are times one needs extreme flexibility in building a
system but the vast majority of applications don't require nearly that
much work.  When I look at the free software world around us one thing
that sticks out to me is that these guys who do this in their precious
spare time are writing their graphical applications in C (!!!).  Why
is that?  Why wouldn't one use Smalltalk to slap together a GUI in a
day?

I want to change that.  I want to make a graphical building system
that lets one build GUIs so fast that nearly everything in use on
Linux could be duplicated in such a short time that the productivity
can't be ignored.  The Smalltalk and Lisp communities always talk
about how much more productive we are (and I believe that), but we're
not showing it.

>BTW, just because I advocate
> against volatile changes to the language, please do not feel like we
> have to stick to ST-80.  I would very much like to see Squeak more
fully
> embrace exception handling, as well as provide shortcuts to avoid the
> overhead (such as using #at:ifAbsent: vs. having to catch errors from
> #at:).

I really like #ifAbsent: and use that pattern in my own code.

By "stock ST-80" I just meant not adding any language extensions.  The
libraries need to always be advancing.  For example, Smalltalk has
resumable exceptions.  Having known about them from Lisp I thought
that was good that they have them.  But when one looks at how they
look when used it leads to some pretty ugly hard to understand code.
One thing I would like to explore at some point is adding Lisp-style
restarts to Smalltalk so this would not only look better but be (imo)
state of the art.

> Squeak does it in some places and not others.  If you want to
> call that "Smalltalk 95" or so, I'd let you get away with it.  Dolphin
> and VW do some related things quite wel, and IMHO, Squeak should
"learn"
> from them.

Agreed.
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

On Jan 16, 2008 11:32 AM, Bill Schwab <[hidden email]> wrote:
> Jason,
>
> Morphic's API certainly leaves room for improvement.  My main interest
> in it is that it works and can get us to whatever we decide to do next.
> Given that, it seems reasonable to consider it as one of our view
> hierarchies of interest.

Ah, I'm just talking about a "pie in the sky" here.  Of course I would
leave everything in place as we talked before as we slowly build up.
This pondering is just what a final state could be like, or what a
"killer app" could be.

Ok, I'll take a look.

> I share your surprise at the way the rest of the world writes software.
> I could draw political analogies for it, but suffice it to say that I
> doubt the situation will change much.  All of us found Smalltalk, and
> others will too, provided dialects continue to exist and remain viable.
>
> Bill

Well, I understand companies.  And it's not that the people wasting
their free time to make a simple GUI app in C surprise me.  It just
strikes me as a place higher level languages like Smalltalk can add
major value.  What we have now would be an improvement but I want to
make the gap so wide as to be uncomparable. :)
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui