Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Does a PRG class execute faster than a VCX based class?
Message
De
07/09/2005 16:08:10
Mike Yearwood
Toronto, Ontario, Canada
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 6 SP5
OS:
Windows XP SP2
Network:
Windows XP
Database:
Visual FoxPro
Divers
Thread ID:
01040117
Message ID:
01047485
Vues:
27
David

I think we're not that far off really. Rather than elephantine classlibs we have either atomic or quarkic ideas.

>>A zip file containing all the files of the package would facilitate such sharing. This is done to support intra-programmer sharing. That is not really necessary. What is necessary is to be able to access the class at runtime!
>
>A zip file is a distribution package. To play devils advocate your position should be that you don't want one zip file with a ton of stuff in it, you'd rather have a ton of zip files ach with one thing in it.
>

During distribution/sharing of code with another programmer, the aggregating of various classes and modules is fine. The compiler does not need packages.

>>I saw nothing about packaging in Ellen's discussion.
>
>Please reread it then because she does discuss in as it relates to UML diagrams and classlibs.

I did and she said precious little about it. She said a class is sort of a package and that a class can be the package.

>
>>"A package is purely conceptual.
>
>Not really, there are different kinds of packaging some logical (conceptual) and some physical.
>
>>It does not exist at runtime!" A VCX is only a PHYSICAL package.
>
>It does to
>
>
>set classlib to cControl additive
>
>
>gives me runtime access to all of the classes in the package.
>

I quoted from your reference. http://fox.wikis.com/wc.dll?Wiki~UmlPackages~SoftwareEng.

I would love to have the classes just exist outside of classlibs if and only if there was a way to refer to them in various ways at the same time.

In VFP 8 help, the New Classes, Commands and Functions "package" refers to the browse command. The Reference.Language Reference.Language Categories.Databases.Table Manipulation "package" refers to the browse command. There is however only one browse command. It is not VFP.Commands.Browse.

The packaging just gets in the way. If it was virtual and not physical that would be ideal.

>In C# we have using. In Java there are the import and package statements.
>
>Here's another relevant Java reference http://java.sun.com/docs/books/jls/third_edition/html/packages.html
>
>>I'm sorry Dave ;). You decided arbitrarily that these classes belong together. I see this as aggregating non-like classes. Everybody handles this differently and that is getting in my way alot.
>
>It's a logical packaging to me. When was the last time you developed an app that had a UI where it only consisted or textboxes or labels?
>
>Having cTextbox and cLabel and cGrid as well as all the other commonly used controls in one place is convenient.

Sure it's convenient until, as you said, you need to share cgrid between two apps.

>
>>cObject in cObject.vcx sounds right to me. I have a system that uses only Excel so your WordHelper would not help me. ;)
>
>But it's right there willing and waiting to be used. *g*
>
>>I was pretty sure that would be your position. You are not providing any examples of how it would get in your way.
>
>Having 500 classlibs in my project manager compared to 30 would be in my way. Having 1000 files on my hard drive and in VSS compared to 60 would be in my way. Having 500 entries in my SET CLASSLIB statement compared to 30 would be in my way.
>

Why? It's no hardship on the computer and you already directly refer to the particular classes by name.

>>I used to do what you are doing! MaxFrame for a time had a set of classlibs that grew up over time. I wanted to create a COM DLL using one of the business objects. This DLL was huge because VFP pulled in all sorts of stuff. Drew thankfully refactored the PHYSICAL class packaging to reduce this bloating.
>
>Did he refactor it all the way down to one class per classlib?
>

Of course not. The refactoring impact on the existing installations prevented him. Let's find a way to keep the flexibility to categorize things without physically relocating them.

>>I know one aspect where this would get in your way. You would have to refactor alot to get to where I am. Conversely I'll never have to refactor again. Hopefully you'll see the light someday.
>
>Ain't gonna happen my friend.
>
>>Thanks for taking the time.
>
>It just feels like you are being argumentative. You asked for some examples of packaging and I gave them to you. It's obvious you are stuck (quite happily) with a one class per classlib packaging structure, that's fine if it suits your style. To me it's not atomic it's quarkic *g* my packaging choice pulls the quarks together into more easily accessed atoms.

The class is not a quark. It is by definition the atom in OOP.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform