Board index » delphi » TechTips: How to avoid "write-only code"

TechTips: How to avoid "write-only code"

Ever tried to maintain somebody else's programming?  First you spend a
lot of time trying to "understand" it.  Then you try to figure out how
to snip out the one thread of malfunctioning logic to insert the new
patch without unravelling the whole thing.  The experience of doing this
can teach you a lot about how to avoid writing "write only code" of your
own.

(1) A THREE-LAYER CAKE:
The top layer of your program is the user-interface:  the world as the
user sees it, oriented toward the purposes the user wishes to be done.
The bottom layer is the physical interface...  the code that talks to
DOS or to BDE or your database-engine or whatever.  (And no, I don't
mean "middleware."  I'm talking about code that _you write.)  The middle
layer is the abstract business-logic layer, where the real "meat and
potatoes work" of the application is expressed, as much as possible, in
business terms...  that is, not in terms of the user-interface and not
in terms of the database model.

(2) WRITE "WHAT, NOT HOW":
Suppose that a two-byte value at location $4E-$4F in a disk record is
"number of employees."  Lots of programmers would write something very
"C-like," such as:
        N := (pWord)( (pChar(recPtr)[$4F]) );
That statement does indeed tell the compiler exactly what the computer
is to do...  how the computer should go about retrieving those two
bytes.  But it does not say one single thing about =what the program is
trying to accomplish.=  That statement is totally dependent upon the
representation chosen "right now."  And if a typo were accidentally
introduced into the statement -- as, in fact, one (intentionally) was --
then neither you nor the compiler would catch it at first glance.

{ n.b. the above for the sake of example.. obviously we could use a
"record" type and so-on. }

(3) TRY TO WRITE "DEPENDENT" CODE ONLY ONCE:
Try to have only one part of your program that really has to care how
something is physically done or represented; only one part that really
cares what button the user pushes to request a change.  This creates
"only one place in the program" that must be debugged if a flaw is found
in that area.

(4) CODE LIKE AN ONION:
The closer you get to the core of the onion, the more "dependent" you
are.  These layers are wrapped by other layers with greater levels of
abstraction ... away from the bottom of the cake and toward the middle.

{ Unfortunately Delphi doesn't make it terribly easy to code this way...
the closest they came was the idea of a "data model," which rather died
on the vine. }

(5) "SPELL IT OUT, DAMMIT - THAT'S WHAT FINGERS ARE FOR!"  ;-)
{no no, not =that= finger ... ;-) ;-) .. ahem}  
Code gets very tiring to read when the programmer who originally typed
the code into the computer was trying to economize on keystrokes.
Variable names need to be descriptive.  Comments need to be inserted
-as- you write the code and kept up to date.  You forget sooner than you
think!

(6) FIND AND STUDY "THE ELEMENTS OF PROGRAMMING STYLE":  Kernighan and
Plauger.  (Kernighan was one of the original authors of Unix.)  Like its
namesake "The Elements of Style," this book is slender and an easy read
but packed with information.  Even if you get the original edition which
was based on FORTRAN, you get the idea quickly.

----------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:i...@sundialservices.com  (PGP public key available.)

Quote
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R):  Release 4.0 is here!!
> http://www.sundialservices.com/products/chimneysweep

 

Re:TechTips: How to avoid "write-only code"


"Sundial Services" <info_...@sundialservices.com> skrev i melding
news:3CC8835B.932@sundialservices.com...

Quote
> Ever tried to maintain somebody else's programming?  First you spend a
> lot of time trying to "understand" it.  Then you try to figure out how
> to snip out the one thread of malfunctioning logic to insert the new
> patch without unravelling the whole thing.  The experience of doing this
> can teach you a lot about how to avoid writing "write only code" of your
> own.

> (1) A THREE-LAYER CAKE:

A very good short form of "How to write sound code" ! As usual, I feel the
urge to add something:

"Why is it that even experienced programmers have to rewrite large parts of
applications for the sake of minor changes all the time ?" ("All the time"
is not meant literally)
Because they do that on a regular basis, no matter how clever they are or
pretend to be....;-)
This is (IMHO, of course) an interesting question as it a) seems to be an
indication of poorly written code, and b) is interesting as one tries to
develop  the perfect programming style.

My answer is something like: Whenever you code, you have sorted out the main
goals, and in the process of finishing the code you move away from the main
issues until you reach the "limit" of your task. An event handler like an
OnClick() is an example of this: you have now left the structured part of
the code and start filling out details. These last lines of code is
frequently buggy, messy and is the first code to be rewritten upon a
modification of functionality. An example from today's work:
Task: create a DataSet - formatting routine, where field order, display
label, visibility, width, etc., is controlled from repository tables. This
code is typically centered around the routine that takes a dataset as a
parameter, and this is where I started. The routine will be modified a few
times - until it covers the application's needs. When I started implementing
this new routine into the application, the first places to do it were the
"standard" routines. Now I've covered some 90% of all dataset formatting.
Still controllable and kept in a generalized form. There are however,
allways cases where the routine won't do the job. What I do then, is I
create a few routines to handle the special cases. This code is neither
beautiful or generally useful. But it will exist in *any* application.

What will normally happen within a few months, is I rewrite this stuff
because my thoughts have matured and a model that covers a much wider area
is made possible. These "iterations" are IMHO the core of programming.
Experience, experience, experience. And patience. And not loosing ones
energy just because one has to rewrite what was seemingly perfect half a
year ago.

Sundial described the ideals and the classical pitfalls, my concern here was
that even good programmers can't and shouldn't attempt to write code that
meets any new needs. This just takes too much time. What you don't know, you
don't know - but soon you *will* know. Each time you get a better feeling
for what may be written with your left hand, and what should be nicely
structured.

Regards,
--
Bj?rge S?ther
bjorge@hahaha_itte.no

Re:TechTips: How to avoid "write-only code"


Quote
Sundial Services wrote in message <3CC8835B....@sundialservices.com>...

[...]

