Re: Components: How do you reuse utility code?

[Cannon Smith via 4D_Tech]

James, I think you’ve expressed very well why more code in the 4D community 
isn’t shared. I know there have been many times when I wanted to share a bit of 
code that I thought would be helpful or in response to a question someone had. 
And then I realized how many “core” methods I would have to somehow share as 
well. Suddenly it becomes too onerous to quickly share it.

--
Cannon.Smith
Synergy Farm Solutions Inc.
Hill Spring, AB Canada
403-626-3236




> On Apr 22, 2017, at 10:58 AM, James Crate via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> So for example, the code I wrote some years ago to do HTTP GET with digest 
> authentication uses utility routines for basic things that I had to write 
> myself. That code can’t be easily shared because then someone would need to 
> also need to either edit the code to use their utility routines, or run the 
> risk of duplicate method names with different parameter lists. 

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

Re: Components: How do you reuse utility code?

[James Crate via 4D_Tech]

>> IMO that is one of the biggest reasons there is no significant code-sharing 
>> or component community in 4D, as compared to almost any other language. 
>> There would need to be a “standard library” component that other components 
>> could depend on, or they all have to reinvent every wheel.
> 
> The “standard library’ you allude to already exists. It’s called the 4D 
> language. The bulk of the world's 3GL “standard libraries” are trying to be 
> the 4D language and they never get anywhere near the level of consistency, 
> version continuity or platform support that 4D does. (Otherwise I’d be using 
> them !). 

Luckily, the bulk of the designers of the world’s 3GL standard libraries have 
never heard of 4D, so they can’t try to be 4D.

As far as consistency, maybe we’re talking about different things. To beat the 
dead horse of splitting a string to an array: 

STR_Parse_to_Array(->$array;$string;$delimiter) // mine
STR_Split($string;->$array;$delimiter)  // mine if I 
were creating it today
STR_Split_to_Array(??)  // 
someone else’s version?
manual string parsing   // 
Cannon’s OBJ module, any STR_?? method would likely collide

So for example, the code I wrote some years ago to do HTTP GET with digest 
authentication uses utility routines for basic things that I had to write 
myself. That code can’t be easily shared because then someone would need to 
also need to either edit the code to use their utility routines, or run the 
risk of duplicate method names with different parameter lists. 

By contrast, anyone developing a component in Objective-C will use:

NSArray *listItems = [list componentsSeparatedByString:@", “];

The same goes for almost every ARR_*, BLOB_*, and STR_* method, in almost every 
4D project ever written. If you look at code in one of those languages, you 
don’t have to look at each developer’s implementation of splitting a string, or 
removing duplicates from an array, etc. If you integrate code written by 
someone else into a project you don’t have to resolve all those conflicts, 
because they’re using the same standard functions you do.


> In that regard, the primary role of 4D components (in my experience) apart 
> from re-useability is quality control.
> 
> A single developer needs to reproduce the same code over again for many 
> applications. A component-based approach requires them to distill out and 
> de-couple business logic so that it is explicitly addressed in areas that it 
> is only implicitly addressed in a host-only project.

However, each single developer needs to implement many of the same things.  For 
example, in this (snipped) list, if you were writing apps in Xcode, you 
wouldn’t need to spend any time writing almost any of these yourself.

> UTILITIES
> • path functions (level navigation, multi-platform, joining, splitting)
NSString, NSURL, NSFileManager

> • version control
Integrated into Xcode and many IDEs. Version control is completely separate 
from any other language I have worked with, probably because every other 
environment starts with being accessible to whichever version control system 
you prefer.

> • property bags (text, blob, object)
> • object management
Full object-oriented support in Objective-C and Swift

> • string functions  (this is where your string ‘trim/splt’ would go)
NSString has most of the common stuff.

> • binary libraries (byte arithmetic, object opacity, colour addition, 
> saturation, brightness etc)
CIImage, CGImage, etc.

> • Window handling
> • user interface (forms, drawers, flaps, swaps, visibility
NSWindow, NSWindowController, an extensive set of built-in controls, data 
binding, etc.

> • inter process communications
NSNotification, NSNotificationCenter

> • BLOB routines
NSData, conversions to/from NSString, etc.

> • error handling
NSError, try/catch, full call stack all built in.


So not only does each developer *not* have to implement major parts of the 
language, when you look at somebody else’s code, most often they will be using 
the same framework you do. You don’t have to figure out how someone implemented 
window handling, they used included NSWindow methods for almost everything. If 
they want to get a file extension, they used filePath.pathExtension whether 
filePath is an NSString or an NSURL.  And those are just the simple examples. 
If in some part of your code you’re manipulating an array of objects, first you 
have to understand how that particular 4D developer implemented that particular 
property bag, and what the methods that implement the behaviors of that 
property bag might be called. In Objective-C, it’s probably an array of 
MyClass, and MyClass.h contains the public interface for that class so you can 
see at a glance pretty much everything you need to know about what data those 
objects contain and how they behave. 

To get back to components, if you have a 

Re: Components: How do you reuse utility code? (long)

[Arnaud de Montard via 4D_Tech]

> Le 22 avr. 2017 à 13:16, Bruno LEGAY via 4D_Tech <4d_tech@lists.4d.com> a 
> écrit :
> 
> I haven't measured if EXECUTE METHOD has a significant overhead to be 
> honest...

it depends  ;-)

+++
ARRAY LONGINT($ms_al;2)
C_LONGINT($count_l;$duration_l;$tk_l)
$duration_l:=60*3

  //**loop 1**
$tk_l:=Tickcount+$duration_l
$count_l:=0
Repeat  
$count_l:=$count_l+1
$result:=TestMethod (...)
Until (Tickcount>=$tk_l)
$ms_al{1}:=$count_l

  //**loop 2**
$tk_l:=Tickcount+$duration_l
$count_l:=0
Repeat  
$count_l:=$count_l+1
EXECUTE METHOD("TestMethod";$result;...)
Until (Tickcount>=$tk_l)
$ms_al{2}:=$count_l

C_REAL($ratio_r)
$ratio_r:=$ms_al{1}/$ms_al{2}
ALERT(String($ms_al{1})+"\r"+String($ms_al{2})+"\r"+String($ratio_r))
+++

I tried with 3 different 'TestMethod'
  a - a simple wrapper of 'Random' function
  b - a home made random based on generate UUID + hexadecimal convert
  c - explode a delimited text in a text array 
Just to mention that from a to c, the called TestMethod is more and more time 
consuming (in other words, regarding $count_l, a > b > c). 

• interpreted 
no difference, loop 1 & 2 are executed the same number of times. 

• compiled 
  a - loop 1 executed 88 times more than loop 2
  b - loop 1 executed 3 times more than loop 2
  c - loop 1 ~ loop 2

In conclusion, the more time consuming the called method, the most negligible 
EXECUTE METHOD. 

-- 
Arnaud de Montard 



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

Re : Components: How do you reuse utility code? (long)

[Bruno LEGAY via 4D_Tech]

Hi,

To be honest i am glad there a feeling of curiosity and interest about 
components.
I have seen the light my friends and I am a believer :-)
And there is hope for a "born again 4D component lovers" community.

I find it sad when I hear 4D developers saying that they tried components and 
that they gave up.

Maybe I can share my experience with components.

I have been using components since day 1 (early adopter) and I am *very* happy 
with them.
It really changed the way we write code.

I did a summit presentation in back 2012 Paris about "4D development 
industrialization with components".

