Re: Defining and documenting Objects

[Chip Scheide via 4D_Tech]

David,
Any chance you might make this system available to the rest of us poor 
and unworthy?
as a component? for a fee?

Chip

On Fri, 12 Oct 2018 15:35:03 +1100, David Adams via 4D_Tech wrote:
> 
> Anyway, with all of that stuff in place, you then can build your own type
> declaration and validation system. The validation is done using *JSON
> Validate* and then a custom checker that reads any extended attributes
> you've designed
---
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing 
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Chip Scheide via 4D_Tech]

I recently went through my code and removed IP vars, to future proof my 
code for pre-emptive possibilities. I went from >500, including sets, 
to 1 which is a set.

Have not done Process vars, still in v13 so

Chip

On Thu, 11 Oct 2018 18:09:23 -0600, Jody Bevan via 4D_Tech wrote:
> 
> Our goal was to have as few of global, and interprocess variables as 
> possible. We got a long way in before we needed more than a few of 
> each. Yes, one of those is for the hiding/showing of listbox rows.
---
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing 
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[David Adams via 4D_Tech]

Just went back and looked at the thread. And, again, I see that there's
huge amount of confusion and murk about what constitutes a "global"
variable. Flow of control, type, and scope are all basic language design
features. Scope in 4D ispeculiar. Scope is typically tied to a
collection of methods that share access to a variable. 4D absolutely,
positively does not have anything like that. It doesn't have any real
notion of data hiding. That's the problem with "globals".

4D has a *runtime* concept of scope where the scope boundary is a process.
That's hard to explain to most people. It's also not something that can
easily be tested in code at rest since it depends on the runtime context
and exact path of execution. It's an inherently unsafe approach compared
with well known alternatives. "Modular" programming is a concept from the
1970s, it's nothing new. And it came out of both best practice, the pain of
project failures, and some really systematic thinking and research.

The ideal goal of scope is to limit the number of methods that can directly
touch an item and the lifetime of a variable. Heck, there are languages
without even the possibility of global variables. One of the thing that
drives people crazy about JavaScript historically is the lack of block
level scope. (Not a concept we have in 4D, nor that really makes sense in
4D.) 4D's feature set is actively antagonistic to anti-global scoping:

* This is why *SET PROCESS VARIABLE* and *VARIABLE TO VARIABLE* are evil.

* With pointers to locals that can escape outside of the current method,
you've now got a hard to figure out level of scope.

* Double for 4D's reference-based dictionaries (*C_OBJECT*.)

The notion that process variables aren't globals and that inter-process
variables are globals is wrong. They're both global, but with a specific
runtime-only boundary called a process. It's a semi-porous boundary that
you can violate without any control at any time with *CALL WORKER/CALL FORM*,
*VARIABLE TO VARIABLE*, and *SET PROCESS VARIABLE. *Alternative design
include benign messaging and function calls. Also nothing new, decades old.

And, as Tim was saying, don't worry about the tiny memory and speed issues,
if there are any. I couldn't measure them in V3 or V6 and doubt that you
can now. Programmers are always guided by their own worst experiences, and
the team developing the server-side of 4D *has different experiences than
we do*. They worry about edge cases. A lot. A whole lot. I'm entirely
sympathetic to this, they really do need to worry about edge cases. Do we
need to worry about the rare cases? Only when we have them. I have them at
the expected frequency. Namely, almost never. It's just silly to design to
edge cases when you don't have to.

With that said, the new *Form* function is *excellent*. Really outstanding,
it's easily one of the greatest things I've seen in V17. I'm also happy to
see 4D finally come around on this. A day nearly 30 years ago now has
always stuck in my mind because it was so awful. Let's just say that the
Engineering team back then was *really* hostile to the idea and lost the
most knowledgeable programmer I ever worked with as a result. Glad they've
seen the light. And thanks to Cannon Smith for the feature request that
seems to have been the genesis of the feature. Oh Canada!
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[David Adams via 4D_Tech]

Keisuke,

Thanks for the quick response, it's always great to hear from you.

Yes, I think you've described exactly the situation. I've got a collection
which is tied to a listbox.
I've got an automatic selected object.
I've got an object display bound to the selected object.
I change the source value in the collection and the binding doesn't fire
all the way through.

Here's where the master data lives:

collection.selected_object.element

The item I've modified via code isn't displayed in the listbox, it's
displayed in a bound variable. The bound variable isn't updating, that's my
problem. Is that the bug you're talking about being fixed? For the
listboxes themselves, I've been calling *REDRAW* and it works well. I've
got a multi-page form and if I switch to a different page and back, the
bound variable redraw is done.

I guess I could update the contents of my bound variable directly but,
honestly, that kind of subverts the whole binding system. Then it's really
unclear what the real data is...plus I don't want my code to have to know
about binding subscribers.



On Fri, Oct 12, 2018 at 3:43 PM Keisuke Miyako via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> Is this about a cell in a collection listbox?
>
> the reason why a redraw needed to be forced (Form.col:=Form.col)
> was related to how ref. counting works,
> in particular,
> when you have an expression defined as the "current item" property.
>
> the current item object can be referenced from another object on the same
> form,
> in addition to the listbox cell itself.
> so when you update that object it by code,
> there was an uncertainty as to whether the original object is meant to be
> updated to retained.
>
> anyway, it should be fixed in ACI0098483
>
> https://bugs.4d.fr/fixedbugslist?branch=17
>
> 2018/10/12 13:35、David Adams via 4D_Tech <4d_tech@lists.4d.com 4d_tech@lists.4d.com>>のメール:
> I was looking for the an answer to "why don't my object variables on
> fields automatically redraw when changed?"
>
>
>
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Keisuke Miyako via 4D_Tech]