Quote
>(1) A THREE-LAYER CAKE:
>The top layer of your program is the user-interface:  the world as the
>user sees it, oriented toward the purposes the user wishes to be done.
>The bottom layer is the physical interface...  the code that talks to
>DOS or to BDE or your database-engine or whatever.  (And no, I don't
>mean "middleware."  I'm talking about code that _you write.)  The middle
>layer is the abstract business-logic layer, where the real "meat and
>potatoes work" of the application is expressed, as much as possible, in
>business terms...  that is, not in terms of the user-interface and not
>in terms of the database model.

Congratulations on a job well done. I feel less need to
_add_ substance to this than Bj?rge, although I do agree
with his cyclic, prototyping model of design/development.

It does call up two observations. First, that the trinity
of user interface, business logic, and storage/physical
interface seems very, very similar between the levels of a
single program and a distributed system involving said
middle-ware. Is there a fractal at work here?

The second is that business logic and physical interface/
database model/storage could well be termed data structures
and algorithms. I have been wondering for several months
now (prompted by development in XSLT) exactly how far the
DS&A model is from the reality of programming. The first
thing that occurred to me was that it didn't mention user
interfaces, but after that I was a bit stuck. I had an
intuitive feeling that user interface, algorithms, and data
structures are still not enough to make up _any_ program.
Perhaps they are after all. I was thinking in the direction
of design methodology, but my experience with formal design
methods is too limited, and my abilities too obviously
unhampered by that, that design should be included in the
visible parts of a program.

Groetjes,
Maarten Wiltink

Re:TechTips: How to avoid "write-only code"


"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding
news:aabb49$mt7$1@news1.xs4all.nl...

Quote
> Sundial Services wrote in message <3CC8835B....@sundialservices.com>...
> [...]
> >(1) A THREE-LAYER CAKE:
> >The top layer of your program is the user-interface:  the world as the
> >user sees it, oriented toward the purposes the user wishes to be done.
> >The bottom layer is the physical interface...  the code that talks to
> >DOS or to BDE or your database-engine or whatever.  (And no, I don't
> >mean "middleware."  I'm talking about code that _you write.)  The middle
> >layer is the abstract business-logic layer, where the real "meat and
> >potatoes work" of the application is expressed, as much as possible, in
> >business terms...  that is, not in terms of the user-interface and not
> >in terms of the database model.

> Congratulations on a job well done. I feel less need to
> _add_ substance to this than Bj?rge, although I do agree
> with his cyclic, prototyping model of design/development.

> It does call up two observations. First, that the trinity
> of user interface, business logic, and storage/physical
> interface seems very, very similar between the levels of a
> single program and a distributed system involving said
> middle-ware. Is there a fractal at work here?

I believe so. But - the reason is that Sundial has borrowed terms used for
both standalone applications and for distributed systems. The aim of the
models here have been to make the actual backend implementation transparent
to the UI, for one. I think it's more a "wishful" statement than anything
else. The UI -> Business Logic -> Storage model is neat but unfortunately
not too well suited for practical implementations. Controls contain a *lot*
of business logic, and so does a database model. One may actually state that
these two layers actually constitute the framework of the business model.
The physical storage delivers premises to the UI, just think of the
difference between a cursor-based table and a single-file storage where you
typically have all data loaded in memory, not to mention when data is
handled by an application server and transported via Web (fragile
connections). You *may* write an application who works transparently with
all these storage mechanisms, but then the third, complex layer would be
handling "persistence behaviour" througout the application rather than
business logic.

I once started developing a set of terms that I thought would be fruitful
when writing applications, and I still feel this may be a way to improve
architecture:

- 'Selector': An object that sets a value or state of interest to other
objects. The Selector may be controlled by a regular UI control, or it may
be controlled in code. Example: "User Selector" (may be controlled once and
for all at login, by picking user name from a list or by a Business Object
field).

- 'Module': A separatable part of an application that will have a limited
amount of necessary interaction with the rest of the application. Example:
"Setup Module", "Report Module"

- 'Editor': An object whose job is to display or edit an object's fields.
May be  multi-dimensional, but will allways have a single object or a
collection as an input parmeter. Most forms are in fact 'editors', and
should be written as such.

- 'Action': See TActionList / TAction.

..and, within data models, the different datasets should be divided into
groups:

- 'System data': Data describing the system. It rarely changes, and needs
only being loaded once per run.
- 'Registers': Like Zip codes, different kinds of libraries ('Employees' may
or may not be placed here).
- 'Business data': What most of the "real work" is centered around.
Concurrency issues & transactions are concerns here.

..another distinction, at dataset level:
- 'Structure data': ID's, Foreign keys, etc. that describe the structure of
the data.
- 'Info' : Data who is not processed or subject to validation.
- 'Business data': that controls the "outcome" of the application.

Quote
> The second is that business logic and physical interface/
> database model/storage could well be termed data structures
> and algorithms. I have been wondering for several months
> now (prompted by development in XSLT) exactly how far the
> DS&A model is from the reality of programming. The first
> thing that occurred to me was that it didn't mention user
> interfaces, but after that I was a bit stuck. I had an
> intuitive feeling that user interface, algorithms, and data
> structures are still not enough to make up _any_ program.
> Perhaps they are after all. I was thinking in the direction
> of design methodology, but my experience with formal design
> methods is too limited, and my abilities too obviously
> unhampered by that, that design should be included in the
> visible parts of a program.

IMHO, we use established distinctions because we need to start somewhere,
and we certainly need terms for what we're modelling. There are two extremes
of 'impedance mismatch' that we struggle with: Where the real world actually
cries for a totally different model e.g. than VCL library, and the other one
where we fail to see how the real world should be "mapped" into a straight,
covering model. The last problem can be overcome by experience and education
in established computer theory, while the first one is more serious. There
are IMHO useful applications that are never built because of this problem.
The Relational Database is to blame for much of this. It reduces all kinds
of problems down to two dimensions (Row / Column) thus making some
applications practically unmakeable. The emphasis on consistency and
security make us spend days and months creating applications that the users
struggle to satisfy rather than helping the user being efficient. If you
don't understand why I state RDBMS'es are the sinner, it's the fact that SQL
doesn't allow database object's names (tables, fields) to be varable, so in
practice, RDBMS model needs to be static.

XML is a good example of what I've been talking about here: Its popularity
is based mainly on the shortcomings of the Relational Database:
- Easy transport of selected data
- Variable & more flexible structure
- Less ned for installing monsters like Oracle servers
...but we recognize the "RDBMS heritage": Rules, rules, rules...;-)
Another question is how interesting the format itself is ? While XML is
self-describing when a DTD is supplied, it doesn't help making applications.
You may use an XML browser that establish the correct structure and enforce
all rules described by the DTD, but it is still relatively useless to a
user.

well, that was too much allready. sorry...;-]
--
Bj?rge S?ther
bjorge@hahaha_itte.no