And I attended Peter's very good presentation on components last year in 
european summit. Peter is also a fan of components.
Interestingly enough we use it in a difference ways (i'll come back to that), 
but we have encountered the same problems/pitfalls and found some 
solutions/workround. 

A bit of context first...

We are a bespoke developer company, mainly 4D, a bit of Oracle and php/web, 
etc.. (several dev, many projets, across several 4D versions).
We work in remotely (not coding together on the same 4D Server).

Before components we would have a common source library (a shell if you want).
We would move code with insider. But Insider is gone and maybe it was a good 
thing.

Early on, the methods of our library were grouped in modules (which helped us a 
lot to move stuff into components).

I looked into components as an alternative to 4D Insider.

I an idea of what I did not like :
- bloated components
- rely on too many human operations (boring, errors)

And what I wanted :
- reduce duplicated code across projets
- re-use technical code
- improve code quality
- fixe code once and share fixes across projects
- versionning
- avoid naming collision (a sort of namespace)
- performance (using compiled components in interpreted host is great 
compromise)
- logs to diagnose stuff
- documentation
- unit tested code (in an ideal world)
- move more than just code/methods, sometimes resources, etc...
- share code between versions (I don't enjoy moving code and fixes 
across libraries in several 4D versions)
- wanted to simplify updating code when changing 4D version
- modular approach : have access to a collection of component where we 
could choose and pick according to the needs of a given project.

I came to the conclusion, early on, that our code was made into two parts :
- business code
- technical code

The business code is rarely re-used. Also, working on tables, etc... is not 
simple with components (working with SQL or pointers) make things more 
complicated and brittle in my opinion. 
And I have never used component "local" data.
So I don't do business code in components. I know Peter has a different 
approach on this. It is fine, there is no right or wrong. Juste different 
taste, experience, needs and methods.


The technical code is in fact a collection of modules which can be, for the 
most part, independant of each other.
So for instance we have written about 40 to 50 components.

Some projects are using 2 or 3 components. Some are using 30+.

Some are published with source code for free (aws_component for S3 for 
instance).

Some are commercial (ociLib to help coding with 4D for OCI and provide 
retro-comptibilty to the legacy "4D for Oracle" plugin).

The vast majority is private and used internally. 
This is for instance, a part of our collection :
- BLB : blob stuff
- CRC : checksum (md5, sha1, sha2, sha384, sha512, crypto)
- CPDF : pdf handling stuff (using "Coherent pdf" binaries)
- DBG : log writing
- ENV : information about system (os, disks, etc...)
- FS : filesystem stuff
- HEX : hexadecimal stuff
- HTTP : http stuff
- HTML : html stuff
- IC : internet commands stuff
- IO : input / output (import and export, cdv, etc...)
- PDF : pdf printing stuff
- PRM : handling "environment" parameters
- PTR : pointer stuff
- MSG : alerts, messages and progress stuff
- OBJ : object stuff (well this one is Cannon's object module converted 
into a component)
- SEM : semaphore stuff
- SMTP : smtp stuff
- TAB : array stuff
- TXT : text
- XDOC : auto documentation
- XML : xml stuff
- ZIP : 7zip stuff (compression and AES encryption)
- etc.

You get the idea...

Most of theses components are independent to each other.
Few higher level components have "strong coupling" because they explicitly call 
another component. When you use a compiled application, 4D will detect the 
missing component an complain when you open you structure.
Most have a "soft coupling" : most components spit out logs. For this, they 
call the "DBG_component". But this is done with a call to EXECUTE 

Re: Components: How do you reuse utility code? (long)

[David Adams via 4D_Tech]

On Sat, Apr 22, 2017 at 7:40 PM, Bruno LEGAY via 4D_Tech <
4d_tech@lists.4d.com> wrote:

Bruno,

I hope that everyone agrees with me that your post was just fantastic.
Thank you very much for sharing your point of view, specifics about what
you've done, and why. A very substantial and interesting post. I'll read
through it a few more times tomorrow (it is night here.)

Just so people know, I'm being a bit cranky about components, but I'm also
mostly ignorant. So, I'm entirely likely to change my opinion going
forward. Even if I think that I'm right all of the time, it's not that odd
to see me change my mind ;-) In any case, I've tried components since they
were first introduced and then every few versions since. I even had some
components published as tech notes years ago. This time, I decided to dig
in a bit more rather than giving up. So, thanks to everyone for all of the
support, encouragement and information.
**
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
**

Re: Components: How do you reuse utility code? (short)

[David Adams via 4D_Tech]

> If you want to communicate with host and or other components => use
callbacks.

As it turns out, what I am validating is the method name being passed into
the component for a callback! This is a database exploiting CALL WORKER and
CALL FORM to implement a Publish/Subscribe messaging pattern.
**
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
**

Re: Components: How do you reuse utility code? (short)

[David Adams via 4D_Tech]

Bruno,

Thanks a lot for the answer and background info. I think I expressed myself
unclearly regarding errors in my original post. I'm not trying to delegate
error handling to a component. I hadn't really thought about it yet.
Instead, what I'm talking about is a custom error stack that I use. It's
possible for an error handler to push an error onto this stack, but it's
normally done by code. I don't use ASSERT, I use my own precondition checks
and push errors onto my custom stack. ON ERR CALL doesn' really have much
to do with it. Apart from anything else, the ErrorStack code makes my unit
testing a lot easier because one of the outcomes I can test for is the
state of the ErrorStack. How many errors are in there? What names do they
have? (I don't use error codes, they're meaningless. I use error names.)
I'm pretty into testing for exceptions, so my unit tests tend to have lots
of checks on things like out of bounds inputs, bad parameter lists,
malformed parameters, etc. Since the errors are stacked on the ErrorStack,
it's pretty easy to sort out if my tests failed or not. As always, unit
testing is both humbling ("humiliating" might be another word) and
reassuring. I'm pretty happy when I run the tests and turn up a change in
the error name(s) returned. Surprising how many little things slip through
when you recode.
**
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
**

Re: Components: How do you reuse utility code? (short)

[Arnaud de Montard via 4D_Tech]

> Le 22 avr. 2017 à 11:09, Bruno LEGAY via 4D_Tech <4d_tech@lists.4d.com> a 
> écrit :
> 
> [...]
> This may look OTT but there are very few method where this is really 
> necessary[...]

Hi Bruno, 
in system document management I needed a bunch of 'on error call'… 

-- 
Arnaud de Montard 



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

Re: Components: How do you reuse utility code? (long)

[Bruno LEGAY via 4D_Tech]

Hi,

To be honest i am glad there a feeling of curiosity and interest about 
components.
I have seen the light my friends and I am a believer :-)
And there is hope for a "born again 4D component lovers" community.

I find it sad when I hear 4D developers saying that they tried components and 
that they gave up.

Maybe I can share my experience with components.

I have been using components since day 1 (early adopter) and I am *very* happy 
with them.
It really changed the way we write code.

I did a summit presentation in back 2012 Paris about "4D development 
industrialization with components".

