Getting rid of 'case statements'

That should be posted to The Daily WTF

> That should be posted to The Daily WTF

I checked WTF on Google, and I assume it's not the Welcome To Finland
site. :-)

Bruce Samuelson wrote:
>> That should be posted to The Daily WTF
>
>
> I checked WTF on Google, and I assume it's not the Welcome To Finland
> site. :-)

http://www.thedailywtf.com/

The Daily WTF - Curious Perversions in Information Technology.  Weird
and less than wonderful snippets of "unusual" programming techniques.

-=-=-
... C++ is history repeated as tragedy. Java is history repeated as farce.

Bruce Samuelson wrote:

> For your amusement or dismay, here are variations of this design problem
> from a recent project. [...]

Dear God...

Especially:

> 2. Copy/paste redux: 'abc...foo...abc' repeated 25 times.
>
> Those 25 methods, about 2 pages long each, were nearly identical to each
> other.

Words fail me.

    -- chris

Peter van Rooijen <[hidden email]> wrote:
[snip]
>
>Peter

And just to be clear, GemStone's arrays:

#[ 1, 2, object, object message, (object message: object2) ]

Are very similar to Squeak, except for syntax, and don't seem to offer any
performance advantages.  A smarter compiler could at least check to see if
the objects in the arrays are literals, and if so, optimize it.

The compile-time constant ##( expr ) seems to be the one that is in some
implementations that actually can do optimization.

Ian

---
http://www.upright.net/ian/

Wel, I think among the worst is to write a code generator to duplicate the
same method many times, and then just modify each one ever so slighty to
"tweak" it to do something a little different in each case.  :)

Ian

"Chris Uppal" <[hidden email]> wrote:

---
http://www.upright.net/ian/

"Sean M" <[hidden email]> wrote:

Generally, this is closer to the solution I would often choose, but normally
I would put the schemes in a class instance variable or Pool, and have it
initialized only once in the system.  Also, when using this type of pattern
I also deeply frown upon mapping values to method selectors, and instead map
values to blocks, if the need be.

Ian

---
http://www.upright.net/ian/

I think the 25 nearly identical methods I mentioned came about by the
technique that Ian deprecates below. It was a VAST application, and the
methods were generated by Instantiations' Window Builder Pro, later to
be tweaked by developers.

The application also had many examples of duplicate methods that arose
from copy / paste reuse, without assistance from WB Pro. I'll set aside
the question of why this reuse technique is so popular among developers.

Are there ways for GUI builders to generate code that can be gracefully
extended via inheritance?

With VAST, WB Pro creates very long, procedural methods. If a GUI
subclass wants to reuse and extend its parent, what I saw developers
doing was applying the layout tool to the subclass GUI and auto
generating a bunch of methods. Many of these methods duplicated, or
nearly duplicated, the parent's methods. Inheritance was not utilized.

With VW, the GUI builder generates shorter #windowSpec methods that are
declarative rather than procedural, consisting of a hierarchy of literal
arrays and other literals. However, I'm still not aware of a mechanism
for a subclass to extend these methods by inheritance.

VAST/WB Pro and VW can both use composition (e.g., subcanvasses) rather
than inheritance to get reuse, but many developers don't take advantage
of this technique.

Object oriented languages offer so much potential for reuse, and in my
experience, most managers and developers take little advantage of it.

Ian Upright wrote:

Bruce Samuelson wrote:
> With VAST, WB Pro creates very long, procedural methods.

AFAIK, it is largely up to you to decide if and where these methods are
broken up, so you do have control over the length and the
overridability. With WindowBuilder, I have used overriding for 'visual
inheritance' many times, with great results, in VA Smalltalk. And in
Visual Smalltalk before that.

 > If a GUI
> subclass wants to reuse and extend its parent, what I saw developers
> doing was applying the layout tool to the subclass GUI and auto
> generating a bunch of methods. Many of these methods duplicated, or
> nearly duplicated, the parent's methods. Inheritance was not utilized.

They could have factored their methods with WB. May have been a matter
of RTFM.

> With VW, the GUI builder generates shorter #windowSpec methods that are
> declarative rather than procedural, consisting of a hierarchy of literal
> arrays and other literals. However, I'm still not aware of a mechanism
> for a subclass to extend these methods by inheritance.

