> On Apr 20, 2017, at 6:04 PM,David Adams wrote:
> 
> That makes sense. I guess what I'm trying to get advice on is how to share
> utility code with a host and other components:
> 
> MyBigDatabase
> |____Components
>         |____ErrorStack
>              |____ErrorStack.4dbase
>                    |____ErrorStack.4DC
>         |____MessageHub
>              |____MessageHub.4dbase
>                    |____MessageHub.4DC
>                         Components
>                          |____ErrorStack
>                               |____ErrorStack.4dbase
>                                    |____ErrorStack.4DC
> 
> See what I'm saying? Does the above work? I'm asking without trying because
> others already know and I'm running out of time I'm willing to devote to
> basic research on 4D components in V16.

4D supports only a single level of components. You can’t have components inside 
of components. It would be a nice feature to have in some situations. 

> 4D components are weird because they have their own little variable space -
> but where is it? How do you address it? More to the point, how do you know
> when you're address it? It's sort of within the current process. But you
> can't address it specifically. It makes the code pointlessly hard to
> follow. The component isn't a runtime object, it's something baked right
> into the code. I don't even know what you call that.

I think we sometimes forget that 4D is not a 3GL programming language like C or 
C++. 4D is a 4GL language. You don’t get all the feature, benefits and 
capabilities of a 3GL language in a 4GL language. Remember why we all use 4D 
instead of using C++. You can get so much more done with 4D in less time and 
with less programming effort than doing it in C++.

4D provides many things that you can get from 3GL languages with less effort 
but with limitations. If you want something without the limitations you can 
have it, but not with 4D. Switch to C++ and you can have everything that you 
want. But then you will have to build it yourself or use code libraries and 
frameworks others have built. And that’s brings it’s own set of problems and 
issues to deal with. 

Also 4D is an environment that has a long history with a tremendous amount of 
legacy support. To provide many new features and capabilities that many want 
could quite possibly require dropping legacy support. And that means you might 
have to start over from scratch. Can’t upgrade from an older version of 4D. 

I’m sure the 4D engineers, when they were designing the component architecture, 
did the best they could in the 4D environment they were working with. They had 
to work within a system that they already had. They couldn’t start from 
scratch. They had to integrate components into the existing 4D environment. And 
that includes supporting the 4D Compiler. 

Consider the complexities of integrating components that may or may not be 
compiled and then building a final compiled 4D application incorporating these 
components. Now include a multi-level component architecture that goes n levels 
deep. Think 4D compiler linking nightmares. 

Makes me think of the proverb “You can’t have you cake and eat it too”. :)

Tim

********************************************
Tim Nevels
Innovative Solutions
785-749-3444
timnev...@mac.com
********************************************

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************

Reply via email to