> 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 **********************************************************************