Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Copy class in one classlib
Message
From
02/07/2001 16:08:29
Gerry Schmitz
GHS Automation Inc.
Calgary, Alberta, Canada
 
 
To
02/07/2001 04:24:09
Mike Yearwood
Toronto, Ontario, Canada
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Miscellaneous
Thread ID:
00525519
Message ID:
00526045
Views:
45
>>I've rarely appreciated the class library approach. <<

The concept of "Class libraries" is good, it's their current implementation for visual components (ie. VCX) that I think is a problem.

>>However, how would two-way help Nadya copy a class?

The original problem (I think) was to copy a class AND change some class names for some objects within that class.

Currently, the VFP designer will not let you change "class names" of objects in VCX's or SCX's ("easily"). This might be a reaonable restriction if I had made extensive changes to the "inherited object" but it's totally unreasonable when I haven't. Even so, "I'm" supposed to be in control here, not VFP; if I think that changing a class name "will not hurt", I should be permitted to do so.

In all the 2-way implementations that I am familiar with, Nadya's class would have been a complete "program" stored as "text" in a .PRG file; not a bit of code and meta-data spread among a number of memo fields in multiple records of a VCX.

Nadya simply would have called up the class she wanted to copy and change, using MODI COMM, Notepad, or whatever was convenient at the time, done some "Find and Replaces", perhaps adding a new property and/or a method, then "saved" this class into a "new" .PRG; in effect, making a new "copy" (with changes) of the "old" class.

She would have, in effect, been (re)programming a class, not hacking.

>> And further, isn't it a mark of a bad design to have to copy classes instead of subclassing?<<

Not necessarily. Let's say I have an "abstract" base class that is used to handle "parent-child" relationships.

I may subclass this class, to create a class that handles Purchase Orders (Header and Details).

Maybe I now want a "Sales Order" (also Header and Details) ... similar to a PO, but different enough that I want to inherit from the "Parent-Child" abstract class and not the PO.

If I now "copy and modify" the PO class to create a new Sales Order class, I think I have a legitimate reason for copying a class. And I don't worry that changing the PO class might negatively impact the Sales Order class.
Previous
Reply
Map
View

Click here to load this message in the networking platform