VWs windowSpecs are a very different animal from the GUI code generated
by WB. I always have the feeling with windowSpecs that the whole
mechanism was devised before the GUI builder existed, and the specs were
intended to be edited manually by lazy programmers who didn't care about
extensibility. Overridability is essentially zero. I am not a great fan
of windowSpecs.

[Probably they were more like a clever hack that someone really smart
built so that you could get GUIs up and running much faster if you were
willing give up some modularity, extensibility, and speed. Maybe someone
who was there way back when can inform us.]

FYI, it is possible, and can be quite enjoyable, to code directly to the
widgets in VW, without using windowSpecs at all. I.e., your code does
the work that the builder does when it interprets a windowSpec. You
don't get support from a GUI-builder then, but you get all the visual
inheritance that you can dream of.

Coding directly to the widgets is much faster than interpreting
windowSpecs, too, giving much snappier GUIs.

> VAST/WB Pro and VW can both use composition (e.g., subcanvasses) rather
> than inheritance to get reuse, but many developers don't take advantage
> of this technique.

That is a completely separate issue. Composition of components
introduces completely different problems (that inheritance avoids).

> Object oriented languages offer so much potential for reuse, and in my
> experience, most managers and developers take little advantage of it.

I don't disagree with that :-).

Cheers,

Peter

Oh don't even get me started on the pitfalls of code generation!  I think
the approach taken by WBPro does exactly what you describe -- it creates
long procedural methods that are hard to reuse.  The implementation and
features are tied highly to the intended implementation of the windows.

Let me just say though, that I think there are some really great things
about WBPro, and it is otherwise quite a great tool.  I first started using
it back in 1995!

Lets try imagine some other windowing frameworks, where the formulation of a
window is merely a template, and then templates can be combined with
behavioral mechanisims and extend other templates.  Or even imagine a world
where these templates can be modified and hundreds of forms simultaneously
updated, and you can edit a form and visually see it along with it's
templates, and in editing the form you could also be potentially editing
several templates at once.  Also, perhaps these forms could be shared to be
used in a GUI client, or on the web, or both.

Or imagine where these templates and even behavior are stored persitently
and declaratively in an object database, and so an end user could manipulate
a template, commit it, and instantly update hundreds of views that used this
template, for everyone in the database.  All without going anywhere within a
100-foot pole of Smalltalk code.

Obviously, a GUI builder that is focusing on code generation is quite a
distance away from all these goals.

I work with systems on a daily basis that do everything I've described and
more, so I'm well aware of the pitfalls and advantages of different
approaches.  However, I've been working with, and developing systems for
many years that follow a very different school of thought -- one where there
is extremely heavy emphasis on keeping all code to a minimum and putting as
much data and non-code behavior in the database as possible.  This goes so
far as being able to construct fairly substantial and sophisticated
applications without any coding at all, and large amounts of the
infrastructure itself, development environment, etc., all implemented in
data and not in code.  But as I said, I'm from a different camp and
paradigm, so perhaps we're a little out there than the rest of the world.
:)

Ian

Bruce Samuelson <[hidden email]> wrote:

---
http://www.upright.net/ian/

Peter van Rooijen <[hidden email]> wrote:

[snip]

>FYI, it is possible, and can be quite enjoyable, to code directly to the
>widgets in VW, without using windowSpecs at all. I.e., your code does
>the work that the builder does when it interprets a windowSpec. You
>don't get support from a GUI-builder then, but you get all the visual
>inheritance that you can dream of.
>
>Coding directly to the widgets is much faster than interpreting
>windowSpecs, too, giving much snappier GUIs.

This may be the case with windowSpecs, but if this sort of idea is done
right (I'm definitely not saying windowSpecs were done right), "interpreting
the data" should be more efficient than generating code.  VM's are usually
optimized to have a cache, and if the primary codebase is quite small, much
of the execution stays within the native instruction cache and within the
CPU cache, and overall performance can be better than that of not
interpeting and leaning towards code generation techniques.

Ian

---
http://www.upright.net/ian/

Peter van Rooijen wrote:

I vaguely recall that one of the driving forces to make windowspecs this
way is that it makes it possible to write a generic editor that can
_visually_ edit windowspecs containing declarations for widgets that are
not in the system and/or the editor does not now about.

The literal array business is just a way to passivate them without
referencing classes directly.



Reinout
-------