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:
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.
>
> I always use compiled components.
I've been testing all of this out with interpreted ones and much appreciate
that you can at least see the component's source. For production, I'd use
compiled components.
> 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.
> I have never expected or really wanted a component to share the same
memory
> space as the calling process so that's not an issue for me. I actually
like
> 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. 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.
It's hard to talk about a lot of language concepts in 4D because 4D is
missing so much. I kind of hoped that components would deliver more than
they do. I admit the business of them having their own variable space is
appealing...but it's done is such a peculiar way. I really don't like that
they don't have their own addressable execution paths. Very weird. I notice
a lot of people on the list being excited about "dot notation." Why? Who
cares? The benefit of object dot notation isn't the dots, it's the objects.
We have _nothing_ like that in 4D. The closest I've come to date are
workers. A worker has a crisp boundary (a process), you can communicate
with it via an API-like system (if you program it that way), and you can
make methods private (by testing the execution context name and type.) So,
yeah, that's okayish. Also, a worker is something that you can create at
runtime and where you can create multiple instances without adding new
methods. That all feels natural to me.
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
answer, someone really didn't understand the question.
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.
> The final thing about components is to have some useful material in the
> comments because that's the only way to get a tip to show up when you're
> using it. I've been using an approach like Wayne talked about for several
> years and it's really great for components. Before building I run the
macro
> and update the comments of all the component methods with the comments
from
> the method. So nice to have that reminder of what params do what.
That seems like really solid advice from you, Wane, et al.
**********************************************************************
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
**********************************************************************