Re:TechTips: How to avoid "write-only code"


Quote
Bj?rge S?ther wrote in message

<0Bdy8.6438$2E.189...@news2.ulv.nextra.no>...

Quote
>"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding
>news:aabb49$mt7$1@news1.xs4all.nl...
>> Sundial Services wrote in message <3CC8835B....@sundialservices.com>...
>          ... You *may* write an application who works transparently with
>all these storage mechanisms, ...

Speaking of which - did anything ever come of your project
to build a system which could work over both a Web and a
Windows interface?

Quote
>I once started developing a set of terms that I thought would be fruitful
>when writing applications, and I still feel this may be a way to improve
>architecture:

>- 'Selector': An object that sets a value or state of interest to other
>objects. The Selector may be controlled by a regular UI control, or it may
>be controlled in code. Example: "User Selector" (may be controlled once
and
>for all at login, by picking user name from a list or by a Business Object
>field).

Like a property editor?

Quote
>- 'Module': A separatable part of an application that will have a limited
>amount of necessary interaction with the rest of the application. Example:
>"Setup Module", "Report Module"

>- 'Editor': An object whose job is to display or edit an object's fields.
>May be  multi-dimensional, but will allways have a single object or a
>collection as an input parmeter. Most forms are in fact 'editors', and
>should be written as such.

>- 'Action': See TActionList / TAction.

I'm handicapped here by still working with D3, which didn't
have ActionLists.

Nevertheless, I worked out the concept myself from customising
Word (6). The basic entity is a "command" at the application
level, and menus, toolbars, and shortcut keys are just "activators"
for things like "FileSaveAs" and "ToggleReadOnly". Looking at it
like this makes it vastly easier to keep menu options and toolbuttons
synchronised to program state, because you are not tempted to try
and do this from the event handler itself. Instead, all "activators"
(term coined right here and now) register themselves with the basic
command, and are synchronised from there.

I implemented this in one of my applications (which I've mentioned
before), even though I achieved the dynamic-registering part only
for plug-ins; synchronising the fixed UI elements was hard-coded.

There are of course problems because UI elements should really sync
to program state, not actions/commands. The activators linked to
plug-ins were _all_ updated on _every_ action; this will obviously
scale very badly.

Quote
>..and, within data models, the different datasets should be divided into
>groups:

>- 'System data': Data describing the system. It rarely changes, and needs
>only being loaded once per run.
>- 'Registers': Like Zip codes, different kinds of libraries ('Employees'
may
>or may not be placed here).
>- 'Business data': What most of the "real work" is centered around.
>Concurrency issues & transactions are concerns here.

These latter two sound like static and dynamic data, with static
data being more in the background and dynamic data being under
your control and the basis for "production".

Quote
>..another distinction, at dataset level:
>- 'Structure data': ID's, Foreign keys, etc. that describe the structure
of
>the data.
>- 'Info' : Data who is not processed or subject to validation.
>- 'Business data': that controls the "outcome" of the application.

[...]

[SQL]

Quote
>doesn't allow database object's names (tables, fields) to be varable, so
in
>practice, RDBMS model needs to be static.

You can hardly blame SQL for that. Models need to be static, because
if they aren't, you couldn't write an application against them.

<XML is no better>

That's what I mean. It _can't_ be any better, even if it makes some
things easier (and I think all the advantages of XML can be had with
network databases, and those map to relational databases, therefore XML
does, too), because applications are _implementations_ of semantics.
They can't look at a database schema, or a DTD, and think about what
it means. In fact, even with descriptive names and other hinting and
prejudices, humans have a hard time doing that.

Groetjes,
Maarten Wiltink

Re:TechTips: How to avoid "write-only code"


"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding
news:aagl6a$4tm$1@news1.xs4all.nl...

Quote
> Bj?rge S?ther wrote in message
> <0Bdy8.6438$2E.189...@news2.ulv.nextra.no>...
> >"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding
> >news:aabb49$mt7$1@news1.xs4all.nl...
> >> Sundial Services wrote in message <3CC8835B....@sundialservices.com>...

> >          ... You *may* write an application who works transparently with
> >all these storage mechanisms, ...

> Speaking of which - did anything ever come of your project
> to build a system which could work over both a Web and a
> Windows interface?

I haven't had much time to do this yet, but it will soon be...;-)

Quote
> >I once started developing a set of terms that I thought would be fruitful
> >when writing applications, and I still feel this may be a way to improve
> >architecture:

> >- 'Selector': An object that sets a value or state of interest to other
> >objects. The Selector may be controlled by a regular UI control, or it
may
> >be controlled in code. Example: "User Selector" (may be controlled once
> and
> >for all at login, by picking user name from a list or by a Business
Object
> >field).

> Like a property editor?

Yes, that, too. But I do rather think of an object that keeps a state or
selected value even when no business objects are loaded. Much like a global
variable, but with notification functionality and an interface for being
controlled by a Propert Editor.

Quote
> >- 'Module': A separatable part of an application that will have a limited
> >amount of necessary interaction with the rest of the application.
Example:
> >"Setup Module", "Report Module"

> >- 'Editor': An object whose job is to display or edit an object's fields.
> >May be  multi-dimensional, but will allways have a single object or a
> >collection as an input parmeter. Most forms are in fact 'editors', and
> >should be written as such.

> >- 'Action': See TActionList / TAction.

> I'm handicapped here by still working with D3, which didn't
> have ActionLists.

Action lists are a *small* step in the right direction - it establish a
solution for the action handlers (buttons, menus, dblclicking lines, etc.)
as well as common captions & glyphs. If it had some kind of "central"
handling all action objects for the application, it would be great. Then you
could actually easily get both a concistent use of command shortcuts,
captions & get a list for all available shortcuts, it could be linked with
help systems, etc.., not to mention how beautiful it would be for
multilingual support.

Quote
> Nevertheless, I worked out the concept myself from customising
> Word (6). The basic entity is a "command" at the application
> level, and menus, toolbars, and shortcut keys are just "activators"
> for things like "FileSaveAs" and "ToggleReadOnly". Looking at it
> like this makes it vastly easier to keep menu options and toolbuttons
> synchronised to program state, because you are not tempted to try
> and do this from the event handler itself. Instead, all "activators"
> (term coined right here and now) register themselves with the basic
> command, and are synchronised from there.

