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]
