Hi Charlie

>Hi Mike,
>I have no wish to fight -- and I don't think you can always use an abstract solution that doesn't take the language into account. It matters how the language works.
>The factory doesn't seem lightweight to me. Is it data driven? If so, you need to open a table, or perhaps get a connection and query a datasource. If it's a case statement, you still have to know what factory class to use since each application needs its own class. If the factory is a singleton, now you have the DataSessionID issue. (Which you don't think is an issue, I know.)

>In my work there are times when there are lots of private DataSessions yet I have never used a SET DATASESSION TO once.

Actually, that's unfortunate. I showed Mike Feltman and Drew Speedie how they might have a picklist form instantiated from a parent form adopt the data session of the parent form via SET DATASESSION. This combined with conditionally private data sessions allows me to query a picklist table once and reuse it as long as the parent form is instantiated. This proved to be a huge performance improvement, especially with larger tables. Both VFE and MaxFrame include this feature and has had it for years. You don't know what you're missing! :)

> When you instantiate the object in the dataSession you need it in, you don't do anything with dataSessions -- you just send a message to the object you wish to communication with. It has access to it's stuff.
>The reason to have a UDF at all is to handle all the details of creating an object in one place and in the current dataSession. NewObjectX has to know that you might pass parameters. You might not have ThisApp available in which case you can just use the default class and classlibrary. I used to have this repeated and would call ThisApp.OF() in code each time I created an object. Obviously, repeating the code was bad, hence the NewObjectX(). However, if your goal, as you say, is to try to follow the book as closely as possible, never mind. I would think that someone who was able to realize that packages of one class per classlib are good (thanks very much -- you've convinced me) would seek out the practical over the theoretical.

I was kidding about the fighting words. :)

The way the GoF described how they formulated the design patterns was by extracting the designs from practical working real world applications.

Programmers do not, IMO, think in terms of separation of design from implementation. That to me is a problem which I'm trying to avoid.

I am coming to appreciate the UDF concept. In fact, I'm often suggesting a PRG is a component just as an object is. However, I'm still trying to do it with objects first. Olaf did a great job explaining. I'm still digesting his input.

>>>Hi Mike,
>>>I think your design is backwards.
>>
>>Where I come from "Them's fightin' words." :)
>>
>>How's that tuna commercial go? "Sorry Charlie."
>>
>>>You have a method call that calls a UDF. One of my co-workers, Chris Bohling, created it as a UDF that calls a method. We use this sort of arrangement.
>>
>>Frankly there's nothing wrong with an object calling a UDF. Chris' UDF calls upon an object to get the class and classlib and newobject it. Why have the UDF at all?
>>
>>To me the whole point of Design Patterns was to turn commonly performed tasks into a set of "abstracts". Personally, I think they should have aimed for "standards". According to the oft published UML from the GoF book it seems an OBJECT is supposed to be creating another object. There was no mention of a UDF or procedure or data-driven or anything. I am trying to implement a design as close to the GoF book as possible. As long as the object encapsulates the design decisions, including whether to call on native commands/functions or even UDFs, that's good design.
>>
>>There are lots of things that will work, but unless it matches the GoF book, they're all IMO "backwards".
>>
>>VFP has datasessions, so IMO that means we deviate from the standard approach enough to deal with that idiosyncracy, not re-engineer the pattern.
>>
>>Thanks