Is this about a cell in a collection listbox?

the reason why a redraw needed to be forced (Form.col:=Form.col)
was related to how ref. counting works,
in particular,
when you have an expression defined as the "current item" property.

the current item object can be referenced from another object on the same form,
in addition to the listbox cell itself.
so when you update that object it by code,
there was an uncertainty as to whether the original object is meant to be 
updated to retained.

anyway, it should be fixed in ACI0098483

https://bugs.4d.fr/fixedbugslist?branch=17

2018/10/12 13:35、David Adams via 4D_Tech 
<4d_tech@lists.4d.com>のメール:
I was looking for the an answer to "why don't my object variables on
fields automatically redraw when changed?"



**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[David Adams via 4D_Tech]

I don't follow the list any longer, but I do check in to look for answers.
Today I was looking for the an answer to "why don't my object variables on
fields automatically redraw when changed?" Didn't find it, does anyone have
a workaround? While I was checking on my question, I ran into this massive
thread on objects. As it turns out, I've been working in this area for a
couple of weeks and have a few thoughts to share. I haven't read the whole
thread, so apologies for repetitions. I don't have time for this post...but
here it is anyway. If you care about this issue enough to work on it,
you'll find a bunch of solid ideas in the TL;DR version. I don't have the
time to edit it into something shorter and better, but here is a very short
version:

* 4D's new system leads to very easy to break, brittle, hard to correct
coding problems. By default.

* You can use tables instead of objects. But do you want to?

* 4D dropped the ball on supporting complex types, so we each have to do
all of that work on our own.

* *JSON Validate* can help. Some.

* It takes quite a bit of work to write a custom type definition and
validation system but, if you need quality code, you don't have a better
alternative.

* Use constructors!

TL;DR version:
First off, some background about types. There are only a few very core
issues in language design...you could have spare fingers on one
handtype is one of those core questions. What we've got in 4D:

* Primitive types.
* Arrays of primitives.
* Dictionaries/associative arrays.

We do *not* have compound types nor do we have objects. *C_OBJECT* is a
dictionary, not an object. We need dictionaries, so that's great, but the
name is misleading to many. Anyway, what difference does it make? Well, a
compound type has many, many advantages. It's a collection of elements into
a distinguishable format with *rules*. 4D's tables are the closest thing to
this we've got. But there are tons of times when you really don't want a
table, you want a pure, in-memory structure. Or at least I do. And every
other programmer in history does. Just saying.

What difference does it make that we don't have compound types (structs in
C, records in Pascal, whatever you prefer to call them?) It makes a huge,
huge difference. Here's some of what compound/complex types are good for:

* They're *types *(formally defined data structures) so you can pass them
around and get an interpreter, linter, or compiler to complain if you pass
the wrong type. You know how 4D uses longints for a zillion things, like
window refs, process ids numbers, etc. With a custom type, you could have
windowRef, or processId as distinguishable types. Pass in some rando number
to a method requiring a window reference and get an error from the
interpreter or, depending on how it's all coded, the compiler. I used a
simple type (longint) here as an example, but the same applies to more
complex structures.

* Type can embed rules right into the structured format. In a sense,
objects are complex types with behavior bound in. In a simpler case, you
can add ranges to elements - like "only allow numbers from 1-3" or "only
allow the strings 'Mon','Tue', or 'Wed'", force reals to round to a certain
number of decimal places, etc., etc. Again, 4D tables are the closest thing
a pure-4D programmer will be familiar with. And the field-level constraints
in 4D are pretty painful to use (required, etc.) because of how error
handling is implemented in 4D...so many people don't use field-level
constraints. I don't.

Okay, so we don't have types...how much difference does it make in V17. It
makes a huge difference, as people have clearly noticed already and are
exploring on this thread. I like the new dot notation, but there are some
massive issues with names. Such as:

* If you add a name to an object, the element is added. What if it's a
typo? You get a new element. No error. This is described as a "feature".
Well, sometimes it is a feature, sometimes it's a bug. There's no "strict
mode" choice. That's a missing feature in 4D. Or a design flaw, call it
what you will.

* Case-sensitive. I just can't say how stupid I find this. Has anyone in
history *ever* found this useful? If so, get them away from the keyboard
and put them into management or something where they can do less harm. Pet
peeve. Tabs not spaces people! Spaces, who does that? But I digress from my
digression. 4D says that this is to be "more compatible with JavaScript."
Why? I can't think of any reason. I've spent enough time with JavaScript to
really enjoy some of its features (closures!, some of the
messaging/delegation, the range of normal operators...man 4D needs ++,
etc.), but I've never heard *anyone* outside of 4D point to JavaScript as
an example of what a language should look like. Quite the opposite.

* So, an "object" can have anything in it. Or not. It's a completely
unfixed format. Sometimes that's what you want. Most of the time? I can
hardly think of *any* time I want a 

Re: Defining and documenting Objects

[Jody Bevan via 4D_Tech]

We rewrote our shell (that has been updated ever few version since 3.0 when I 
write the first shell).

Our goal was to have as few of global, and interprocess variables as possible. 
We got a long way in before we needed more than a few of each. Yes, one of 
those is for the hiding/showing of listbox rows.

We really like the freedom of not having to worry about what I call the 
butterfly effect, where a global or interprocess is changed by somewhere else. 
The code is a bit longer to write, but after a few days it became natural to me.

We love objects, and since ObjectTools was first released (years ago) we have 
been using objects. We really pushed the use of objects in our new shell too.

One thing we did in our new shell was to write a bunch of developer tools to 
make our development lives much better. These are:
- Color Picker
- Method Finder (Name, Premptive, or by search words line in the method)
- Object Viewer (we had this years ago), but now we can display it is a 
Developer of Administrator is signed in. What a great way to peak at what the 
values are.
- DevMacros: This is a graphical code picker. So much easier to add those 
common / or not so common code snipets that one needs often or not so often. 
Now instead of hunting through code, or trying to remember what it is called, I 
go to the DevMacros Dialog.
- Error Counter Window: Through all our code we trap for errors. Some errors 
bring up alerts, but others just get recorded in a log. This window shows us as 
we develop if we have encounter an err without disrupting anything.
- The ObjectViewer tells us much about the computer, Admin, User preferences, 
and what is happening in the program. Being able to send this to us from the 
user’s computer, gives us great tools to investigate a problem.

Now v17 comes out. We (Adam) had already written a dot notation module that 
included arrays. So this is not a big attraction. Now that version 17 is the 
last of the 32 bit 4D versions, our current shell could be useful to us and 
others. We will be rewriting our shell in v17 or v18 to make use of ORDA, 4Ds 
dot notation, and the new language. Oh always something to be keeping up with.

Jody

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Keisuke Miyako via 4D_Tech]

the collection type listbox introduces a new "meta" property.

if each row in the list is an object or an entity,
you could have an optional static This.meta property,
which would control properties such as style, colour, disabled, selectable, at 
the row or cell level.

http://doc.4d.com/4Dv17/4D/17/List-box-specific-properties.300-3743666.en.html
http://doc.4d.com/4Dv16/4D/16.4/Managing-List-Box-Objects.300-3978736.en.html

(new: doc.4d.com now has a table of contents on the right 
column)

since the property is an expression, it can also be a method that dynamically 
returns an object with the relevant properties.
but this feature assumes all rows are visible (it can be disabled or inactive).

collection type listboxes are really productive when used with collections, 
ORDA and object notation.

one noticeable disadvantage compared to array type
is the automatic row height feature (4D View Pro license),
but maybe "hidden row" is another one.

that said, the hidden row feature was created to quickly display a filtered 
sub-selection of a large array.
since collections can be filtered, expanded or even swapped and restored,
I don't think the "hidden row" will be that missed.

notice also that the "hidden row" boolean array have been superseded by the 
"control row" longint array,
a combined value that controls 3 properties (hidden, enabled, selectable)

2018/10/12 6:05、Kirk Brooks via 4D_Tech 
<4d_tech@lists.4d.com>のメール:
Second - can you do that with a collection or object based listbox?



**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Kirk Brooks via 4D_Tech]

Olivier,
First - nifty hack.
Second - can you do that with a collection or object based listbox?

On Thu, Oct 11, 2018 at 11:15 AM Olivier Flury via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> Well, not sure if this is what you need, but you can insert a dynamic
> column into a list box, get a pointer to it and define this column as
> control array/column for hiding/showing rows.
>

-- 
Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

AW: Defining and documenting Objects

[Olivier Flury via 4D_Tech]

Well, not sure if this is what you need, but you can insert a dynamic column 
into a list box, get a pointer to it and define this column as control 
array/column for hiding/showing rows.

http://doc.4d.com/4Dv16/4D/16.4/LISTBOX-SET-ARRAY.301-3978698.en.html

I use this a lot, e.g. in custom popup/dropdowns to display matches by hiding 
the non-matches.

Olivier

|| https://flury-software.ch/

-Ursprüngliche Nachricht-
Von: 4D_Tech <4d_tech-boun...@lists.4d.com> Im Auftrag von Dennis, Neil via 
4D_Tech
Gesendet: Donnerstag, 11. Oktober 2018 16:34
An: 4D iNug Technical <4d_tech@lists.4d.com>
Cc: Dennis, Neil ; Bernd Fröhlich 
Betreff: RE: Defining and documenting Objects

> I LOVE it that there are no longer ANY global variables necessary when 
> working with forms 

Is there a way to do hidden rows in a list box? So far I have not found a way 
and still have to use a process array. If you know of something please share.

Neil

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Kirk Brooks via 4D_Tech]

Neil,
You are correct. I think this is an example of how deep the changes are to
accomplish ORDA. But there are a lot of changes in the works on forms (viz
dynamic forms) so it will probably change too.

On Thu, Oct 11, 2018 at 7:33 AM Dennis, Neil via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> > I LOVE it that there are no longer ANY global variables necessary when
> working with forms
> Is there a way to do hidden rows in a list box? So far I have not found a
> way and still have to use a process array. If you know of something please
> share.
>

-- 
Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Defining and documenting Objects

[Bernd Fröhlich via 4D_Tech]

Dennis, Neil:

>> I LOVE it that there are no longer ANY global variables necessary when 
>> working with forms 
> 
> Is there a way to do hidden rows in a list box? So far I have not found a way 
> and still have to use a process array. If you know of something please share.

Sorry, maybe my enthusiasm got a bit far. Maybe you still need a global for 
this.
(Never tried that.)

Greetings from Germany,
Bernd Fröhlich
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Benedict, Tom via 4D_Tech]

Peter Jakobsson so eloquently writes:

>The original selling point of 4D was that it was stateful and that 
>statefullness
>is what gave us massive productivity gains. Lower level languages like the
>Microsoft developer platforms, Delphi and even Javascript/Python type
>environments had the versatility but you had to pay the price in coding
>according to the classic, stateless styles. 4D is now allowing us to do stuff
>you could do in these languages but there's a great big banana skin potentially
>associated with that transition which is productivity. For example when I 
>started
>building widgets in 4D, they could be "very nice" but my productivity 
>absolutely
>plummeted since you need to spend most of the time on designing plumbing
>systems, event models and custom data structures instead of solving business
>problems which have traditionally been the 4D developer's domain.

And if you give up that advantage, why develop in 4D at all?

Can you imagine living without the Current Selection?

Tom Benedict
Optum
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Benedict, Tom via 4D_Tech]

Koen Van Hooreweghe writes:

>Objects can be 'exported' to JSON quite easily: $json_text:=JSON 
>Stringify($4Dobject) Then you can expose this text data to the external system.

>The other way around is: $4Dobject:=JSON Parse($json_text)

>I really advise the step up to v15 and further. Objects are quite fun to work 
>with...

They do look useful. Wouldn't work for ODBC access, obviously. I'll check 'em 
out.

Tom Benedict
Optum
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Tim Nevels via 4D_Tech]

On Oct 11, 2018, at 9:37 AM, Peter Jakobsson wrote:

> I think I might happily pay the price of recreating the variable table for 
> every process (since I never noticed any adverse effect of that) and use 
> naming conventions to avoid conflicts to get those features ! ;)
> 
> The original selling point of 4D was that it was stateful and that 
> statefullness is what gave us massive productivity gains. Lower level 
> languages like the Microsoft developer platforms, Delphi and even 
> Javascript/Python type environments had the versatility but you had to pay 
> the price in coding according to the classic, stateless styles. 4D is now 
> allowing us to do stuff you could do in these languages but there’s a great 
> big banana skin potentially associated with that transition which is 
> productivity. For example when I started building widgets in 4D, they could 
> be “very nice” but my productivity absolutely plummeted since you need to 
> spend most of the time on designing plumbing systems, event models and custom 
> data structures instead of solving business problems which have traditionally 
> been the 4D developer’s domain.
> 
> Just a thought.
> 
> Sometimes it’s difficult to tell novelty value and practical value apart. 
> (Well it is for me at least :-) )

I agree with Peter that sometimes it just makes sense and is much less of a 
hassle to use a process variable, or an interprocess variable. I know exactly 
how they work and their limitations. And I know the benefits of using them and 
when it could cause “issues” in what I’m building. Taking all those 
considerations into account I make the decision to use them or not. No regrets. 
Do the work and move on.

I know some developers will say “yeah, but them damn process variables use 
memory, precious memory”. Or they might say “it takes time, precious micro 
seconds of time, to instantiate the process variable table for each new 
process”. OK. 

So you are in an environment where you have to worry about a few megabytes of 
extra memory being used? You sure about that? Every machine any of my 4D 
databases currently run on has at least 8,000MB of memory to use. I really 
don’t care if I were to “waste” even 20MB. So I disregard the wasting memory 
argument in most situations.

And as for wasting time, we don’t even need to go there with the massive power 
current hardware has. 

If you want to talk about wasting time and memory, consider the “hard core” 
developer that believes in “functionalizing” their code and keeping methods 
very small and with limited scope. So they literally have 10,000+ methods to 
work with. And the call stack to perform an operation may be 10+ levels deep. 
That’s 10 stack frames of memory and 10 method calls to build up and tear down 
and memory movement to pass parameters, etc. These developers think this is a 
good waste of memory and time. Maybe it is, maybe it isn’t. The point I’m 
making is nobody is noticing that this is faster or slower with today’s 
hardware. 

We ain’t running on 25Mhz 68040 processors with 4MB of RAM any longer. (Thank 
God!) So let’s just focus on getting the work done as efficiently as we can and 
be as productive as we can. Use the tools 4D provides and the ones that make 
you the most productive. That’s my approach. Get the work done, bill the 
customer a very reasonable amount, and move on. For me that has resulted in 
many years of happy clients and repeat business. 

My philosophy on new 4D features is that it is just another tool for my 
toolbox. That is all. The new features are not necessarily “better” than doing 
it the “old way”.

I can remember back in the 4D v2 days when there was only one way to do many 
things in 4D. No choices. I’m so happy that now we have so many choices and 
ways to do things.

Tim

*
Tim Nevels
Innovative Solutions
785-749-3444
timnev...@mac.com
*

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Defining and documenting Objects

[Dennis, Neil via 4D_Tech]

> I LOVE it that there are no longer ANY global variables necessary when 
> working with forms 

Is there a way to do hidden rows in a list box? So far I have not found a way 
and still have to use a process array. If you know of something please share.

Neil



--


Privacy Disclaimer: This message contains confidential information and is 
intended only for the named addressee. If you are not the named addressee you 
should not disseminate, distribute or copy this email. Please delete this email 
from your system and notify the sender immediately by replying to this email.  
If you are not the intended recipient you are notified that disclosing, 
copying, distributing or taking any action in reliance on the contents of this 
information is strictly prohibited.

The Alternative Investments division of UMB Fund Services provides a full range 
of services to hedge funds, funds of funds and private equity funds.  Any tax 
advice in this communication is not intended to be used, and cannot be used, by 
a client or any other person or entity for the purpose of (a) avoiding 
penalties that may be imposed on any taxpayer or (b) promoting, marketing, or 
recommending to another party any matter addressed herein.
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Jim Dorrance via 4D_Tech]

I have no menus in my current work, menus for a form are built dynamically
"On Activate", disposed of "On Disactivate". The menu ref is kept in a form
variable, and is used on contextual click to pop-up the current menu. Don't
hesitate to ask if there are any questions.
-- 
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)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Kirk Brooks via 4D_Tech]

Bernd,

On Wed, Oct 10, 2018 at 11:49 PM Bernd Fröhlich via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> there are no globals required for menus (I assume here that you are
> talking about popup menus in the form).
>

So true. This deserves its own thread. In fact unless you have some
extended lookups to do building menus is fast, (has been) fast enough to do
on-the-fly in response to a user click for a long time. I think a lot of us
learned about installing menu bars a long time ago and never stopped to
look at alternatives.

There are good reasons to move form controls onto the Form instead of
maintaining controls and commands in the menu bar. Off the top of my head:

* large/multiple screens: it's a complete PITA to have a form open on the
lower right of a big screen and have to mouse to the far upper left corner
for some command.

* easier for users to see commands relevant to their immediate action on
the form.

* easier for you to keep track of.

* easier to adjust menus to specifics of user permission, form state, user
prefs, etc.

* easier to make menus context sensitive.

Granted I'm assuming the overall design of the project has a modern look:
multiple windows and responsive design. If you're still using MODIFY
SELECTION/RECORD type design it probably doesn't matter as much
aesthetically though I stand by the issues of managing them.

Just give them an objectname, get a pointer in the "on load" phase with
> Object Get Pointer and define the array using that pointer.
> Works great.
>
So true. And you can release a menu immediately after you use it, there's
no particular advantage to keeping them.

$menu:=Create menu

- build it -

$result:=Dynamic pop up menu($menu) // present to user

RELEASE MENU($menu)

Case of  //  manage the choice

  :($result="doThis")
   ...

End case

I do this this response to user clicks and contextual clicks all the time
and I've never had a memory leak. It makes popping up menus on listboxes,
buttons or any active object (that's a picture too) very easy to manage.
And you can also use Dynamic pop up menu to present a menu designed in the
menu editor.


> I LOVE it that there are no longer ANY global variables necessary when
> working with forms, even if the form has to give some information back to
> the calling method.
> Just put that information in the Form-object and you get it back in the
> object that you passed into the form with the DIALOG command.
>

Agree completely. I find it useful to have a single process variable - an
object (I call it 'prosObject') which I use for persisting data. Pre v17
this can be used like (not equivalent to) the new Form object - it's just
there all the time. Very handy for passing parameters to a dialog I popup
for information, for example. Or for complex forms with many subforms where
each subform provides details, lookups or whatever for the larger data
object. Plus this makes it easy to have a single subform object and simply
install the relevant subform when needed.

I adopted Canon's OBJ Module to make set/get method to this object for
convenience. eg. ProsObj_SET_TEXT("some.property";"some value for it").
Code using this approach translates well to v17 and the technique can work
going back to v14.

I also very much like being able to look at it. It's a huge advantage when
working with some complex data structure to be able to open a dialog and
see all the elements. Possible but not easy if each element were its own
process var. Plus I like being able to copy it to my text editor.

>
> I think this is the best change since making pointers to local variables
> available.
>
Yes.

-- 
Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Peter Jakobsson via 4D_Tech]

> On 11 Oct 2018, at 12:02, Bernd Fröhlich via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> All true, but with globals you can have hard to find side effects.
> E.g. i have a lot of buttons and other variables on a lot of forms use 
> "standard" global variables (bOK, bCancel, bSave, bPrint, bWhetever) so that 
> I don´t have to define new globals for each form.
> 
> Now and then it happened, that one form changed one of those variables that 
> was also used by another form. Good luck with finding those bugs because they 
> only happen now and then and are seldom reproducable.
> Using only dynamic variables in my forms saves me from those headaches.

Ok, thanks for that clarification - I can see your reasoning.

But just as a bit of philosophical fun, imagine if things were the other way 
around. Since v1 we had always been using objects and you needed to use 
accessor commands to do absolutely anything with either data or active form 
objects. Then one day 4D, after 25 years, 4D came along with this great new 
feature - a built in wrapper for the object accessors (called a “global 
variable") that sported a host of great productivity advantages:

 - maintains state for you without any coding (no laborious “sets” and “gets” 
anymore)
 - a single point of reference for the property instead of tens or hundreds of 
local variables capturing the same property, all with potentially different 
names and contexts
 - compiler support for typing to detect bugs “ahead of time”
 - design time find, replace and rename support - again with a single point of 
reference

I think I might happily pay the price of recreating the variable table for 
every process (since I never noticed any adverse effect of that) and use naming 
conventions to avoid conflicts to get those features ! ;)

The original selling point of 4D was that it was stateful and that 
statefullness is what gave us massive productivity gains. Lower level languages 
like the Microsoft developer platforms, Delphi and even Javascript/Python type 
environments had the versatility but you had to pay the price in coding 
according to the classic, stateless styles. 4D is now allowing us to do stuff 
you could do in these languages but there’s a great big banana skin potentially 
associated with that transition which is productivity. For example when I 
started building widgets in 4D, they could be “very nice” but my productivity 
absolutely plummeted since you need to spend most of the time on designing 
plumbing systems, event models and custom data structures instead of solving 
business problems which have traditionally been the 4D developer’s domain.

Just a thought.

Sometimes it’s difficult to tell novelty value and practical value apart. (Well 
it is for me at least :-) )

Regards

Peter

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Bernd Fröhlich via 4D_Tech]

Peter Jakobsson:

> Out of interest, what advantages does this give you over using a global ? The 
> advantage of a global to me is that it preserves state throughout the life of 
> the form without any coding. (For example you don’t need to keep using Object 
> get Pointer(“myPopUp”) all over the place to re-create the state). Also, 
> using globals lets you do a lot of type-based debugging at compile time.

All true, but with globals you can have hard to find side effects.
E.g. i have a lot of buttons and other variables on a lot of forms use 
"standard" global variables (bOK, bCancel, bSave, bPrint, bWhetever) so that I 
don´t have to define new globals for each form.

Now and then it happened, that one form changed one of those variables that was 
also used by another form. Good luck with finding those bugs because they only 
happen now and then and are seldom reproducable.
Using only dynamic variables in my forms saves me from those headaches.

Also you don´t have a huge variable-table for each new process because 4D 
creates that table for every global variable in every process.

You have a point about using Object get Pointer to get access to the variables, 
but most of the time that is only necessary in the form method, since I handle 
almost everything in that method.

> If we take this to its logical conclusion won’t we just end up with Delphi, 
> .NET or Python instead of 4D ? (i.e. a low level environment that’s extremely 
> versatile but far less productive).

I don´t know those languages, but I can see nothing low level about 4Ds 
approach. Quite the opposite in fact.

Just my two Eurocent.

Greetings from Germany,
Bernd Fröhlich
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Koen Van Hooreweghe via 4D_Tech]

Hi Tom,

Objects can be 'exported' to JSON quite easily: $json_text:=JSON 
Stringify($4Dobject)
Then you can expose this text data to the external system.

The other way around is: $4Dobject:=JSON Parse($json_text)

I really advise the step up to v15 and further. Objects are quite fun to work 
with...

HTH
Koen

> Op 10 okt. 2018, om 22:15 heeft Benedict, Tom via 4D_Tech 
> <4d_tech@lists.4d.com> het volgende geschreven:
> 
> I'm stuck on v13.x, so I haven't had an opportunity to learn much about 4D 
> objects. One thing that I would be interested in is how easy it is to expose 
> data in objects to external non-4D systems. Can I pass an object as a 
> response to a web service call from a .Net app and have the JSON or whatever 
> form the object takes be meaningful? Or does that even make sense?




Compass bvba
Koen Van Hooreweghe
Kloosterstraat 65
9910 Knesselare
Belgium
tel +32 495 511.653

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Peter Jakobsson via 4D_Tech]

> On 11 Oct 2018, at 08:49, Bernd Fröhlich via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> there are no globals required for menus (I assume here that you are talking 
> about popup menus in the form).
> Just give them an objectname, get a pointer in the "on load" phase with 
> Object Get Pointer and define the array using that pointer.

Hi Bernd

Thanks for that tip. I will experiment with your approach.

Out of interest, what advantages does this give you over using a global ? The 
advantage of a global to me is that it preserves state throughout the life of 
the form without any coding. (For example you don’t need to keep using Object 
get Pointer(“myPopUp”) all over the place to re-create the state). Also, using 
globals lets you do a lot of type-based debugging at compile time.

If we take this to its logical conclusion won’t we just end up with Delphi, 
.NET or Python instead of 4D ? (i.e. a low level environment that’s extremely 
versatile but far less productive).

Regards

Peter

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Bernd Fröhlich via 4D_Tech]

Peter Jakobsson:

> So what I’m doing now is just using a single object to hold all form 
> properties that I’d previously used globals for. Then just use globals where 
> required for active objects like menus.

Hi Peter,

there are no globals required for menus (I assume here that you are talking 
about popup menus in the form).
Just give them an objectname, get a pointer in the "on load" phase with Object 
Get Pointer and define the array using that pointer.
Works great.

I LOVE it that there are no longer ANY global variables necessary when working 
with forms, even if the form has to give some information back to the calling 
method.
Just put that information in the Form-object and you get it back in the object 
that you passed into the form with the DIALOG command.

I think this is the best change since making pointers to local variables 
available.

I also love the .-notation for entity-selections. Now you can have multiple 
selections of one table that don´t overwrite each other.

V17 is really great (except for WritePRO which definitely needs several updates 
befor beeing able to replace 4D Write, but that´s another discussion. For now 
the old 4D Write still works in V17(32 Bit), so I am a very happy camper at the 
moment :-)

Greetings from Germany,
Bernd Fröhlich
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Benedict, Tom via 4D_Tech]

> On 5 Oct 2018, at 09:15, Paul Dennis via 4D_Tech 
> <4d_tech@lists.4d.com> wrote:
>
> With tables and records and the structure it's relatively
> straightforward to track through the code and work out what's going
> on. I can see this being a real problem with objects. There just
> doesn't seem to be any visibility. The data could be buried many
> layers down in an object let alone all the quotes, dots and semi
> colons involved

I'm stuck on v13.x, so I haven't had an opportunity to learn much about 4D 
objects. One thing that I would be interested in is how easy it is to expose 
data in objects to external non-4D systems. Can I pass an object as a response 
to a web service call from a .Net app and have the JSON or whatever form the 
object takes be meaningful? Or does that even make sense?

Tom Benedict
Optum
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Peter Jakobsson via 4D_Tech]

Hi

This is a good point made by Paul...

> On 5 Oct 2018, at 09:15, Paul Dennis via 4D_Tech <4d_tech@lists.4d.com> wrote:
> 
> With tables and records and the structure it's relatively
> straightforward to track through the code and work out what's going on. I
> can see this being a real problem with objects. There just doesn't seem to
> be any visibility. The data could be buried many layers down in an object
> let alone all the quotes, dots and semi colons involved


I also agree with Kirk’s last post about unncecessary redundancy when you have 
a perfectly working programming paradigm already - and they do indeed take some 
documenting (at least in the code) - and you can get yourself tied in knots, 
especially when you go even one level of object hierarchy.

Despite that, I have recently taken the leap to using objects as arguments in 
methods and passing parameters “by name” rather than using $1..$N.

I did this because Laurent Ribardierre and JPR recommended this approach so 
categorically at the last advanced developers class. Also, when they demoed the 
new features of v17 and I saw the roadmap I can kind of see why - 4D want to 
drastically loosen the coupling between the forms layer, the code and the 
database engine. So what I’m doing now is just using a single object to hold 
all form properties that I’d previously used globals for. Then just use globals 
where required for active objects like menus.