> I implemented this in one of my applications (which I've mentioned
> before), even though I achieved the dynamic-registering part only
> for plug-ins; synchronising the fixed UI elements was hard-coded.

This is very much similar to TActionList. I've also done somethig like this
in a dataanalysis system, where actions are stored in the database with
command name, parameters, etc., and the whole process is controlled from a
database table.

Quote
> There are of course problems because UI elements should really sync
> to program state, not actions/commands. The activators linked to
> plug-ins were _all_ updated on _every_ action; this will obviously
> scale very badly.

The TAction model is quite handy: It runs action "state" update on idle
time. I have naver been able to investigate it 100%, though, as it is a
nightmare tracking this execution (jumping through a vast number of methods
in a lot of different units).

Quote
> >..and, within data models, the different datasets should be divided into
> >groups:

> >- 'System data': Data describing the system. It rarely changes, and needs
> >only being loaded once per run.
> >- 'Registers': Like Zip codes, different kinds of libraries ('Employees'
> may
> >or may not be placed here).
> >- 'Business data': What most of the "real work" is centered around.
> >Concurrency issues & transactions are concerns here.

> These latter two sound like static and dynamic data, with static
> data being more in the background and dynamic data being under
> your control and the basis for "production".

Exactly. And it makes sense to keep the two in separate parts of both
application *and* database.

Quote
> >..another distinction, at dataset level:
> >- 'Structure data': ID's, Foreign keys, etc. that describe the structure
> of
> >the data.
> >- 'Info' : Data who is not processed or subject to validation.
> >- 'Business data': that controls the "outcome" of the application.

> [...]

> [SQL]
> >doesn't allow database object's names (tables, fields) to be varable, so
> in
> >practice, RDBMS model needs to be static.

> You can hardly blame SQL for that. Models need to be static, because
> if they aren't, you couldn't write an application against them.

I don't blame SQL, I just feel that it is an extremely formalized concept,
which make applications really ugly once you move too far away from the
CUSTOMER/EMPLOYEE examples. All databases have system tables, but you're not
allow to extend them with information needed for your own project, and
you're not allowed to write SQL based on this kind of system data. It could
easily be done, but the RDBMS world have been fighting over security-,
performance- & transaction issues rather than the area where SQL no longer
does the job in a sensibly written system. Good for Delphi programmers'
market position, of course.

Quote
> <XML is no better>

> That's what I mean. It _can't_ be any better, even if it makes some
> things easier (and I think all the advantages of XML can be had with
> network databases, and those map to relational databases, therefore XML
> does, too), because applications are _implementations_ of semantics.
> They can't look at a database schema, or a DTD, and think about what
> it means. In fact, even with descriptive names and other hinting and
> prejudices, humans have a hard time doing that.

Exactly. What is between the data definition and a good user's system is
hours and hours of programming. In this scenario I feel that a
"component-based approach" like VCL is not worth much. Delphi offers next to
none helpful concepts that enables writing an application that represents a
relevant mental model of what it contains. Instead you get Forms, Forms,
Forms and nothing inbetween them.

--
Bj?rge S?ther
bjorge@hahaha_itte.no

Re:TechTips: How to avoid "write-only code"


Quote
Bj?rge S?ther wrote in message ...
>"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding
>>                 ... applications are _implementations_ of semantics.
>> They can't look at a database schema, or a DTD, and think about what
>> it means. In fact, even with descriptive names and other hinting and
>> prejudices, humans have a hard time doing that.

>Exactly. What is between the data definition and a good user's system is
>hours and hours of programming. In this scenario I feel that a
>"component-based approach" like VCL is not worth much. Delphi offers next
to
>none helpful concepts that enables writing an application that represents
a
>relevant mental model of what it contains. Instead you get Forms, Forms,
>Forms and nothing inbetween them.

Maybe we're not talking about the same things, but Delphi
offers OO capability and a working component system for
when you want to use it (as it happens, I don't want to
use it that often, which is perhaps more telling than I've
so far recognised). The class system lets you build ANYTHING
in terms of a mental model, in my experience.

When I worked at the bank, I once discussed programming
concepts with the guy in charge of the telebanking application.
He told me it was about a hundred units large, and I asked
him how many components they had written for it. Oh, about
five or ten. *boggle*

If it is true that Delphi gives you forms and the VCL, you
can still build class hierarchies to model reality, and if
you do it right, yes, you have to build most of your own
classes. Forms will be among the least interesting classes
in your project.

I was asked to build an editor for structured data files, so
I started with a class that represented generic data files, a
grammar that described the structure, a class that used them
both (derived from one, embedding the other) to parse the real
data files into itself, an editable display that you could
assign a data file to and would construct itself from the
grammar linked to from the data file. A plug-in class to keep
the editor general (worked, too - since grammars were also
derived from that generic data file class, you could load them
into the editor as well - required changing _three_lines_), a
treedata class to store hierarchical data (parse data according
to a grammar and the grammar tells you what the hierarchy means).

Later I wrote an XML parser and derived the DTD classes from the
grammar classes. Really, I have to take exception to your saying
that Delphi hands you nothing. Delphi lets you build ANYTHING.

You're right in so far as that the VCL itself gives you little
more than a few building blocks. Lists to store your objects in,
a treeview to display their structure. Frankly, I'm not waiting
for the moment that any idiot could click together an application
that I spent over a year on. I hope there will _always_ be things
I can do that are beyond visual aids for managers and secretaries.
Do you want to be made redundant by nephew art in VB?

Groetjes,
Maarten Wiltink

Re:TechTips: How to avoid "write-only code"


"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding
news:aaj15s$g14$1@news1.xs4all.nl...

Quote
> Bj?rge S?ther wrote in message ...
> >"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding

> >>                 ... applications are _implementations_ of semantics.
> >> They can't look at a database schema, or a DTD, and think about what
> >> it means. In fact, even with descriptive names and other hinting and
> >> prejudices, humans have a hard time doing that.

> >Exactly. What is between the data definition and a good user's system is
> >hours and hours of programming. In this scenario I feel that a
> >"component-based approach" like VCL is not worth much. Delphi offers next
> to
> >none helpful concepts that enables writing an application that represents
> a
> >relevant mental model of what it contains. Instead you get Forms, Forms,
> >Forms and nothing inbetween them.

