>WeekDays, I really don't have such a function but similar like WeekStart,WeekEnd. They're in a prg based custom class called DateTimeUtils. The prg itself is named utils ( < g > every developer has one of them so a namespace like 'cb' and 'cb.Utils' would be nice).

I just read that a namespace is not the same as a vcx. A namespace sounds like what I'm talking about.

> Utils.prg as you might have guessed has a number of util classes. I don't bother all classes to be compiled in it because at least of 99% of whatever in it is used somewhere in the app. However I don't instatiate them with 'set procedure to ...' but explicitly with:
>
>local loDateTime as 'DateTimeUtils' of 'Utils.prg'
>loDateTime = NewObject('DateTimeUtils','Utils.prg')
>*...
>
>If that'd be referenced in a form a considerable amount of time then I might choose to:
>
>* Form.Init
>this.NewObject('DateTimeUtils','DateTimeUtils','Utils.prg')

Seems like that is a practice you should always follow since you're using an object. Regardless, instantiating the class and calling the method or just calling the method both take more time at runtime than calling the weekend.prg directly. You'd have to test in a exe or app to prove it so as to eliminate path searches.

So for me to find your weekend function, I have to modify command utils.prg, then look for the datetimeutils class and then look for the weekend method? It simply takes less time to just modify command weekend.prg at design time.

I admit it's interesting to use an object because of subclassing etc. but watch for performance. Putting a bunch of datetime methods together into a single class is a similar arbitrary grouping. A weekend object would give the same subclassing ability and would be far more granular.

Hmmm! I wonder if you could do that like this?...

weekend.prg
calculate the weekend
return the result

define class weekend as blah
procedure result
return weekend()
endproc
enddefine
*EOF

Then you could find the code in one shot and still use it as an object.

loWeekend.Result(date())

>
>Editing for me is simple either (such classlibs are always in my dev path):
>modify command Utils

Only because you already know where to look. You still have to move down the Utils.prg to find the DateTimeUtils class and then the method. That takes time.

>
>BTW I'm a single developer shop but I think it wouldn't matter if I were multidev shop. I'm also not saying everything in one classlib but multiple classes grouped in multiple classlibs. With a single file system you're actually doing that but with the help of OS organizing your files in folders. In a multidev situation my 'utils' might look like a blackbox to another developer but a class' purpose is being a blackbox provided it does what it documents right (OK I'm lazy to document each myself).
>
>Cetin
>
>>>Well I may not use English well. I use "personal preference" to mean "though I don't agree your way to be right I respect your ideas. You do it your way and I do it my way. No need for an endless discussion. Neither of us would be convinced:)"
>>
>>You use English well enough. I respect your opinion. If I did not respect your opinion, I would not see any benefit to discussing this with you. I am willing to let you try to poke holes in my argument because I may be wrong and hope to learn from you. I am willing to be convinced.
>>
>>There should indeed be discussion. There is a problem that needs to be solved. The problem is a lack of planning in the organization of software modules at design time. Can you tell me where I would put a function called Weekdays? I believe it should be it's own .PRG. Your first attempt SHOULD be to MODIFY COMMAND WEEKDAYS. So with no thought you can find my .PRG. You need only to guess the name of the function - which should be obvious. Just as with a language, the word ball represents a physical ball. The name of the function must represent the function. You should not also have to guess where it is stored.
>>
>>What is the best form of organization? There is a spectrum of everything in one classlib to one class per classlib. In a single developer shop, it would probably be OK to put everything in one classlib. In a multi-developer shop it would quickly become really awkward.
>>
>>Which approach works in both a single developer and a multi-developer environment? The answer should be obvious.
>>
>>I already know I cannot find your classes - without reading through documentation - if there is any, or asking you. If you leave the company before I start there, I'm screwed. I may chose to just build another one. If I need to fix yours I will have to find it, check it out of source control, make the change, recompile not just that one function, but the entire library, test it and then hope it checks back in to source control. Conflicts with other developers changing that library can require me to manually intervene in the integration process. There are workarounds, like text searchers and merging, but they are just workarounds.
>>
>>We don't build database multi-user applications that way! The user does not get the entire DBF file sent to them, change it, and then we examine the entire file to reintegrate those differences. In a properly normalized table such conflicts rarely happen. The record is the lowest common denominator in a table. The file is the lowest common denominator in a file system.
>>
>>Assuming everything is left broken down, I can categorize and cross-reference the functions in many different ways. You could categorize them your way and I could categorize them my way (if we think differently) and neither of us would be hindered by the physical arrangement.
>>
>>
>>>Cetin
>>>
>>>>I don't understand the use of "personal preference". Personal preference applies IMO to things that I like without really thinking it through. Things like how I take my coffee. It rarely applies to technical matters.
>>>>
>>>>For instance, if someone says it's their personal preference to put big half inch gobs of solder when assembling a circuit board that doesn't mean he's doing the right thing.
>>>>
>>>>>Personal preference.
>>>>>BTW I don't see weekdays function related to Payroll screen. I mean classes that are really related.
>>>>
>>>>I know they are not related. That doesn't stop people from coding it that way. Things get lumped together BEFORE any real thought goes into the organization.