...the example was actually referring to
ancestor->PFC + descendant->PFE
>& ancestor->PFE + descendant->PFC<-------------------------Add
-versus what a PFCer may naturally associate as-
ancestor->PFC/PFE + descendant->app.
Sharon Buntz wrote:
>
> Boris,
>
> I understand your point about how descendant PBDs "have knowledge" of their
> ancestors. But what I do not understand is your and Gordon's conclusion
> that hence you cannot share PFC PBDs across multiple applications.
> Respectfully I must say - That is not an absolute truth. The truth is that
> it depends. And my opinion is that if one thinks like that (not sharing),
> then they are missing out on the glory of PB and PFC -
> REUSE.
>
> Gary said it best (see below), and I admire how he put it so succinctly. 6
> lines - Six! - oh how I'm duly impressed!!
>
> But I am here to elaborate because it is very important that PFCers
> understand that you CAN share PFC PBDs/DLLs among multiple applications -
> That is the beauty of using PB and PFC - REUSE! You change one place and
> voila all apps change to the common way. Plus you only have to have one
> copy of the PFC PBDs/DLLs on the end users machine (not to mention the
> extra overhead and headaches of separate sets of source PFC PBLs.) We have
> a dozen applications in production that share a common, single set of PFC
> PBDs/DLLs with no problems and lots of advantages.
>
> My point? Never underestimate the power of reuse.
>
> My truth? You can share PFC PBDs/DLLs among multiple applications - and it
> does behoove you to do so in my opinion - but you must follow these three
> golden rules:
>
> 1. Share your PFC/<...>/PFE PBLs as a whole [where <...> denotes any
> layers inserted in-between]. For example, you cannot have a separate set
> of PFE level PBLs for app1 and app2. Just one set of PFC PBLs
> (main/dwsrv/etc) and one set of PFE PBLs. Like this:
>
> 1-PFC main/dwsrv/etc
> 1-... " "
> 1-PFE " "
> / \
> app1 app2 <app3...app~infinity>
>
> 2. Do not "dip" below the PFE level within your PFC/<...>/PFE PBLs. That
> is, your PFC/<...>/PFE code cannot reference any application-specific
> code. Imagine a wall separating the PFC/<...>/PFE code from your
> applications like this...
>
> 1-PFC
> 1-...
> 1-PFE
> ========WALL========top code cannot refer to anything specific to an app
> / \
> app1 app2
>
> 3. Rebuild and redistribute every application anytime that you make a
> "significant change"* to your PFC/<...>/PFE PBLs.
> Note A: This is true only if PFC/<...>/PFE level source code changes.
> Note B: Remember that you need to redistribute the new app PBDs/DLLs too.
> Note C: Since app1 and app2 share the same ancestors, it only makes sense
> that both should be regenerated to take on the new common change.
> Note D: Bear in mind that this is only necessary if you make a
> "significant change" to the ancestors. That is, if you change instance
> variable declarations or function declarations in the PFC/<...>/PFE PBLs.
> And that does not happen too often.
>
> Now, granted there are a myriad of other viable approaches, each with their
> pros and cons - and everybody has their own circumstances and situations -
> especially in large corporations... But always strive for simplicity, and
> just remember the power of reuse.
>
> As an addendum to further support the above truth, I quoth the Borg from
> http://www.pfcguide.com/pfcmag/extension_page03.asp#PFE_as_a_Framework_Layer
> >>>>>>> START >>>>>>>
> PFE as a Framework Layer
>
> Using the second approach both the framework and application elements are
> included in the extension scope. The PFE layer is reserved for framework
> objects only. The application specific logic is added by inheriting from
> the PFE layer as demonstrated in Figure 9.
>
> <thumbs up> PFE and PFC pbls, pbds or dlls may be reused / shared between
> multiple applications.
> <<<<<<< END <<<<<<<
>
> I might add that I thoroughly enjoyed your PowerTimes PFC Place article
> which demonstrates how a descendant object "has knowledge" of its
> ancestor. I even recreated the experiment from scratch since the resource
> code is not yet available. You did a fine job as usual, and the experiment
> makes the black box PBVM transparently clear so a PBer can "see" how
> instance variables (and functions) are imprinted behind the scenes on the
> descendants.
>
> But I feel strongly that that one line right before the "PBVM and PFC"
> conclusion be righted. Rather than saying, "This created a web of
> dependencies between objects and makes >>PFC PBLs specific to a single
> application<<." I think that you can only say, "This created a web of
> dependencies between objects and makes >>the PFC and PFE PBLs tightly
> coupled.<<"
>
> This also applies to your slant in this thread and specifically the line
> below that says, "In PFC this may mean different compiled version of PFC
> PBDs for different applications." Although you did at least say "may"
> there <g>
>
> Lastly, in the "PBVM and PFC" article, I just wanted to point out that it
> was somewhat mind boggling since the example was actually referring to
> ancestor->PFC + descendant->PFE
> -versus what a PFCer may naturally associate as-
> ancestor->PFC/PFE + descendant->app.
> And in summary that again was the slant that I think is very misleading.
>
> Respectfully yours,
> Have fun,
> ~Sharon
> --
> Sharon Weinstrom Buntz | mailto:[EMAIL PROTECTED]
> Cheat Sheet for PFC/PB Help | http://www.pfccheatsheet.com/
>
> Boris Gasin wrote:
> >
> > Here are some details on Gordon's reply which may clear things up...
> >
> > PowerBuilder's PBLs contain both source code, something you would see when
> > you export an object and compiled p-code version of the object. PBDs only
> > contain the later. The problem most PB developers have with this issue is
> > that they think "source code" If source code is the same so is the
> > compiled p-code, right? Not exactly. This was more or less the case in
> > PB 3 and earlier versions. The objects were more independent of each
> > other, and more code was interpreted at runtime. At this version it was
> > possible to swap PBDs or to distribute the Class Library of the day in
> > PBDs. This flexibility came at a price. Performance had a lot of room for
> > improvement. Some of you may remember the recommendations to keep
> > inheritance below 3 or so levels.
> >
> > Starting in version 4.0 there were many performance related enhancements.
> > These enhancements were done by taking many tasks performed by the VM at
> > runtime and doing them upfront at compile time. For example in the case of
> > inherited object PB used to read the definition for the instantiated
> > descendant from the PBD. When it determined that the object was inherited
> > it would read the definition of the ancestor, building the event scripts,
> > resolving instance variable defaults and extended, overloaded, and
> > overridden functions at runtime. Obviously this took a while. In the
> > later PB revs the inheritance is resolved at compile time. For each object
> > in the inheritance chain PB builds an instance image, which includes the
> > definitions of all its ancestors. In other words the inheritance is
> > flattened at compile time. This instance image is stored in the PBDs and
> > PBLs. At runtime the object construction is greatly simplified. The down
> > side is that we lose the flexibility. A change in the ancestor will change
> > the compiled code of every descendant even though their source code has not
> > changed. In PFC this may mean different compiled version of PFC PBDs for
> > different applications.
> >
> > Second issue has to do with function v-tables. During a compile PB creates
> > a v-table containing the offsets to all the functions within this object.
> > PB also saves the offsets to the v-tables of the functions of other
> > related objects. The relationship could be via inheritance or association
> > (instance variables) Remember the message you get when you change the
> > object function definition? - "Changing the function arguments requires
> > that you regenerate all objects that call this function. Continue?" This
> > is another reason why you have to maintain a separate copy of PFC PBLs for
> > each application. Consider this. By changing a function definition in the
> > n_tr transaction object in the extension layer you are actually changing
> > the references to its v-table stored in the pfc_u_dw object in the PFC
> > layer! This is because pfc_u_dw has an instance variable of the n_tr type
> > and may call functions on n_tr. Even though the source code remains
> > unchanged after the n_tr change (extension layer) the compiled version of
> > the pfc_u_dw becomes unique to a specific application.
> >
> > I have recently submitted an article for the PFC Corner column of the Oct
> > 99 PowerTimes. The article discusses this in detail and goes through an
> > example demonstrating this behavior. If anyone doesn't get PowerTimes and
> > wants to see this article please email me, I'll be happy to forward it to
> > you. But to be fair to the publishers in exchange I would like to ask you
> > to plug PowerTimes at your local PB user group meeting or even going out on
> > the limb and getting a subscription! See http://www.powertimes.com/
> >
> > - boris
> >
> > At 09:10 AM 7/10/99 +0800, Gary Hyland wrote:
> > >I use the same set of PBDs for common 'Library' PBLs, ie PFC, PFE and any
> > >intermediate extension levels. If any changes are made in the common PBLs
> > >then all applications referencing them need to be recompiled. Currently
> > >have 3 apps that run like this in production. As others have stressed, you
> > >need to ensure that any application specific code is 'below' the library
> > >PBLs so it doesn't get caught up in the PFC inheritance loop.
> > >
> > >Gary Hyland
> > >
> > >-----Original Message-----
> > >From: Gordon A. Dickens, Jr. [SMTP:[EMAIL PROTECTED]]
> > >Sent: Wednesday, October 06, 1999 9:36 PM
> > >To: Vinod Adimulam; [EMAIL PROTECTED]
> > >Subject: RE: PFCSIG To use same set of pbd's.
> > >
> > >NO. The way that Powerbuilder "compiles" prohibits this from working
> > >correctly. You need to have one set per application.
> > >
> > >HTH,
> > >Gordon Dickens
> > >
> > >-----Original Message-----
> > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> > >Vinod Adimulam
> > >Sent: Monday, October 04, 1999 10:27 AM
> > >To: [EMAIL PROTECTED]
> > >Subject: PFCSIG To use same set of pbd's.
> > >
> > >
> > >Hi!
> > >Can I use same set of pbds (framework PBDs) in two different applications.
> > >
> > >Regards,
> > >Vinod
> [EMAIL PROTECTED] HOSTED BY IIGG, INC. FOR HELP WITH LIST SERVE COMMANDS, ADDRESS
> A MESSAGE TO [EMAIL PROTECTED] WITH THE FOLLOWING MESSAGE: help pfcsig
> SEND ALL OTHER INQUIRES TO [EMAIL PROTECTED]