> Maybe we're not talking about the same things, but Delphi
> offers OO capability and a working component system for
> when you want to use it (as it happens, I don't want to
> use it that often, which is perhaps more telling than I've
> so far recognised). The class system lets you build ANYTHING
> in terms of a mental model, in my experience.

Yep, we had that possibility even back in TurboPascal for Windows. Buying
the inflated Delphi package just to write basic Object Pascal ? I must say
I'd expect a little more in the year of 2002. A problem here is evident: If
I choose to put all my efforts into a "component-free" programming style,
maybe even creating a whole new framework to build new applications over, I
find myself communicating with other Delphi developers who took a strategic
decision of sticking to the VCL model. That's in fact a high prize to pay
for getting yourself a better model: solicity.

Quote
> If it is true that Delphi gives you forms and the VCL, you
> can still build class hierarchies to model reality, and if
> you do it right, yes, you have to build most of your own
> classes. Forms will be among the least interesting classes
> in your project.

Yes, they will.

Quote
> Later I wrote an XML parser and derived the DTD classes from the
> grammar classes. Really, I have to take exception to your saying
> that Delphi hands you nothing. Delphi lets you build ANYTHING.

IMHO, you can't judge a programming tool by the programming language itself,
as it's obvious that the structure & quality of the provided class libraries
*really* matters. Remember Delphi2 ? The TDataSet
base class actually required installed BDE to be used. Not much left of
database functionality for non-BDE programming then. What was done with D3
actually opened up new possibilities that would before be practically
undoable due to the required effort.

Actually it's worse. A standard Delphi application has the line:

  Application:=TApplication.Create

...where TApplication is an object that you don't touch. OK. Want to skip
the TApplication object ? Want to *rewrite* the TApplication object ?
Probably not, we'll just start creating workarounds from line #1.

Quote
> You're right in so far as that the VCL itself gives you little
> more than a few building blocks. Lists to store your objects in,
> a treeview to display their structure.

The TreeView of Delphi is for displaying individual strings & pictures
stored in separate lists, it's as if noone understood that everything
displayed & edited in controls is in fact part of data structures.
"Reinventing the wheel" all day long.

Quote
> Frankly, I'm not waiting
> for the moment that any idiot could click together an application
> that I spent over a year on. I hope there will _always_ be things
> I can do that are beyond visual aids for managers and secretaries.
> Do you want to be made redundant by nephew art in VB?

No, that's not gonna happen. But programming *must* mature, and I believe
the first step would be getting rid of the stupid RAD ideas.

--
Bj?rge S?ther
bjorge@hahaha_itte.no

Re:TechTips: How to avoid "write-only code"


Quote
Bj?rge S?ther wrote in message ...
>"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding
>news:aaj15s$g14$1@news1.xs4all.nl...
>> Bj?rge S?ther wrote in message ...
>> >"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding

>> >>                 ... applications are _implementations_ of semantics.
>> >> They can't look at a database schema, or a DTD, and think about what
>> >> it means. In fact, even with descriptive names and other hinting and
>> >> prejudices, humans have a hard time doing that.

>> >Exactly. What is between the data definition and a good user's system
is
>> >hours and hours of programming. In this scenario I feel that a
>> >"component-based approach" like VCL is not worth much. Delphi offers
next
>> to
>> >none helpful concepts that enables writing an application that
represents
>> a
>> >relevant mental model of what it contains. Instead you get Forms,
Forms,
>> >Forms and nothing inbetween them.

>> Maybe we're not talking about the same things, but Delphi
>> offers OO capability and a working component system for
>> when you want to use it (as it happens, I don't want to
>> use it that often, which is perhaps more telling than I've
>> so far recognised). The class system lets you build ANYTHING
>> in terms of a mental model, in my experience.

>Yep, we had that possibility even back in TurboPascal for Windows. Buying
>the inflated Delphi package just to write basic Object Pascal ? I must say
>I'd expect a little more in the year of 2002. [...]

We're getting sidetracked here, I think - the question I wanted
to raise was if _any_ language could supply what you seemed to
be "expecting a little more of in the year 2002". (Read on.)

[...]

Quote
>> Later I wrote an XML parser and derived the DTD classes from the
>> grammar classes. Really, I have to take exception to your saying
>> that Delphi hands you nothing. Delphi lets you build ANYTHING.

>IMHO, you can't judge a programming tool by the programming language
itself,
>as it's obvious that the structure & quality of the provided class
libraries
>*really* matters.

For programmers with a solid base of theory, programming languages
are to a large degree irrelevant. It's like really good musicians,
who can pick up a new instrument, abstract its physical qualities
in ten minutes, and start making *music* on it. With an instant
proficiency that would take you or me years to develop. Standard
libraries must nowadays be considered an integral part of every
language, or sometimes every development environment.

Quote
>                  Remember Delphi2 ? The TDataSet
>base class actually required installed BDE to be used. Not much left of
>database functionality for non-BDE programming then. What was done with D3
>actually opened up new possibilities that would before be practically
>undoable due to the required effort.

>Actually it's worse. A standard Delphi application has the line:

>  Application:=TApplication.Create

>...where TApplication is an object that you don't touch. OK. Want to skip
>the TApplication object ? Want to *rewrite* the TApplication object ?
>Probably not, we'll just start creating workarounds from line #1.

I don't see this as a disadvantage. You can (could) subclass
TApplication if you really wanted, but even if you simply leave
it as it stands, it does an enormous amount of work for you
that otherwise you'd have to do yourself. Don't forget that
Windows is a whole other beast than DOS; this work _has_ to be
done.

These _are_ the things that make Delphi on Windows "new" and
"improved" and, yes, really better than Turbo Pascal on DOS.

[...]

Quote
>> Do you want to be made redundant by nephew art in VB?

>No, that's not gonna happen. But programming *must* mature, and I believe
>the first step would be getting rid of the stupid RAD ideas.

Okay, you don't have to like RAD. You're not the only person
Borland is trying to sell Delphi to. They won't care if 90%
of the clikz kiddies who buy a copy never make it past the
point of clicking and dragging an application together that
differs from the samples only in the tab order.

Still, given that Delphi is a Windows development environment,
it's a good thing there are UI construction facilities. I don't
want to build my own windows, even if I still have to push
pixels if I want my forms to resize properly (meaning the way
*I* want them to).

