Hi, Feature Request for different style in method editor:
http://forums.4d.fr/Post//19321897/1/ Regards, Wayne [image: --] Wayne Stewart [image: http://]about.me/waynestewart <http://about.me/waynestewart> On 21 April 2017 at 09:04, 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 **********************************************************************