You can preserve some of the formality of the old “$1…$2” approach by writing 
wrappers to “receive” the object properties and simultaneously “define” the 
form parameters - so that an error can be thrown is something’s missing from 
the mandatory argument list for example. But one of the advantages of this new 
approach I’ve noticed is massive flexibility when it comes to initialising the 
form. It’s much easier to refactor or add/remove parameters. (Say you had a 
function that opened the form and that function took some initial states as 
$1…$n. Just passing a single object instead saves having to support the 
argument list right up and down the call chain.

Also, I’m still on v15 but at the end of the day the new dot notation 
referenced object properties will not be much different from the old global 
variable approach.

Peter

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Paul Dennis via 4D_Tech]

Kirk,

Good point, well made.
Paul



--
Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Kirk Brooks via 4D_Tech]

Paul,
You know it's perfectly acceptable to just not even worry about it.
Personally I never wrote a SOAP API or client and it looks like I never
will. :-)

If you don't need dot notation and don't see anything on the horizon that
will require it spend that time doing other things. I've seen some
implementations of objects and dot-notation that really did nothing useful
except inject new techniques into a stable environment with no particular
benefit.

This reminds me of a former neighbor in our condo and I talking about some
work that needed to be done to the property. We were going over the options
and extent of the work. Not surprisingly I tended to want to make things
perfect and last forever. He heard me out and simply said at his age, "it
only has to last as long as I do." Whether that's short sighted or profound
it's a perfectly valid point of view.

On Fri, Oct 5, 2018 at 12:15 AM Paul Dennis via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> I've been thinking about it more from the point of practicalities than the
> coding. I understand how we can create documentation of the objects. My
> problem is three years down the line when you revisit some old code written
> by third-party. With tables and records and the structure it's relatively
> straightforward to track through the code and work out what's going on. I
> can see this being a real problem with objects. There just doesn't seem to
> be any visibility. The data could be buried many layers down in an object
> let alone all the quotes, dots and semi colons involved. I think my first
> step is to have another eye test.
> Paul
>
> --
Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Paul Dennis via 4D_Tech]

I've been thinking about it more from the point of practicalities than the
coding. I understand how we can create documentation of the objects. My
problem is three years down the line when you revisit some old code written
by third-party. With tables and records and the structure it's relatively
straightforward to track through the code and work out what's going on. I
can see this being a real problem with objects. There just doesn't seem to
be any visibility. The data could be buried many layers down in an object
let alone all the quotes, dots and semi colons involved. I think my first
step is to have another eye test.
Paul



--
Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Kirk Brooks via 4D_Tech]

If anyone is a little intimidated about writing JSON validation schema from
scratch (I am) there are some online resources to assist. One that's
particularly easy to use is

https://www.jsonschema.net/

On this site you can paste in a properly formatted JSON and the site will
infer the schema. The result may not be perfect but gives you framework and
an example to work with.

On Thu, Oct 4, 2018 at 7:50 AM Keisuke Miyako via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> the recommended way to so this in 4D is to use JSON Validate.
> http://doc.4d.com/4Dv17/4D/17/JSON-Validate.301-3730393.en.html
>

-- 
Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Keisuke Miyako via 4D_Tech]

as a general rule,
if objects are meant to share a common structure,
the choice should be to use a record, not a single object field.

the closest thing we have to a "class" in 4D is a table, not an object.
http://doc.4d.com/4Dv17/4D/17/Dataclasses.300-3777698.en.html

2018/10/04 23:24、Chip Scheide via 4D_Tech 
<4d_tech@lists.4d.com>のメール:

3 -  You could run a method at shutdown (during development) which
would document/comment every object field. This information
(object.content) could be put into the table's object field(s)
comment(s), and/or into a separate comment only method outlining the
structure of every object field.


**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Keisuke Miyako via 4D_Tech]

the recommended way to so this in 4D is to use JSON Validate.
http://doc.4d.com/4Dv17/4D/17/JSON-Validate.301-3730393.en.html

the structure of an object can be defined using a JSON schema,
a blueprint of a class of object, itself written in JSON.

kind of like what XSD or DTD are to XML.

https://en.wikipedia.org/wiki/XML_Schema_(W3C)
http://doc.4d.com/4Dv15/4D/15.6/DOM-Parse-XML-source.301-3817445.en.html

the type of value is far granular than native JSON,
you can have integer, date, etc.

you can specify value limitations (max, min, between),
use regex or simple wildcards.

it can even have internal cross references (a.k.a. JSON pointers).

essential reading:

https://blog.4d.com/validate-your-json-object/
https://blog.4d.com/a-new-tool-json-validator/
https://blog.4d.com/working-with-json-pointers/

2018/10/04 23:24、Chip Scheide via 4D_Tech 
<4d_tech@lists.4d.com>のメール:

2 - For Objects, I would think that extending this idea to the object
itself would be useful, and valuable.
-- I would think that installing as the first property/value of the
object a definition of the contents of that object would allow for each
object to be 'self documenting' and might even lead to very generic
code. In this way you could blindly access the values in an object. Any
value in the object which is not 'documented' as part of Object.content
effectively would not exist.



**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Chip Scheide via 4D_Tech]

I do not use objects - not up to a version of 4D that supports them, 
yet.

My thought on handling documentation of an object's contents... this is 
probably worth what you are paying for it...  :)
1 - In every system, or component install a comment only method 
outlining your conventions. This contains all of your system's naming 
conventions, standards etc. This puts the needed information easily 
available to the programmer(s).
I use a method called "__Conventions" as this tends to be the first 
method in the method list.

2 - For Objects, I would think that extending this idea to the object 
itself would be useful, and valuable.
 -- I would think that installing as the first property/value of the 
object a definition of the contents of that object would allow for each 
object to be 'self documenting' and might even lead to very generic 
code. In this way you could blindly access the values in an object. Any 
value in the object which is not 'documented' as part of Object.content 
effectively would not exist.

i.e.
My_Object.Content --> a text(? or whatever floats your boat) value 
containing all of the expected/allowed values in the object.