And the whole database interfacing thing you get with Delphi -
I assume it must make your life easier (I can only assume since,
curiously, I've never done database-related things in Delphi) to
have database connection libraries at a click's distance. Plus,
they conform to the same model as all other components. How can
this not be progress?

But in the year 2002, you expect a little more. What, then? I'm
not saying you're being unreasonable, just that I don't see it.
There are things we have now that are better than five years ago,
and there are things that can't realistically be done today.
The component model (and the thousands of components available)
would be an example of the former, an intelligent application that
can make sense of, and do unspecified useful things with, arbitrary
DTDs it's fed would be an example of the latter. Apparently you have
visions of things between these extremes; I'm perhaps a more prosaic
type that needs solid footing somewhere and will build what's asked
for on that foundation, with the tools available now.

My point is that _all_ programming needs that solid footing in
_some_ place, but I'm aware that the real prophets can push it
back to unexpected places. Here's your chance to impress me.

Groetjes,
Maarten Wiltink

Re:TechTips: How to avoid "write-only code"


"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding
news:aajr3m$iee$1@news1.xs4all.nl...

Quote
> Bj?rge S?ther wrote in message ...
> >"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding
> >news:aaj15s$g14$1@news1.xs4all.nl...
> >> Bj?rge S?ther wrote in message ...
> >> >"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding

> >> >>                 ... applications are _implementations_ of semantics.
> >> >> They can't look at a database schema, or a DTD, and think about what
> >> >> it means. In fact, even with descriptive names and other hinting and
> >> >> prejudices, humans have a hard time doing that.

> >> >Exactly. What is between the data definition and a good user's system
> is
> >> >hours and hours of programming. In this scenario I feel that a
> >> >"component-based approach" like VCL is not worth much. Delphi offers
> next
> >> to
> >> >none helpful concepts that enables writing an application that
> represents
> >> a
> >> >relevant mental model of what it contains. Instead you get Forms,
> Forms,
> >> >Forms and nothing inbetween them.

> >> Maybe we're not talking about the same things, but Delphi
> >> offers OO capability and a working component system for
> >> when you want to use it (as it happens, I don't want to
> >> use it that often, which is perhaps more telling than I've
> >> so far recognised). The class system lets you build ANYTHING
> >> in terms of a mental model, in my experience.

> >Yep, we had that possibility even back in TurboPascal for Windows. Buying
> >the inflated Delphi package just to write basic Object Pascal ? I must
say
> >I'd expect a little more in the year of 2002. [...]

> We're getting sidetracked here, I think - the question I wanted
> to raise was if _any_ language could supply what you seemed to
> be "expecting a little more of in the year 2002". (Read on.)

In one sense VCL is not only a dead end, it gets worse every day. When the
"level of code interoperability" is that of TComponent, this makes evolving
more fruitful frameworks for *real* applications harder every day. For the
exact same reasons that also make Delphi development easy - thousands of
programmers around the world giving their code away (more or less). Maybe
something like when the 1,44MB diskette became standard, and all efforts to
create ~100MB diskettes fell to the ground. I believe the fact that VB &
Delphi/ C++ Builder use the same "drop-a-component" concept makes it likely
that what we'll see over the next years is "more of the same" rather than
new concepts.

- Show quoted text -

Quote
> [...]

> >> Later I wrote an XML parser and derived the DTD classes from the
> >> grammar classes. Really, I have to take exception to your saying
> >> that Delphi hands you nothing. Delphi lets you build ANYTHING.

> >IMHO, you can't judge a programming tool by the programming language
> itself,
> >as it's obvious that the structure & quality of the provided class
> libraries
> >*really* matters.

> For programmers with a solid base of theory, programming languages
> are to a large degree irrelevant. It's like really good musicians,
> who can pick up a new instrument, abstract its physical qualities
> in ten minutes, and start making *music* on it. With an instant
> proficiency that would take you or me years to develop. Standard
> libraries must nowadays be considered an integral part of every
> language, or sometimes every development environment.

...and just like the basic functionality of a flute is different from that
of a bass guitar, there are fundamental differences between programming
environments. I feel that VB / Delphi (or C++ Builder / Delphi for that
sake) are much closer related to each other than Delphi / Turbo Pascal. Not
syntactically, but the way you start thinking applications. An example of
this is that the TStringGrid is used by developers around the world no
matter how buggy or useless. Just because it's there.

Quote
> >the TApplication object ? Want to *rewrite* the TApplication object ?
> >Probably not, we'll just start creating workarounds from line #1.

> I don't see this as a disadvantage. You can (could) subclass
> TApplication if you really wanted, but even if you simply leave
> it as it stands, it does an enormous amount of work for you
> that otherwise you'd have to do yourself.

No. Any modern programming tool would have to provide some kind of
TApplication class. The stupid thing is that you're not supposed to subclass
it, and if you did, other programmers wouldn't dare to use your code
libraries. "The one who abandons TApplication will be a lonely programmer".
Anyway it's gonna be a hack.

Quote
> Don't forget that
> Windows is a whole other beast than DOS; this work _has_ to be
> done.

> These _are_ the things that make Delphi on Windows "new" and
> "improved" and, yes, really better than Turbo Pascal on DOS.

I was talking about TP *Win*, not DOS.

Quote

> [...]
> >> Do you want to be made redundant by nephew art in VB?

> >No, that's not gonna happen. But programming *must* mature, and I believe
> >the first step would be getting rid of the stupid RAD ideas.

> Okay, you don't have to like RAD. You're not the only person
> Borland is trying to sell Delphi to. They won't care if 90%
> of the clikz kiddies who buy a copy never make it past the
> point of clicking and dragging an application together that
> differs from the samples only in the tab order.

I believe I understand why Borland keeps on releasing new, identical (more
or less) Delphi versions. I don't know if this reason makes it look better -
that the programming tool with the most devoted supporters are in fact made
for kids...

Quote
> Still, given that Delphi is a Windows development environment,
> it's a good thing there are UI construction facilities. I don't
> want to build my own windows, even if I still have to push
> pixels if I want my forms to resize properly (meaning the way
> *I* want them to).

There are differencs between a "Form Designer" and an "All-Forms-VCL". The
only objects that cross TForm boundaries are phenomenons like Clipboard,
Printer, Session, Application, Screen, all *global objects*. None of them
are meant to be modified.

Quote
> And the whole database interfacing thing you get with Delphi -
> I assume it must make your life easier (I can only assume since,
> curiously, I've never done database-related things in Delphi) to
> have database connection libraries at a click's distance. Plus,
> they conform to the same model as all other components. How can
> this not be progress?

It's a dead end, too, if you ask me. The problem is that you save a *lot* of
time creating the simple editing & viewing screens, but there are things
that can only be accomplished through loads of really ugly code. Not to
mention SQL....to be able to write SQL without ''s and  #13 wrapping all
lines, you need to store SQL in TStrings properties of the datasets. Delphi
havs been sold for 7 years now, and there is still no solution to this
within Delphi. There are lots of such details, making the "sound"
programming strategies unneccesarily hard and the "dead ends" flashing into
your face.

Quote
> But in the year 2002, you expect a little more. What, then? I'm
> not saying you're being unreasonable, just that I don't see it.
> There are things we have now that are better than five years ago,
> and there are things that can't realistically be done today.
> The component model (and the thousands of components available)
> would be an example of the former, an intelligent application that
> can make sense of, and do unspecified useful things with, arbitrary
> DTDs it's fed would be an example of the latter. Apparently you have
> visions of things between these extremes; I'm perhaps a more prosaic
> type that needs solid footing somewhere and will build what's asked
> for on that foundation, with the tools available now.

You're right, I have ideas about an application framework that takes into
account that every little piece of data has it's DTD, and so has the
application itself. OnClick; and OnExit; handlers are *not* what it's about,
these are a computer technichan's perspective, not a System Analyst's.
OnExecute; and OnFinishedEditing;, it should be (if any event handlers at
all) ! VCL as it is today is built by a set of programmers with absolutely
no ideas about what building blocks make an application, their main goal was
hiding the WinAPI from the programmer, making it seemingly easy to create
applications. "Look, it says 'Hello, World' in less than one minute !" ...
and that's about all it's ever gonna do. There are people insisting on that
50% of all software projects are never finished, and it's a fact that
software developers are one of the most mistrusted groups in the world. You
try to defend yourself: "Yeah, but you see - I only have these OnExit events
!" - noone believes you. They think we are all morons. No, we're not, but we
have no tools...

Quote
> My point is that _all_ programming needs that solid footing in
> _some_ place, but I'm aware that the real prophets can push it
> back to unexpected places. Here's your chance to impress me.

I try to make a living from programming. I wouldn't expect to make a *single
$* from creating a good application framework that wasn't based on VCL. So -
I have to be pragmatic, and use most of the VCL, too. A part of this
decision is that I do no longer want to get involved in larger fixed-price
projects, because I have no tool that help me doing that job. It's too
risky, and I don't feel I'm getting any closer to success even if I feel I'm
getting a better programmer every day.
And you know what ? The day I didn't believe that there were programming
tools available in, say, 5 years that would make me laugh at Delphi 2002,
I'd probably end my programming career quite fast. I've been playing the
Guitar all my life, and I don't want anything out of it that it can't give
me. But Delphi & the likes...it's like a one-string guitar. Don't laugh, you
started the ...

read more »

Re:TechTips: How to avoid "write-only code"


Quote
Bj?rge S?ther wrote in message ...

<snip>

That was really a bit sad. Your arguments against the
VCL are valid and I agree with them. The bit about
"interoperability at the level of TComponent" is the
key, I think.

You seem to be saying that you'd like programming to
take a quantum leap; take the step to the next level
of abstraction. I expected that (if you didn't mean
that, I still expected that and that's how I made the
mistake), but I hoped you had a clear vision of what
it would look like. Alas, it seems little clearer than
my own ravings about application-level events and such.
An informal design philosophy, something that works in
one's head and gives good results when used, but not
with the clarity of ink on paper.

For now, we have to take this step ourselves in code,
and do so anew for every application. We have all of
Delphi's facilities to build on (or not), and all of
its examples to follow. Or not. I think it _is_ possible
to take this step, but (like dragging together a form)
it might be nice to have it generated. The real quantum
leap may be to not make it look like a code wizard.

Groetjes,
Maarten Wiltink

Re:TechTips: How to avoid "write-only code"


"Maarten Wiltink" <maar...@kittensandcats.net> skrev i melding
news:aakd2g$4at$1@news1.xs4all.nl...

Quote
> Bj?rge S?ther wrote in message ...

> <snip>

> That was really a bit sad. Your arguments against the
> VCL are valid and I agree with them. The bit about
> "interoperability at the level of TComponent" is the
> key, I think.

> You seem to be saying that you'd like programming to
> take a quantum leap; take the step to the next level
> of abstraction. I expected that (if you didn't mean
> that, I still expected that and that's how I made the
> mistake), but I hoped you had a clear vision of what
> it would look like.

I'd lie if I stated having a clear vision. I have a few ideas, some
fractional, some more "wholistic":

- The only "Form" in the Delphi sense in an application would be "The
Complex Main Form", when a such exists (the Main Window in MS Word, the
Toolbar in Delphi, The Browser Window of Outlook Express, etc.). Having a
form like this with lots of code in it sometimes feels natural, as it is the
"heart" of the UI.
- Parts of such forms could be kept as separate objects, because they may
contain functionality that's also a central part of an application's "state"
or data model. To the rest of the application, it should be 100% transparent
whether the object is actually owned by the Main Form or not. The concept I
*have* been discussing with myself, is the 'Selector', or maybe
'StateObject' - an object that provides values and notifications to other
parts of the system whether or not it's actually represented by some visual
control. It may be a control that's optional to a user or a "user mode".
It's obvious that such objects should not be centered around a specific
control class, while control classes should be able to interact with it.
- The 'Inplace Editor' of the TXXGrid is an interesting concept - the
control as a passive display with one little editor object "jumping around".
When writing a grid-oriented editor, you may need to do lots of calculations
on what inplace editor to invoke, how it should look, etc.. There are a lot
of ways to make a user friendly dialog that con't be done by placing
controls at designtime. The Inplace Editor is useful also outside the
grid...
- 'Actions' as in 'TAction/-List' should be treated in a "matrix", as they
are connected to certain dialogs/controls (like when used with
TActionLists), while their design, maintenance and documentary sides pont
towards a centralized handling. Just think of the standard actions like
Copy/Paste/Undo/Redo, etc., they should of course be accessible as *one*
object per functionality.
- Dialogs are 'Editors', passive information displays (An 'Editor' minus
editing capabilities) or they are containing separate functional modules -
'Applets'. They are not 'Forms'. Most experienced programmers have developed
a habit of wrapping a dialog in a procedure call, and would claim that a
form should never be treated the "Standard Delphi Way" - by creating the
form Component-wise at startup *or* from another form. Allways call the
entry routine.
- When moving to OO data handling, invoking the object's editor should of
course be possible without writing the code for explicitly doing it. It's as
basic as having a form closed when you hit the upper right 'X' button.
- Copy / Paste / Undo / Redo / Print, Local menus etc., should be regarded
basic application functionality instead of being tied to certain control
classes. Within regular VCL Form design, you fill in PopupMenu properties
for every control, a task that is both tedious and likely to be outdated.
The concept of a shortcut is partly "control-specific actions", partly "most
relevant actions" - and so handling of local menus should be *designed* for
that !

[going to bed]

Quote
> Alas, it seems little clearer than
> my own ravings about application-level events and such.
> An informal design philosophy, something that works in
> one's head and gives good results when used, but not
> with the clarity of ink on paper.

> For now, we have to take this step ourselves in code,
> and do so anew for every application. We have all of
> Delphi's facilities to build on (or not), and all of
> its examples to follow. Or not. I think it _is_ possible
> to take this step, but (like dragging together a form)
> it might be nice to have it generated. The real quantum
> leap may be to not make it look like a code wizard.

One *big* problem with the VCL component model is that components are made
static in their nature - I have accidentially found that you're really much
more happy with leaving the package uncompiled when changing incorporated
units, leaving out all "tricky" parts from designtime manipulation. Then you
may modify a class for the sake of one application without breaking all the
other that uses the same component. I get so nervous whenever I recompile a
component package. Maybe one should rethink the whole designtime stuff.

--
Bj?rge S?ther
bjorge@hahaha_itte.no

Re:TechTips: How to avoid "write-only code"


This is one of the most interesting threads to have developed here,
ever...

I don't think that it's "wishing" to speak of a three-layer cake as a
buildable design for a system.  It is certainly something that you can
do in Delphi or any other language.

One mistake that I see, and that I see taught ad-nauseum in college
courses (and I am to a certain extent guilty here...), is that we all
try to create the "ultimate framework."  We try to build an abstracted
model of a system that magically encompasses all possible cases we can
think of.  And what winds up happening, of course, is that our model
just becomes too-complex.  {Witness what happened with Microsoft's
OLE/COM/DCOM system... "great until the registry breaks .. anywhere!"}

The terminology that is bantered around in such circles can also become
a problem (especially if you've had to pass a college test on it!).  You
wind up attaching a boatload of meanings and interpretations to what
someone might be talking about when they say "an object."  If you were
introduced to these words in the context of "Dr. So-and-So's Methodology
Which Is The Subject Of This Course You've Got To Pass" (for your degree
or for your vendor-certification...), then those words never mean
anything less than all-of-that to you.  I fear that what can happen in
this case is that you just _lose _sight _of the big-picture; the simple
idea that lies behind all of that elaboration.

You -can- design a practical system, even one built in standard Delphi,
with distinct layering between physical-storage, logical objects, and
user-interface.  What's hard, in the case of standard Delphi, is that
you can't just use "data-aware controls" to do it.  And data-aware
controls of course are so damned easy to use that it's hard to justify
in your mind -not- using them.

But "data aware controls" don't display objects; they display database
records.  Individual records pointed-to by a cursor.  If that is not
what you had in mind, then building the system in standard Delphi
suddenly switched from being easy-to-do to being much more difficult.

But there's still more to it than that ... an idea that's more
ephemeral, one that lies in-back-of any concrete example you could think
of.  Let me allude to it in a question:

Quote
> In a standard-Delphi application, how many layers of the "cake"
> would be aware that there exists "a table" and "a record" and
> that you are looking at this "record?"  How exposed to the user,
> if you will, is the underlying schema of (and the existence of)
> a "database?"

In standard Delphi the answer would probably be, "all three."  So there
is logic scattered throughout the program that knows about, and that is
therefore highly dependent on, the nature and _exact structure of an SQL
table someplace.  This is why you can watch the color drain from the
face of your senior software-engineer when you suggest the idea of
"adding a field to the PRODUCTS table."  Her(!) face went blank because
she probably _cannot _easily _know just how much of the code might be
"broken" by that change.

And so on.

----------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:i...@sundialservices.com  (PGP public key available.)

Quote
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R):  Release 4.0 is here!!
> http://www.sundialservices.com/products/chimneysweep

