What If..... Strong Types

brueckd at tbye.com brueckd at tbye.com
Wed Jun 19 18:12:25 EDT 2002


On Wed, 19 Jun 2002, Don Garrett wrote:

> > It's sometimes hard for me to model my objects this way because of having
> > had to always do it the other (completely statically defined) way, but
> > when this approach works the solutions are often quite elegant and
> > straightforward (btw - I believe that a good portion of bugs and program
> > cruftiness is related to forcing the programmer to clearly define, up
> > front, what the complete type of the object is. In many cases this forces
> > the programmer to make decisions without enough information, in others it
> > is too constricting, and in others it's just too tedious to make the
> > programmer worry about all those details, and in all cases general
> > hackiness ensues).
> > 
[snip]

>    Don't you find that you miss the advantages of a clear definition of
> what a class is and/or does? That's more important with group
> development, but even when it's just me.... I need memory aids.

A clear definition... as in a completely specified data type? ;-) It's the 
same issue of not being required to supply any more information than you 
really have.

I know what you mean though, but it's not like your objects are going to
be completely devoid of form or description when you use the dynamic
techniques. And like any other tool, when used in excess it doesn't really
help (i.e. in reality many/most data members of most classes won't be
dynamically added and removed so it's not too big of a deal).

In the cases I've used dynamic data members + group development, 99% of
the time the dynamic members were pretty private to my class, and the one
or two that weren't were covered in the test cases, which is where people
go to look to know how to use the class anyway.

Have fun,
-Dave






More information about the Python-list mailing list