And I attended Peter's very good presentation on components last year in 
european summit. Peter is also a fan of components.
Interestingly enough we use it in a difference ways (i'll come back to that), 
but we have encountered the same problems/pitfalls and found some 
solutions/workround. 

A bit of context first...

We are a bespoke developer company, mainly 4D, a bit of Oracle and php/web, 
etc.. (several dev, many projets, across several 4D versions).
We work in remotely (not coding together on the same 4D Server).

Before components we would have a common source library (a shell if you want).
We would move code with insider. But Insider is gone and maybe it was a good 
thing.

Early on, the methods of our library were grouped in modules (which helped us a 
lot to move stuff into components).

I looked into components as an alternative to 4D Insider.

I an idea of what I did not like :
- bloated components
- rely on too many human operations (boring, errors)

And what I wanted :
- reduce duplicated code across projets
- re-use technical code
- improve code quality
- fixe code once and share fixes across projects
- versionning
- avoid naming collision (a sort of namespace)
- performance (using compiled components in interpreted host is great 
compromise)
- logs to diagnose stuff
- documentation
- unit tested code (in an ideal world)
- move more than just code/methods, sometimes resources, etc...
- share code between versions (I don't enjoy moving code and fixes 
across libraries in several 4D versions)
- wanted to simplify updating code when changing 4D version
- modular approach : have access to a collection of component where we 
could choose and pick according to the needs of a given project.

I came to the conclusion, early on, that our code was made into two parts :
- business code
- technical code

The business code is rarely re-used. Also, working on tables, etc... is not 
simple with components (working with SQL or pointers) make things more 
complicated and brittle in my opinion. 
And I have never used component "local" data.
So I don't do business code in components. I know Peter has a different 
approach on this. It is fine, there is no right or wrong. Juste different 
taste, experience, needs and methods.


The technical code is in fact a collection of modules which can be, for the 
most part, independant of each other.
So for instance we have written about 40 to 50 components.

Some projects are using 2 or 3 components. Some are using 30+.

Some are published with source code for free (aws_component for S3 for 
instance).

Some are commercial (ociLib to help coding with 4D for OCI and provide 
retro-comptibilty to the legacy "4D for Oracle" plugin).

The vast majority is private and used internally. 
This is for instance, a part of our collection :
- BLB : blob stuff
- CRC : checksum (md5, sha1, sha2, sha384, sha512, crypto)
- CPDF : pdf handling stuff (using "Coherent pdf" binaries)
- DBG : log writing
- ENV : information about system (os, disks, etc...)
- FS : filesystem stuff
- HEX : hexadecimal stuff
- HTTP : http stuff
- HTML : html stuff
- IC : internet commands stuff
- IO : input / output (import and export, cdv, etc...)
- PDF : pdf printing stuff
- PRM : handling "environment" parameters
- PTR : pointer stuff
- MSG : alerts, messages and progress stuff
- OBJ : object stuff (well this one is Cannon's object module converted 
into a component)
- SEM : semaphore stuff
- SMTP : smtp stuff
- TAB : array stuff
- TXT : text
- XDOC : auto documentation
- XML : xml stuff
- ZIP : 7zip stuff (compression and AES encryption)
- etc.

You get the idea...

Most of theses components are independent to each other.
Few higher level components have "strong coupling" because they explicitly call 
another component. When you use a compiled application, 4D will detect the 
missing component an complain when you open you structure.
Most have a "soft coupling" : most components spit out logs. For this, they 
call the "DBG_component". But this is done with a call to EXECUTE 

Re: Components: How do you reuse utility code? (short)

[Bruno LEGAY via 4D_Tech]

Hi David,

On your original message (sorry for the late response, been very busy this 
week).

First about, component are not russian dolls.

Then about error handling, you need to set up a simple test environment to 
understand how they work.
An error in the component, if not "trapped" will be propagated to the host if 
my memory serves me right.

This is why I tend to things like this in components :

C_TEXT($vt_errHdlr)
$vt_errHdlr:=Method called on error

ON ERR CALL("HTTP__errorHandler") // a private method of the component 

// I know this can generate an error for instance if not connected to internet
$vl_httpStatus:=HTTP Request(...)

// check stuff, log errors, status, timers, request size, response size, 
throughput

ON ERR CALL($vt_errHdlr)


This may look OTT but there are very few method where this is really necessary 
: not connected to internet, disk full, something you cannot predict basically.

On the other hand programming errors like missing parameters, wrong pointer 
type, nil pointers are coding errors and are ASSERTed (fail fast, fail early, 
fail loud).

If you want to communicate with host and or other components => use callbacks.

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

Re: Components: How do you reuse utility code?

[David Adams via 4D_Tech]

On Sat, Apr 22, 2017 at 12:44 PM, Peter Jakobsson via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> A single developer needs to reproduce the same code over again for many
> applications. A component-based approach requires them to distill out and
> de-couple business logic so that it is explicitly addressed in areas that
it
> is only implicitly addressed in a host-only project. This leads to a
quantum
> leap in reliability as well as a huge increase in that developer’s
capacity
> for addressing complex business problems.

What you're describing are the benefits of modularity and data hiding. I'd
argue that there is no more important practical concept in everyday
programming. In 4D, it's hard as the language provides virtually no
assistance and several hinderances. If the component features have helped
you with this, that's great and I doubt that anyone would want to take that
away from you. It's just that some of us have an acquaintance with a larger
range of tools and techniques...that's why we're complaining about the
long-standing (eternal) limitations of the 4D language. So, it's probably
not that we disagree with what you think is good (encapsulation is good),
it's that we disagree that components are particularly good at it (compared
either to some ideal or with standard practice.)

I do like your point about how moving your code into components has
improved how you think about code. Yeah, that makes a lot of sense. And
that's way more  important than any little trick or twiddle with individual
lines or methods.
**
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
**

Re: Components: How do you reuse utility code?

[Peter Jakobsson via 4D_Tech]

Jim -

I read all of your post with interest. But with respect, IMHO it really does 
not do the least bit of justice to the real world applications that 4D’s 
component architecture is designed to address. Nor does it reflect the practice 
of a component based development paradigm.

For example the invocation of the ”domain specific” aspect of 4GL’s is of very 
little use practically because it doesn’t characterise 4D’s industrial context 
in any significant way. SQL has a user interface, an integrated database and a 
reporting function, but look how different it is from 4D in practice. It’s true 
that “4GL”s are a vaguely defined technological concept, but I did outline a 
specific interpretation as I saw relevant in my last post.

On 22 Apr 2017, at 00:47, James Crate via 4D_Tech <4d_tech@lists.4d.com> wrote:

> It’s difficult to imagine having 30 small independent components in a 4D 
> system, and in reality it would be unworkable because then each component 
> would need to include it’s own method to split a string to an array, or 
> descend into the problems of dependent components

Luckily, I have the benefit of not having to imagine the last 10 years of my 
professional life and the associated “descent” into the problems of dependent 
components. On the odd occasion, reality can turn out better than imagination ;)

> IMO that is one of the biggest reasons there is no significant code-sharing 
> or component community in 4D, as compared to almost any other language. There 
> would need to be a “standard library” component that other components could 
> depend on, or they all have to reinvent every wheel.


The “standard library’ you allude to already exists. It’s called the 4D 
language. The bulk of the world's 3GL “standard libraries” are trying to be the 
4D language and they never get anywhere near the level of consistency, version 
continuity or platform support that 4D does. (Otherwise I’d be using them !). 
Beyond that you’re into the business logic layer and the diversity that exists 
therein is the main reason for the lack of code sharing in the community. But 
that doesn’t mitigate the advantages of a formally implemented modular approach.

In that regard, the primary role of 4D components (in my experience) apart from 
re-useability is quality control.

A single developer needs to reproduce the same code over again for many 
applications. A component-based approach requires them to distill out and 
de-couple business logic so that it is explicitly addressed in areas that it is 
only implicitly addressed in a host-only project. This leads to a quantum leap 
in reliability as well as a huge increase in that developer’s capacity for 
addressing complex business problems.

> These are both tight coupling. This is compile-time vs runtime binding. 


Thanks very much ! That is indeed a more accurate description.

> Also, using the term “productive” is kind of amusing when primarily what 
> people would put into a component are the missing parts of the framework 
> (i.e. string trim/split, blob searching, array operations, making C_OBJECT 
> nicer to use)

