Mike-
>What is the artificial extension? My associate is in favor of putting the DWORD code into every class that needs it. What I'm surprised about is that he's saying the class(es) is/are more cohesive because dword is inside them.

This isn't about cohesion or coupling. Your associate is just wrong headed about this. It was as bad a choice 20 years ago as it is today and has nothing to do with cohesion. Cohesion and coupling are only related to the component. Your DWORD utility may be cohesive and lend itself to loose coupling all it wants. That your associate copies the code into another class doesn't change that. See?

IOW, it's just not a smart idea for the same reason we (generally) normalize tables. It's not that there aren't times to break the rules, it's just that those times are rarer than some people think.

>Cohesive does not apply to the physical locations of the code, but to the idea that the class is a meaningful unit. Dword started out as a meaningful unit. Embedding it in another class may make the class a meaningful unit, but it did it at the expense of the meaningful-ness of dword.

No, it did it at the expense of the _maintainability_ of DWORD. Using fancy words like cohesion and coupling is just trying to slap lipstick on a pig.

>>BTW, what about the idea of using an interface?
>
>What do you mean by "using an interface"? A separate class that calls the DWORD.PRG? Isn't that an artificial extension? ;)

Ah, I see your confusion. No, I meant Interface as in Interface Class. But that wasn't a very bright idea on my part. An interface isn't going to probably help y'all.

>Embedding it in a distinct class may be fine, but a class done in code or visually takes longer to create than a prg as it must have more code.

Do you mean it takes you longer to write it, or to instantiate it? Neither is correct, IMO. Though, for the latter, if you really have millions of tight loops you should benchmark both solutions. But I've never seen anything definitive that says VCX classes take longer than PRG functions. But I find a lot people spend an inordinate amount of time optimizing code that in fact makes no difference what so ever.

>DWORDVCX.PRG
>DEFINE CLASS DWORD AS CUSTOM
>PROCEDURE DWORD

>Insert dword code here. Putting it in the init doesn't seem right, but even so, you'd have to include PROCEDURE INIT...ENDPROC

No, you don't.

>ENDPROC
>ENDDEFINE
>
>VS
>
>DWORD.PRG
>insert dword code here.
>
>Then using the class would require more steps than using the .PRG.

Not necessarily at all. Add the object to your component at run time and then call the method any time you like.

DEFINE CLASS blah AS CUSTOM
  ADD OBJECT MyDWORD1 as MYDWORD

>SET CLASSLIB TO DWORD.VCX ADDITIVE OR SET PROCEDURE TO DWORDVCX.PRG ADDITIVE

In neither case is this necessary. Just fer example:

DO MyDWORDfunc IN DWORD.PRG

or

lo = NEWOBJECT("MyDWORD","MyDWORD.VCX")

or

lo = NEWOBJECT("MyDWORD","MyDWORD.PRG")

>loDword = CreateObject("dword")
>?loDword.dword(parameters)

>
>VS
>

>?DWORD

>
>Never mind that dword must be found in the DOS path. That is a non-issue when the code is part of the EXE. Compiling the EXE would not remove the requirement of the SET CLASSLIB or SET PROCEDURE of the other approach.

I hate to see how long it takes you guys to thrash out really complicated disputes. *gd*rvvvf*