David, On Thu, Apr 20, 2017 at 3:22 PM, David Adams via 4D_Tech < 4d_tech@lists.4d.com> wrote:
> On Thu, Apr 20, 2017 at 16:57 Kirk Brooks via 4D_Tech < > 4d_tech@lists.4d.com> > wrote: > > > 1) as a repository for a core set of functions > > 2) as more or less independent sub-programs > > 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: > ... > Does the above work? Yes. but. the times I've tried it really got to be a mess. You know that old joke? "You change one little thing..." The biggest problem is when you compile each component must have its own copy of utilized components within. In your example you change one little thing in Error Stack and you've got to rebuild everything - and in the correct order. Not happy. > 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. > I think if you orient your view of of components as tool packets you'll be better served. > > And I dearly wish 4D offered a pref that > > would allow me to have them appear with a different color from regular > > methods in the editor. > > What an outstanding idea! How hard could it be? Please set up a feature > request on the forums and post back here. I'll vote for it, for sure. > > > Or I write a local method to take over that function from the component. > > There are two ways to spot duplicated methods: 1) they appear as warnings > > in the complier > > Not for me they don't. I've set this up on purpose and they aren't > detected. > > > I like being able to override the component with a local method. The > > problem is when I may write a local version of a method and forget to go > > back and update the component. > > I have no problem with the concept of an override, it's just that it's a > bit obscure if/when it is happening. There is no way to address a specific > instance/scope of the method. > The visiual cue would help. I'll put that on the forum tonight. > > the black box approach they compel you to take. > > Man, I wish 4D gave us a black box. What I'm seeing is more of a soggy > brown cardboard box. Made me laugh. > The variables are in their own weird space *without an > address*. You just implicitly have to know what context the code is running > in. And that code may or may not be running in the host or the component. I > find this hard to get my head around because it's a murky design. There > isn't a crisp line and there is no way to specify where you're talking to. > You just have to know. I'm not loving it. > True but you can work with it. So long as it's consistently enforced it's not so big a deal. You can always pass pointers to vars on the 4D side. I should point out, though, that my style of programming stays away from large memory blocks that I expect to be stable or controlled during the life of the session. I use some of those, of course, but not extensively. So some of these cncerns about memory management aren't so large for me. This may be why it's not so much of a concern. > Note: You can absolutely screw up what I just said about using workers in a > novel way. Just mess with them using GET/SET PROCESS VARIABLES. Whoever > thought they were a good idea? I'll say this, if those commands are the > ans > Pro > wer, someone really didn't understand the question. > I think they were pretty good solutions at the time - which was what, 20 years ago? Otherwise I agree, they're dodgy and in a busy system I think the time you'd spend setting & clearing semaphores to control them would obviate the benefit of using them. Your suggestion of just using a table is much better there. 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. > Well this is the opacity of the soggy cardboard isn't it? Think of them as microwave ovens maybe. You open it up, put some stuff in, adjust some settings and turn it on (lose). Then you get out the finished result. You could get involved in modulating the microwaves yourself - but why? If you're writing your own component you could include methods to sync component vars with program vars - you'd just have to pass in the pointers to the program vars. IP vars in a component are available to the component in all component processes. -- Kirk Brooks San Francisco, CA ======================= *The only thing necessary for the triumph of evil is for good men to do nothing.* *- Edmund Burke* ********************************************************************** 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 **********************************************************************
