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
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>> [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]
>
>> [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]
>
>> [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]
Boris Gasin
mailto:[EMAIL PROTECTED]
___
____ _
_____ _
____ _
___
Dynamic Technology Group, Inc.
http://www.dynamictechgroup.com/
1055 Parsippany Blvd., Suite 501-26
Parsippany, NJ 07054
Phone: 973.402.5600
Fax: 973.402.5620
> [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]