3 -  You could run a method at shutdown (during development) which 
would document/comment every object field. This information 
(object.content) could be put into the table's object field(s) 
comment(s), and/or into a separate comment only method outlining the 
structure of every object field.

3a - you could wrap the commands to create a new object (not a field) 
that would grab or take as a parameter the object's content) 
Object.content and place it into 1 comment only method for all dynamic 
objects, or into a 'module' specific comment only method (again only 
during development).

Thoughts?

Chip

On Thu, 4 Oct 2018 02:45:36 -0700 (MST), Paul Dennis via 4D_Tech wrote:
> Thanks Kirk, I was afraid you were going to say that. Ive got multiple
> developers on our app all with different habits plus me and I am the worst.
> I have to give this some thought.
> 
> 
> 
> --
> Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
---
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing 
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Paul Dennis via 4D_Tech]

Thanks Kirk, I was afraid you were going to say that. Ive got multiple
developers on our app all with different habits plus me and I am the worst.
I have to give this some thought.



--
Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Aparajita Fishman via 4D_Tech]

> BTW, I mimicked the OT GetArrayLong/Text/Date* commands and the Find in
> array command from Object Tools in my copy of OBJ_Module. The approach that
> I took was to extract the array from the object and do a find in array and
> I was thinking that, perhaps, that would incur a penalty. I don't have the
> metrics handy but, until it got into the thousands of hits, the operation
> was essentially instantaneous. And the reason, as 4D has pointed out over
> the years, is that we're dealing with references to data not the actual
> data itself so it's not a question of moving data in memory.

You *are* moving memory if you extract the array from an object. Not a huge 
amount, but not nothing. I’m not sure what the motivation was for implementing 
those commands yourself, but whatever.

- Aparajita
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Defining and documenting Objects

[Kirk Brooks via 4D_Tech]

Paul,
You touch on an excellent point about using objects. At the heart of it is
your naming convention. We haven't had to worry about naming too much in
the past. Variable names aren't case sensitive and you could always use the
COMPILER_ methods to document the IP and process variables. And the same is
true for the object variables themselves.

When it comes to the properties (or keys as in key:value) it's a different
story. Starting with them being case sensitive. I find a difference in how
I handle this between being able to handle native dot notation and not. The
difference being in v15 I used constants for (not IP vars) key names. You
can still do this in v17 but it's less useful. Looking through some
projects here are the main schemes I use for documenting how an object is
structured.

1) a disk file
Add a folder to Resources and keep templates for various objects there. Or
a single file with templates listed as objects. I do this for large
templates, for objects with lots of default data, for objects I want to be
able to configure for specific instances and for objects defined by some
other service I communicate with. Reading them is fast. Fast enough to use
when loading a form, for example, though obviously I wouldn't do this
inside a loop.

Working with large objects benefits by being able to open them in my text
editor. A line like:

$account_id:=$obj.source.data[2].customer.preferences.account.number

is easier for me when I can be looking at the object. Especially if it's
from some other source (like a API call).

2) in the method header
Perfect for defining keys as parameters.

// MyMethod (object)

// $1: { date: , person_id: , query_str: }

Handy because it pops up in the method editor to remind me what the keys
are.

I also do this to document moderate sized objects returned by a method.

3) initialization or getter methods

$obj:=Address_get_object

where the method initializes the object. This could include reading a disk
file or simply defining the object in code. Frequently I write these to
include an optional param for the key value of a record so it either
returns an empty object or a specific record. With a complementary SAVE
method it's a good way to manage record data.

4) readMe files for each module
Module? Addresses for example. I'd make a folder in Home named ADDRESS and
a method named Address_readMe. This method is where I make notes about
what's important and explain what is supposed to be going on. Like naming
conventions for addresses and the structure of objects.

Like I said at the start a good naming convention is your friend.
Especially in v17. Decide for yourself how you are going to manage key
names. Basically this comes down to camelCase or snake_case. The first
character of the name must be a letter, underscore or $. Decide what $ and
_ mean and be consistent. Avoid "stringly_typing" : using the key to imply
metadata like type, usage etc. These things are totally mutable in an
object. It can seem like a good idea in the short term but will bite you
eventually.

And don't forget you have JSON Validate. Validation schemas can be quite
complex but they don't have to be. Again, you can include a validation
document(s) in the Resources folder to check critical objects against
before using.

I encourage you to just begin working with them. When you find yourself
getting bogged down take a step back because you are likely trying to use
these new tools incorrectly. This is the hardest thing for long time 4D
devs - things we've done a certain way for years can be done with the new
tools a different, easier way.

Objects and collections are the gateway drug to ORDA and your programming
life will never be the same again.

Hope this helps.

On Wed, Oct 3, 2018 at 6:02 AM Paul Dennis via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> We have not started using objects in our application but I can see how they
> could be useful. However where I am struggling is how we are supposed to
> keep documentation as to the object definition. With database structure you
> can clearly see the definition of the table and fields and these are
> available in the method editor for lookup.
>
> Am I missing something as it seems to me that it would be very easy to get
> in a mess as to definition and contents of an object.  Would appreciate
> feedback as to have everyone is managing this. We are using V16 R6.
> Thanks
> Paul
>
>
>
> --
> Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **



-- 
Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*
**
4D Internet 

Defining and documenting Objects

[Paul Dennis via 4D_Tech]

We have not started using objects in our application but I can see how they
could be useful. However where I am struggling is how we are supposed to
keep documentation as to the object definition. With database structure you
can clearly see the definition of the table and fields and these are
available in the method editor for lookup.

Am I missing something as it seems to me that it would be very easy to get
in a mess as to definition and contents of an object.  Would appreciate
feedback as to have everyone is managing this. We are using V16 R6.
Thanks
Paul



--
Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**