Although that type of functionality is to be found in 4D component libraries, 
it doesn’t really qualify as ‘canned business logic’ which is where most of the 
benefit is to be had. A more useful (and in my experience typical) example of 
content domains might be:


FINANCIAL
 • double entry bookkeeping logic
 • multi-currency library for managing trial balances
 • dimensional analysis
 • consolidation libraries (multi-company)
 • credit control
 • period management
 • journalling properties
 • caching
 • sales tax

TRADING
 • inventory definition libraries
 • inventory registration
 • revision control
 • location and balance tracking libraries
 • property inheritance (for model-product hierarchies)
 • stock movement journalling definitions
 • trigger and stock error definition

ADDRESSING
 • address book API
 • library support for form embedding

SERVICES
 • http libraries
 • PAYPAL API clients
 • XLIFF generators
 • OAuth libraries
 • Google API clients

MARKUP
 • text processing

DOCUMENTS
 • all kinds of 4D Write wrappers and PDF production

SECURITY
 • generic logic for user logins
 • support for business logic level privileges
 • session tracking libraries
 • privilage-based form configuration support

TIME
 • period algebra libraries (second - day - week - month - year - calendar 
quarter - financial quarter)

MIGRATION
 • data migration/export import by various means (records, blobs, text etc)

UTILITIES
 • RFC support (e.g. 3986, 8601, 4217)
 • path functions (level navigation, multi-platform, joining, splitting)
 • version control
 • property bags (text, blob, object)
 • text DIFFING libraries
 • query canning (caching optimisations, counting, logic cans)
 • string functions  (this is where your string ‘trim/splt’ would go)
 • binary libraries (byte arithmetic, object opacity, colour addition, 
saturation, brightness etc)
 • CODECS
 • 

Re: Components: How do you reuse utility code?

[David Adams via 4D_Tech]

Jim Crate wrote:

> Depends on what you consider 3GL vs 4GL

Yeah, I find the terms unhelpful. They aren't crisp enough to mean anything
useful without a lot of discussion about what you mean by each term first
;-)

> These are both tight coupling. This is compile-time vs runtime binding.

I'm glad that you picked up on that as I missed it. In 4D, it's very common
to see what I think should be called "pathological coupling." It's just bad
coding, regardless of language. As a contemporary point, people should
think through what they pass in messages via CALL FORM and CALL WORKER.
Ideally, the caller *does not know the details of the callee.*

CALL FORM(WindowID;"UpdateButtons")

Seems okay. The target window is asked to update it's button's states.
Presumably the window checks some data and figures out if something needs
changing. If so, it does it. But the caller doesn't know what (if anything
happened.)

CALL FORM(WindowID;"UpdateButtons";"UploadPDFButton";True)

This version tells the remote window to enable the UploadPDFButton. This is
pathological coupling. What happens if:

* You rename the button?
* You want to add more rules for what enables/disables the button? Where do
they go?
* What if you want to call the window to do an update from multiple
locations? Imagine the button flickering on and off.
* What if you get rid of that button altogether?
* What if you add a button to upload as text?

If you go with the first version, all of the logic is in the target
window's control:

CALL FORM(WindowID;"UpdateButtons")

If you go with the second approach, you've got a mess:

CALL FORM(WindowID;"UpdateButtons";"UploadPDFButton";True)


P.S: I'm going to keep offering reminders that CALL FORM and CALL WORKER
don't really send messages. I've written most of my code to make them work
like that, but it isn't what 4D's doing. What 4D is doing is

EXECUTE METHOD IN FORM WINDOW
EXECUTE METHOD IN WORKER
**
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
**

Re: Components: How do you reuse utility code?

[James Crate via 4D_Tech]

On Apr 21, 2017, at 12:41 PM, Peter Jakobsson via 4D_Tech 
<4d_tech@lists.4d.com> wrote:
> 
> On 21 Apr 2017, at 02:44, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com> wrote:
> 
>> 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++.
> 
> In general, I find 4D’s component model immensely powerful - still far more 
> productive than its 3GL equivalents and there isn’t a lot I would change 
> about it.

Depends on what you consider 3GL vs 4GL, I suppose. 4D isn’t really much of a 
4GL, it’s more of a (very) stripped-down 3GL with an integrated database and 
IDE being the only 4GL features. 

Although, there isn’t really much consensus about what makes a 3GL vs 4GL. By 
the strictest definition, a 4GL is domain-specific, so regular expressions and 
SQL could be considered 4GLs, and C, ruby, and python would be 3GLs. 
Objective-C would normally (rightfully) be considered a 3GL, but since it is 
primarily used within the confines of the Xcode IDE with the trappings of 
Foundation and AppKit, it could be considered as 4GL as 4D. 

Also, using the term “productive” is kind of amusing when primarily what people 
would put into a component are the missing parts of the framework (i.e. string 
trim/split, blob searching, array operations, making C_OBJECT nicer to use).  
By comparison, the “components” (gems) I use in Ruby/Rails apps are for 
productive things like generating/expanding zip files, creating CSV files, 
creating PDFs, interacting with external programs/services (LDAP, ImageMagick, 
etc). My Mac/iOS apps so far have been small and focused, but the few 
“components” I’ve used have had laser-like focus onto a specific problem 
domain, which they can do because they do not have to implement basic language 
features.

It’s difficult to imagine having 30 small independent components in a 4D 
system, and in reality it would be unworkable because then each component would 
need to include it’s own method to split a string to an array, or descend into 
the problems of dependent components.  IMO that is one of the biggest reasons 
there is no significant code-sharing or component community in 4D, as compared 
to almost any other language. There would need to be a “standard library” 
component that other components could depend on, or they all have to reinvent 
every wheel.

The worst part is that it didn’t really have to be this way. New commands have 
been added to the language over the years, so the language lacking basic 
features isn’t necessarily because they don’t have “a language guy” or can no 
longer modify the compiler. It’s not that it is too difficult to figure out 
what a basic language framework needs; a function to split a string to an array 
exists in the standard library for every language I have used in the last 20 
years except 4D, Applescript and C/C++ (although most doing C++ would use 
Boost, which includes this). 

Also, with the speed of modern computers, interpreted code can run pretty fast, 
and if they spent some effort to make the interpreter better in the cases where 
it is slow, they may not even really need the compiler. Plenty of code runs 
every day in javascript, ruby and python and is fast enough.


> 1: Tight Coupling
> (Where a component references another component’s method explicitly). 
> Advantages: compiler is made aware of all calls, compiles as reliably as if 
> all methods were host native calls.
> 
> 2: Loose Coupling
> (Where EXECUTE METHOD is used). Advantages: components can be ‘unplugged’ 
> without any compiler complaints.

These are both tight coupling. This is compile-time vs runtime binding. 

An example of loose coupling would be one component publishing a notification 
that it did something, and another component listing for that notification to 
do something in response.  Obviously, sending a notification hoping some 
library will split your string into an array is not the right way to do things. 
Sending a notification that a file has been generated can allow another 
component to email that file to somebody, and a different component could show 
the file to the user, and the component that generated the file and published 
the notification doesn’t even need to know or care if anyone was listening.

Jim Crate

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

Re: Components: How do you reuse utility code?

[David Adams via 4D_Tech]

On Sat, Apr 22, 2017 at 2:41 AM, Peter Jakobsson via 4D_Tech <
4d_tech@lists.4d.com> wrote:

What a fantastic post! Peter, thanks so much for taking the time to share
your point of view and knowledge. This is a help to me now, and an
excellent contribution to the archives.

I've already said my piece, I'm going to try to make components work for me
a bit and see if I can live with them...so I won't qibble or comment. I am
super happy that this conversation has staid so fruitful, depsite me
throwing a trantrum! You guys are all very kind and patient ;-)

> ERROR HANDLING
> I notice David, you were having issues with this, but I think you may
have gravitated straight
> to the exception that’s the most footery aspect of components. (If you
had been eating a lobster,
> it would be like picking of one of those tiny end-claws and trying to get
the meat out of it
> rather than going for the body flesh first :-)).

Heh! Without a doubt, I have a gift. If I try out something new in 4D and
*don't* crash it within an hour, I know I'm doing something wrong ;-)
**
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
**

Re: Components: How do you reuse utility code?

[Tim Nevels via 4D_Tech]

On Apr 21, 2017, at 2:00 PM, Peter Jakobsson wrote:

> On 21 Apr 2017, at 02:44, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com> wrote:
> 
>> 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++.
> 
> Amen to that ;)  What a thread !

Glad you said that. After reading David’s reply I was starting to think my 26 
years of 4D development work and my 4 year computer science degree was worth 
less than I thought it was. 

> I know this may slightly horrendous but it’s actually simpler to implement it 
> may sound as long as you do it in a “lab environment” - plain pair of vanilla 
> structures with hardly any other code in them. It has one huge advantage - 
> you only ever need 1 error handler when you’re working with lots of 
> components. After that, no need to worry about the context (in which 
> component the error occured) so one can go back to being a host developer ;)
> 
> WHAT DO WE NEED CALLBACKS FOR ?
> In 15 years of component developing, here’s a comprehensive list of the only 
> callbacks I’ve ever needed:
> 
>  - FORM GET PROPERTIES
> - Get Pointer (for both objects and fields in a (Table;Field) synta)
> - MENU BAR handling
> - GET PICTURE FROM LLIBRARY
> - ON ERR CALL

Great post Peter. We needed a component expert involved in this discussion. I’m 
not an expert like you. Component work is maybe 2% of my 4D work over the 
years. But like you said, there is a learning curve and once you get past it 
things start to clear up and makes sense. 

It reminds me of when I first started to learn 4D. I was working with a guy 
that had several years of 4D experience. He was my teacher. I was trying to do 
thing in 4D like I had learned in school programming COBOL and Pascal and was 
having trouble. He gave me this advice:

You have to learn how to do it the 4D way. Otherwise you are always swimming 
upstream. Learn how to paddle the 4D boat and you will enjoy the ride a lot 
more. And you’ll get to your destination faster. That changed things for me and 
in 6 months, with his guidance and teaching, I was loving 4D and getting a lot 
accomplished. 

You comments about callbacks is great information for everyone. Some things 
just can’t be done in the component context. You have to create host methods 
and share them and then call those methods from the component to get 
information.

In one component I created that had a UI and included a menu bar I found that 
menu bars share the same address space with the host. So if I have a menubar 
defined in the toolbox in the component with number 3 — or a name it does not 
matter — you can run into trouble. If in the component you call SET MENU BAR(3) 
— and you also have a menu bar 3 in the host — there is a conflict and the host 
menu bar 3 get possessed. Again calling it by a unique name like SET MENU 
BAR(“component menu bar”) does not make a difference because the menu bar has 
an ID of 3 in the component. Here is how to make it work:

C_TEXT($menuRef_t)
$menuRef_t:=Create menu("ISE Quick Report")
SET MENU BAR($menuRef_t)

You have to call “Create menu” from the component. I guess this creates an 
instance of the menu differently that referencing it by ID or name. Whatever is 
happening under the hood, this is how I got it to work.

> Hope that helps…and to David A.,  I hope you manage to stick with it long 
> enough to write another “Joy of Triggers” episode someday !

More likely he’ll call it “50 Shades of Components”. :)

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

Re: Components: How do you reuse utility code?

[Robert McKeever via 4D_Tech]

Remember subtables inside of subtables? (4D v1.xxx). Lots of fun - if used 
right.

> On Apr 21, 2017, at 8:31 AM, Keith White via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
>> If they did care, some of these things could have been added instead of 
>> querying on object fields that most people will eventually wish they didn’t 
>> use in the first place.
> 
> This made me smile a lot.I had exactly the same thought.  It brings back 
> memories of subtables which I'm sure every 4D old-timer regrets ever using, 
> if they ever did.  Someone could compile a list of 4D features with a 
> recommended "steer clear of this to avoid regret later"  ;-)
> 
> To add my 0.02p on components:-
> 
> No.  Don't like them.  Don't use them in our coding.   I'd only ever use them 
> for an essential 3rd Party "drop-in" black-box component that I have no 
> intention of amending the source code for, so much akin to plug-ins.
> 
> Other than that, I can only echo what others have said about wanting the 4D 
> language moved forward a bit.  I do recall that 4D did say at a Paris Summit 
> that they had decided to re-commit to the 4D language.  Adding 
> multi-threading support is possibly a sign of that decision, even though I 
> really dislike their implementation of it.
> 
> Best regards
> 
> Keith White
> Synergist Express Ltd, UK.
> **
> 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
> **

_
Bob McKeever  http://www.mswl.com 
McKeever's Software Wizardry
Port Coquitlam, B.C.
bobmckee...@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
**

Re: Components: How do you reuse utility code?

[Peter Jakobsson via 4D_Tech]

On 21 Apr 2017, at 02:44, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com> wrote:

> 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++.

Amen to that ;)  What a thread !

Great discussion.

I feel I must make at least an attempt to convert David’s component-pain to 
pleasure by recontextualising some of the interpretations of the archetype. Of 
course everyone has their personal priorities and preferences so it’s just my 
take, but I have spent 30% of my living existence doing components so I’ll get 
these points of my chest before any more of it passes me by (Life that is).

In general, I find 4D’s component model immensely powerful - still far more 
productive than its 3GL equivalents and there isn’t a lot I would change about 
it. I haven’t read the whole thread but some general points that spring to mind 
are these:

FLAT vs HIERACHICAL METHOD TIERS

In my view, 3GL - 4GL distinction isn’t to do with language, it’s to do with 
complexity.

In a 4GL (well at least in 4D’s implementation) we are always working within a 
unified top language tier which is flat. It’s therefore right that the 
developer should have to disambiguate between method names amongst components 
because the whole point of the component is that it provides a seamless 
extension to the host (flat) method namespace as opposed to some kind of 
hierarchical class-based extension.

DESIGN TIME vs RUNTIME ARCHITECTURAL CONTEXT
As such, it’s not comparable with say a class library or a DLL or other type of 
3GL code module since 4D components are only given an architectural context at 
runtime. This is a huge advantage over traditional coding structures because 
when we design and build components we’re always working in a host context. 
When we’re developing a component, we should not think like a component 
developer, we should think like a host developer because 4D will do the 
architectural contextualisation for us at runtime. If you start to think 
architecture when you’re building components you’ll get very confused because 
there is no architecture at design time. There are of course odd exceptions to 
this but a tiny number and they *are* exceptions, not the rule (See “NASTY 
STUFF” section at the end of this ramble).

NAMESPACES
Remember, 4D owes much of its productivity to implicit referencing, with the 
proverbial elephant in the room being of course the datafile itself. Current 
selections are implicit (within the scope of a process), globals are, methods 
are, form scripts are, form objects are and resources are to name but a few. 
There are no explicitly referencable namespaces anywhere in the language and 
the reason there aren’t any in components is because it would significantly 
disrupt this highly productive paradigm for very little gain and probably a 
measurable productivity loss. As Tim says, it also conflicts with 4D’s identity 
as a 4GL.

CASCADING DEPENDENCIES
Contrary to some of the concerns I’ve seen expressed, you can have components 
call other components in a hierarchy without any problem. In fact you can have 
2 types of coupling in that regard:

1: Tight Coupling
(Where a component references another component’s method explicitly). 
Advantages: compiler is made aware of all calls, compiles as reliably as if all 
methods were host native calls.

2: Loose Coupling
(Where EXECUTE METHOD is used). Advantages: components can be ‘unplugged’ 
without any compiler complaints.

The optimal choice can also depend on short/long term criteria. If your 
component is going to be used all over the place and potentially only 
occasionally, loose coupling can be better. If the component is a permanent 
resident (e.g. a bookkeeping library in an ERP) then I find tight coupling far 
more reliable.

DESKTOP CONFIG: ALL AT THE SAME LEVEL
The fact that a component doesn’t "on board” its dependencies is a GOOD thing, 
not a deficiency IMO. It confines the dependency hierarchy to the logic, not 
where they happen to be located on the desktop and again reflects the 4GL 
paradigm that all components are ultimately an extension of the host top layer. 
You’d end up with a version control nightmare if you had to install the same 
component in 6 different siblings instead of just once at the host level. So 
again, my view is that 4D have thought this through to give us the best of all 
worlds:

 • We have cascading hierarchical dependency supported
 • We have optimal desktop configuration
 • We have a choice of hard or soft coupling

RESOURCES
How 4D handles these is a thing of beauty IMO and is worth including into the 
overall architectural appraisal. When I researched this for my summit 
presentation I actually blew myself 

Re: Components: How do you reuse utility code?

[Keith White via 4D_Tech]

>If they did care, some of these things could have been added instead of 
>querying on object fields that most people will eventually wish they didn’t 
>use in the first place.

This made me smile a lot.I had exactly the same thought.  It brings back 
memories of subtables which I'm sure every 4D old-timer regrets ever using, if 
they ever did.  Someone could compile a list of 4D features with a recommended 
"steer clear of this to avoid regret later"  ;-)

To add my 0.02p on components:-

No.  Don't like them.  Don't use them in our coding.   I'd only ever use them 
for an essential 3rd Party "drop-in" black-box component that I have no 
intention of amending the source code for, so much akin to plug-ins.

Other than that, I can only echo what others have said about wanting the 4D 
language moved forward a bit.  I do recall that 4D did say at a Paris Summit 
that they had decided to re-commit to the 4D language.  Adding multi-threading 
support is possibly a sign of that decision, even though I really dislike their 
implementation of it.

Best regards

Keith White
Synergist Express Ltd, UK.
**
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
**

Re: Components: How do you reuse utility code?

[John DeSoi via 4D_Tech]

I'm fairly new to components also, and what you describe below is pretty much 
how I'm doing it. Anything reusable goes in one component library. But I want 
to use different subsets of this for different projects. I have "build methods" 
which specify which methods (modules) should be shared for the compiled 
component. So this allows different compiled components to be created with 
different sets of features from the same source structure. I have a parser 
almost done. I will eventually remove all unused code from the component before 
compilation rather than just hiding methods by making them unshared.

John DeSoi, Ph.D.



> On Apr 20, 2017, at 6:32 PM, David Adams via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> 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.

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

Re: Components: How do you reuse utility code?

[David Adams via 4D_Tech]

On Fri, Apr 21, 2017 at 2:45 PM, Tim Nevels via 4D_Tech <
4d_tech@lists.4d.com> wrote:


> Just before I clicked “Send” on my post I thought “this is probably gonna
> crawl under David’s skin, I can’t wait to read his reply”. You certainly
> did not disappoint. :) And that is a smiley face because I was smiling the
> entire time I was reading it.


 Oh fine, be that way. Yup, I feel into your trapglad we actually agree
more than not!
**
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
**

Re: Components: How do you reuse utility code?

[David Adams via 4D_Tech]

On Fri, Apr 21, 2017 at 2:39 PM, James Crate via 4D_Tech <
4d_tech@lists.4d.com> wrote:


> A few more less important things that are in almost every modern language
> that would make coding nicer for everyone, and could be added without
> affecting legacy code:
>


 +1 on your list. And while The Language Guy (TLG) is around, let's get a
few more things done:

--  More operators, like ++ and so on. Why not? That won't break old code.

-- Short-circuit evaluation of conjoined ifs. I don't think that will break
any old code, given how interpretation works now. If it does, a
compatibility setting or drop-dead conversion version seems fair.

And, since TLG has extra time after doing all of these,

METHOD GET PARSE TREE

Just give us a navigable parse tree from the specified method. I mean, the
4D interpreter is already building such a thing and so is the compiler. The
idea is that you get back a version of the code *that is already fully
parsed*. It might have to be XML, as you need nodes to have a type
(command, plug-in, method, constant, etc.) and contents (Open Window, etc.)
I say a tree because that's what would make sense. A branch for each line
and then an interpretation/parse tree for each line. This is handy to have *as
4D sees it*  because 4D follows its own rules. For example, I think it does
evaluations left-right rather than by order of precedence. The interpreter
does this sort of parsing every single day, so it's not like this is a new
feature. What's new is exposing the underlying structure to us for reuse.
With such a command, we would be free to write whatever code-analysis tools
we want.

A thousand flowers bloom.

P.S. Yes, I know about the token format for METHOD GET CODE. Not what I'm
talking about, but glad it exists. The token format doesn't simplify
writing a parser, but it does make writing an accurate parser easier.
**
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
**

Re: Components: How do you reuse utility code?

[Tim Nevels via 4D_Tech]

On Apr 20, 2017, at 10:23 PM, David Adams wrote:

> Tim, I finally said "what the heck" and am giving my blunt opinions below.
> Don't take the torrent as directed at you. I think that you made an
> intelligent and high-level argument. I mean, you're wrong, but at I don't
> hold that against you ;-) That's not an ironic smiley face...I grew up in
> schools where the whole class period might be spent fighting about stuff.
> They thought it was good for us. In a way, it was...in another way, not so
> much.

Just before I clicked “Send” on my post I thought “this is probably gonna crawl 
under David’s skin, I can’t wait to read his reply”. You certainly did not 
disappoint. :) And that is a smiley face because I was smiling the entire time 
I was reading it.

I’m a glass is 1/2 full kind of guy and try to not dwell on the things i don’t 
have. With 26 years of making a living doing 4D work, I really don’t have much 
to complain about. 

> Thanks for the confirmation. This makes 4D components pretty much a
> non-starter for me. I can see how if you know this (and the other)
> restrictions in mind, you could do an okay job. As an example, Cannon's
> Obj_ module isn't a component, but I just compiled it to one and, so far,
> it seems fine.

Current 4D components are a good fit for some things and a horrible fit for 
others. And the only way to find out is to try out your idea. That’s what I’ve 
done. I’ve been about 50% successful on my component projects. Half turned out 
to be a success and I was happy with the end result. Half I had to abandon and 
never finished. I just couldn’t make it work. But I learned a lot by trying 
different things and learning what the limits are. Now if I have an idea for a 
component I have a sense of “I can make this into a component" or "this is 
going to be a problem to make as a component”. 

> Man, wouldn't it be nice if you had a structure defining, oh, let's say a
> process setup:
> 
> $customers := New(ProcessSetup)
> $customers.name  := "Customers"
> $customers.table := ->MyBigArrayOfStuff
> $customers.max_rows := 100
> 
> ...and then the 4D compiler kicks back the obvious error:
> 
>$customers.table points to an array instead of a table.
> 
> So much easier and better than what we have today. Despite using dots,
> that's not an object. It's a typed data structure. We need it, we've always
> needed it, and it's easier than what we've got now.
> 

> And again, I'm not asking for 4D to do a completely new language. No
> thanks, we have a zillion modern languages to choose from. I'm asking for a
> sensible evolution of the language:
> 
> * Data structures that were in Pascal back when 4D was a baby.
> * Exception handling like any sensible language.
> 
> Those two alone would help improve quality by huge, huge amounts.

I totally agree with this. Adding support for Pascal type record structures 
would be so useful. 4D should have done it a long time ago. 

I was hoping the new C_OBJECT variable type would provide that functionality. 
But it falls short in that it lacks strong typing of the record structure 
items. We really need a new C_STRUCTURE variable type. Maybe it could be based 
on C_OBJECT internally but with the addition of typing that the compiler could 
use. 

Throw in a try/catch control structure for exception handling and my glass goes 
from 1/2 full to 3/4 full! 

But alas they have neglected improving the language. It’s just not a priority 
for them now. 

> Sure, but that doesn't mean that they came up with a great solution, albeit
> perhaps the best they could. Given how various features have been
> implemented in the past few years, I don't get the impression they've got a
> language guy on the team. They're a special breed and a bit rare. I never
> hear anything out of France that sounds like they've been thinking about
> the language itself.

I think you are right about that. If they would hire a “language” guy that 
would make a big difference. They wanted to support XML so they hired a guy to 
do that. They wanted to support SQL, so they got a guy for that. If they are 
going to update the 4D language — and the compiler to support it — they need to 
hire a language guy for that. 

> Yes, a linker. That's what's needed. Otherwise, it leaves us with not so
> many great choices. If they did the linker, we would all benefit. Linkers
> aren't exactly a modern tool - there's plenty of existing art out there.

Too bad David Hemmo — Mr. 4D Compiler — is working at Apple now. Now there’s a 
guy who could write an awesome 4D linker.

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:  

Re: Components: How do you reuse utility code?

[James Crate via 4D_Tech]

On Apr 20, 2017, at 9:42 PM, David Adams via 4D_Tech <4d_tech@lists.4d.com> 
wrote:

> And again, I'm not asking for 4D to do a completely new language. No
> thanks, we have a zillion modern languages to choose from. I'm asking for a
> sensible evolution of the language:
> 
> * Data structures that were in Pascal back when 4D was a baby.
> * Exception handling like any sensible language.
> 
> Those two alone would help improve quality by huge, huge amounts.

A few more less important things that are in almost every modern language that 
would make coding nicer for everyone, and could be added without affecting 
legacy code:

string interpolation (handling expressions, not just variables)
modern language constructs like foreach (including foreach on a selection of 
records)
early return, break/continue in loops
named parameters
expanding on things like string functions (why do we all have to write our own 
trim/split/etc methods?)

None of these things would be particularly hard. These things aren’t in the 
language simply because 4D doesn’t care. If they did care, some of these things 
could have been added instead of querying on object fields that most people 
will eventually wish they didn’t use in the first place.

Considering that even the gigantic flaming mess that is PHP managed to strap on 
object oriented functionality without affecting masses of legacy code, it could 
probably be worked into 4D without any real problems as well.

Jim Crate

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

Re: Components: How do you reuse utility code?

[Wayne Stewart via 4D_Tech]

Don't forget the Pascal guy Niklaus Wirth


Regards,

Wayne


[image: --]
Wayne Stewart
[image: http://]about.me/waynestewart



On 21 April 2017 at 11:56, David Adams via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> Speaking of nerd crushes, here are the names of people that I find
> particularly inspirational for the broad and lasting contributions they've
> made (or are making) to our fields. Other people will have their own
> equally sensible lists:
>
> Mike Bostock
> Edsger W. Dijkstra
> Martin Fowler
> Steve McConnell
> Bertrand Meyer
> **
> 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
**

Re: Components: How do you reuse utility code?

[Wayne Stewart via 4D_Tech]

One of the big pluses of EXECUTE METHOD is working around does this exist?
If the component is present run this method if it isn't don't try.

And of course, it completely hides the need for a component from 4D.  This
can be very useful.

On a number of occasions I've tried to open a structure and it says NO -
you need the component, that's it. End of story.  Can't open in interpreted
mode even because the component is missing.

The specific circumstance this occurs is if Comp A needs Comp B but when
launching Host Comp B is not present.  To get around that particular
problem, remove Comp A from Host so it doesn't check Comp A's requirements.



Regards,

Wayne


[image: --]
Wayne Stewart
[image: http://]about.me/waynestewart



On 21 April 2017 at 11:48, David Adams via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> Thanks Wayne, so for development:
>
> MessageHub
>Components
>   ErrorStack
>
> For deployment
>
> Host
> Components
>  ErrorStack
>  MessageHub  (no ErrorStack component here)
>
> Host calls ErrorStack
> MessageHub calls ErrorStack
>
> In development of MessageHub, it calls ErrorStack in its Components folder.
>
> In deployment Host and MessageHub bot call ErrorStack in
>Host/Components/ErrorStack
>
> Is that right? If so, I can deal with that. Seems okay to me. Much better
> than I feared. It looks like it satisfies Tim's rule of components nesting
> to only one level...it's still just one level at a time. If this does work,
> it's because there really is only one project-wide method namespace - so
> whoever looks for a method finds the 'closest' one, I guess.
>
> I won't use the EXECUTE METHOD across components. Sounds like the tool of
> Satan. Not sure, but it smells of sulphur...
> **
> 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
**

Re: Components: How do you reuse utility code?

[David Adams via 4D_Tech]

Speaking of nerd crushes, here are the names of people that I find
particularly inspirational for the broad and lasting contributions they've
made (or are making) to our fields. Other people will have their own
equally sensible lists:

Mike Bostock
Edsger W. Dijkstra
Martin Fowler
Steve McConnell
Bertrand Meyer
**
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
**

Re: Components: How do you reuse utility code?

[David Adams via 4D_Tech]

Tim, I finally said "what the heck" and am giving my blunt opinions below.
Don't take the torrent as directed at you. I think that you made an
intelligent and high-level argument. I mean, you're wrong, but at I don't
hold that against you ;-) That's not an ironic smiley face...I grew up in
schools where the whole class period might be spent fighting about stuff.
They thought it was good for us. In a way, it was...in another way, not so
much.

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

Thanks for the confirmation. This makes 4D components pretty much a
non-starter for me. I can see how if you know this (and the other)
restrictions in mind, you could do an okay job. As an example, Cannon's
Obj_ module isn't a component, but I just compiled it to one and, so far,
it seems fine.

> 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++.

I appreciate your point, but don't forget for a minute that 4D is what it
is. Then again, the language hasn't been improved since the 1980s, and that
has nothing whatever to do with it being a nGL. I tend to think of it as a
structure language because, well, it's sort of a subset of Pascal. Pascal
is famous as a structured language because that's where it comes form. Many
structure paradigms are with us today, albeit in different outfits, and
many new concepts have been added as computer science has advanced.
Structure programming was *obsessed* with the flow of control through the
system and the use of proper control structures. We've got the basics in 4D
(and always have)

If...then...else
Begin...end (in various flavors)
Case of...

That's it. The 4D collection is somewhat simplified, but that's not all
bad. I like 4D's version of the case structure, for example, although a
purist would declare it Forever Unclean! Case was meant to be a clean way
of doing a multi-part if. More like a switch in a lot of languages. 4D lets
you combine different tests in the same structure. Nice, but less easy to
test formally. Back in the Day, Dijkstra and the crew really believed that
it would be possible to prove the correctness of computer programs, like
math proofs. They tried, made a ton of progress, gave us some great ideas
and practices...and realized that formal proofs weren't going to happen.
(The world of formally correct program still exists, but tends not to use
languages anything like Pascal or C++, for that matter.)

Structured Programming wanted there to be a single point of entry for any
method, and a single exit. Again, obsessed with testable and predictable
code. It was a different world, when "GOTO considered harmful" came out,
the basic control structures that we can take for granted didn't exist. We
take them for granted now because they solved a fundamental problem that
didn't change. The point of Pascal was to make the language itself remove
entire categories of problem before they ever happened. (As is the
motivation for many new languages.)

So, way back in the day, before 4D, we had things like:

* Semaphores
* Constants
* Message queues
* Records (structs, the basis of Abstract Data Types, part of what evolved
into Objects)
* Enumerated types
* Domains (custom types defined by a range of possible values)
...and more.

When was this? The late 1970s? I'm not talking about anything particularly
modern or particularly hard. Man, our life would be *so* much easier with
what Pascal called 'records' and C called 'structs." Here, I just dug up a
Pascal example:

type
record-name = record
   field-1: field-type1;
   field-2: field-type2;
   ...
   field-n: field-typen;
end;
Here is the way you would declare the Book record −

type
Books = record
   title: packed array [1..50] of char;
   author: packed array [1..50] of char;
   subject: packed array [1..100] of char;
   book_id: integer;
end;
The record variables are defined in the usual way as

var
   r1, r2, ... : record-name;
Alternatively, you can directly define a record type variable as −

var
Books : record
   title: packed array [1..50] of char;
   author: packed array [1..50] of char;
   subject: packed array [1..100] of char;
   book_id: integer;
end;

4D could throw in with some syntactic sugar to make it look less geeky but,
honestly, how hard is that? It's *vastly* simpler than trying to do
something like that with C_OBJECT. with C_OBJECT, you get a kind of data
structure, but you get *no* help from the compiler on type validation.
Beyond that, the 4D language's incomplete support for JSON makes it
*impossible* to retrofit your own meta-data/schema system to (laboriously)
do your own type 

Re: Components: How do you reuse utility code?

[Wayne Stewart via 4D_Tech]

You can have components calling other components from within a host
database.

Host
Component A
Component B

Option 1:  Easy!
If Component A calls B, then during development of A you need to have a
copy of B in its component folder.  To compile Comp A you must have a
compiled version of Comp B.

Then in the host you have Comp A & B in the host's component folder but not
the Comp B component within the Comp A (as required during development).

Option 2:  Not so easy
Comp A calls B and Comp B calls A
In order to compile A you need a compiled B in A's component folder.  In
order to compile B you need to have a compiled A in B's component folder.
See the problem?
That's where EXECUTE METHOD comes into play.  Using EXECUTE METHOD you can
call B from A and effectively hide it from the compiler.  However there's a
speed hit for that but it is possible.

Last thought:
When building your component please go to the fourth tab (Plugins &
Components) and turn OFF all the plugins and components that you don't
use.  Otherwise you'll get messages about 4D SVG (for example) needing to
be recompiled because you said it was required.



Regards,

Wayne


[image: --]
Wayne Stewart
[image: http://]about.me/waynestewart



On 21 April 2017 at 10:44, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com>
wrote:

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

Re: Components: How do you reuse utility code?

[Tim Nevels via 4D_Tech]

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

Re: Components: How do you reuse utility code?

[David Adams via 4D_Tech]

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

Okay, I've seen it now for the first time. Four 'overrides' are reported -
but there are several dozen 'overrides'.

So, if no conflict is reported, I think the result should be

Everything seems okay.
**
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
**

Re: Components: How do you reuse utility code?

[David Adams via 4D_Tech]

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

Re: Components: How do you reuse utility code?

[Wayne Stewart via 4D_Tech]

Components calling components?
Get used to EXECUTE METHOD, this works and is the easiest way to achieve
this.
Of course it sort of negates the benefits of compiling so don't do it in a
loop!

That's why the Foundation shell went from a bunch of small components in
2003/2004 days to one big component for v11+.  You can still see a lot of
legacy code in the source, checking for the existence of components before
calling it.  This is unnecessary now as it definitely is present!




Regards,

Wayne


[image: --]
Wayne Stewart
[image: http://]about.me/waynestewart



On 21 April 2017 at 09:07, Wayne Stewart  wrote:

>
> On 21 April 2017 at 09:06, Wayne Stewart 
> wrote:
>
>> http://forums.4d.fr/Post//19321897/1/
>
>
> ​Well that link doesn't appear to work (but go to the forum and vote
> anyway).​
>
>
>
> Regards,
>
> Wayne
>
>
> [image: --]
> Wayne Stewart
> [image: http://]about.me/waynestewart
> 
>
>
**
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
**

Re: Components: How do you reuse utility code?

[Wayne Stewart via 4D_Tech]

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



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 

Re: Components: How do you reuse utility code?

[Kirk Brooks via 4D_Tech]

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:  

Re: Components: How do you reuse utility code?

[David Adams via 4D_Tech]

 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 

Re: Components: How do you reuse utility code?

[Arnaud de Montard via 4D_Tech]

> Le 20 avr. 2017 à 08:01, David Adams via 4D_Tech <4d_tech@lists.4d.com> a 
> écrit :
> 
> [...] I've got a standard module called ErrorStack where
> I can, well, stack errors. [...]

I gave up on a "complete" error management embedded in a component, in 4D it 
mostly relies on process variables that are not shared. 
BTW if someone has good ideas to turn around… 

-- 
Arnaud de Montard 


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

Re: Components: How do you reuse utility code?

[Wayne Stewart via 4D_Tech]

David,

I would forget about the error stack idea.

Kirk's thoughts are all good except beware the Object one (putting Cannon's
module in a component).

I did that but… somethings work slightly different, off the top of my head
I can't recall what they are. In the end I just gave up and copied the
module in directly (although I did edit all the comments so they worked
with my Comment writing code).

Normally my components have a 2-3 character prefix which means you still
have a massive 27-28 characters for your method name

For example:
SYN_ServerIdentifier
FND_KVP_Text (Of course when writing a Foundation component you also lose
another four characters).
etc

Like Kirk, I've had no success with inherited forms.

The easiest way is to create a project form which can be copied from
structure to structure and control it with component methods.

An excellent example of this approach is Listbox Magic by Barclay Berry.

This doesn't apply to forms that the component has total control of
obviously.



Regards,

Wayne


[image: --]
Wayne Stewart
[image: http://]about.me/waynestewart



On 20 April 2017 at 17:14, Jim Dorrance via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> I prefix all methods shared with the host with an underscore so I can
> easily see what I have shared.
>
>
> > --
> Jim Dorrance
> jim.dorra...@gmail.com
> 4...@dorrance.eu
> www.4d.dorrance.eu
>
> PS: If you know of anyone that needs an experienced 4D programmer to add
> energy and experience to their team, please let me know. I have
> experience in many areas. Reasonable rates. Remote or Paris only.
> **
> 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
**

Re: Components: How do you reuse utility code?

[Jim Dorrance via 4D_Tech]

I prefix all methods shared with the host with an underscore so I can
easily see what I have shared.


> --
Jim Dorrance
jim.dorra...@gmail.com
4...@dorrance.eu
www.4d.dorrance.eu

PS: If you know of anyone that needs an experienced 4D programmer to add
energy and experience to their team, please let me know. I have
experience in many areas. Reasonable rates. Remote or Paris only.
**
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
**