> > Does the above work? > > > Yes. but. the times I've tried it really got to be a mess.
So then, "no" :( > 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 concerns about memory management aren't so large for me. > This may be why it's not so much of a concern. I'm not sure what you mean about "large memory blocks, etc.", but I can say that memory management isn't on my list of concerns here. At all. > I think they were pretty good solutions at the time - which was what, 20 > years ago? Nope, they were always a crap idea. I hated them on day one and my reasoning has not changed. (I have used them enough to understand how to use them correctly and to see the places where they're handy.) It is fundamentally wrong that a process can change the state of another process without any form of permission or negotiation. A message queue was always a better solution and they were well-known at the time. We still don't have a native queue in 4D, but there's some progress with CALL WORKER/CALL FORM (if used correctly, you can absolutely use these commands in terrible ways - but you don't have to.) 4D wasn't cutting new ground when it came to concurrent processes. Although they did a great job of bringing to the masses in a very easy to use way. Kudos. The basic programming issues and tools around concurrency got thought through before 4D ever existed. First and foremost by Edsger Dijkstra. He invented the semaphore along the way, believe it or not. But my disgust at GET/SET VARIABLE is well established already, so I'll (try to) stop now. > 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. Ugh. I'm just trying to find a strategy that's workable but not too onerous. I may not have mentioned, but I'm not trying to share variables directly. I've got calls like: ErrorStack_GetStack () : Error stack object When this routine is called, there is no error stack object. Instead, the actual stack is an object array and some support variables. For 99% of the time, it's a lot simpler to work with the object array than a C_OBJECT with an embedded array. When I need to dump the stack to text or to an object, that's the only time I need a single object. The outside world hasn't got access to the arrays, etc., but it can ask for an object version of them. The outside world doesn't know there isn't a C_OBJECT because that's all it can see or get. Put another way, ErrorStack is already API-oriented. But what data does ErrorStack_GetStack() package? That's what gets confusing. I absolutely don't want to write a bunch of code that delves into the hidden locations 4D has allocated. I also don't want to expose my underlying implementation. Pointers smell wrong here too, particularly since what I'm returning is generated on the spot. I might give components one more try by putting everything into an OmniJumble component and having the host call it all of the time. Not really a sensible way to organize libraries, but it may be as good as I can get. My main goal, in this case, is to hide a lot of the plumbing on a large body of code. I'm not trying to hide the code per se (if I give out the component, I'd give out the code), but to make the calls easier to work with. Your idea about colored method names would help here too. On Fri, Apr 21, 2017 at 9:04 AM, Kirk Brooks via 4D_Tech < 4d_tech@lists.4d.com> wrote: > 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 > ********************************************************************** > ********************************************************************** 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 **********************************************************************