Re:TechTips: How to avoid "write-only code"


On Fri, 03 May 2002 12:25:32 -0700, Sundial Services

Quote
<info_...@sundialservices.com> wrote:
>This is one of the most interesting threads to have developed here,
>ever...
<snip>
>In standard Delphi the answer would probably be, "all three."  So there
>is logic scattered throughout the program that knows about, and that is
>therefore highly dependent on, the nature and _exact structure of an SQL
>table someplace.  This is why you can watch the color drain from the
>face of your senior software-engineer when you suggest the idea of
>"adding a field to the PRODUCTS table."  Her(!) face went blank because
>she probably _cannot _easily _know just how much of the code might be
>"broken" by that change.

I can't resist jumping in here.

The segregation of UI, Data manipulation and physical storage is
fascinating.

It is one of the reasons why I have always been suspicious of 'Data
Bound' Controls.

However I have long (since 1989) been of the opinion that one can and
should pass a 'lump' of data around the App and only let things that
_have_ to know about what is in it get at it.

And those things should not know about anything else in the 'lump'.

Adding a field should never impede on anything other than the odd
screen - and generally printed report.  
The rest of the system should be able to be 'blythely unaware' that it
exists.

To me the paradigm system design is:

    Data := GetData( Key )
    StoreData( Data )             // note: no key
    Handle := QueryAllData( TextString )
    Data := GetDataFromHandle( Handle, N )

    Something = GetSomethingSimple( TextString, Data )
    Something = GetSomethingMoreComplex( TextString, Data )  

In other words 'Hourglasses'.

Adding fields should involve no more than using a Text Editor

Re:TechTips: How to avoid "write-only code"


Quote
"J French" <Bounce_It_je...@iss.u-net.com> wrote in message
> It is one of the reasons why I have always been suspicious of 'Data
> Bound' Controls.

I like the idea of data bound controls. I just think that they should be
more generalized. A data source should be able to cope with data from any
source. This allows the edit controls to concentrate on ui issues, the data
source co-ordinates access to the data set, and the data set can manage the
data.
Go to page: [1] [2]

Other Threads