Arnaud,
On Sun, Jan 8, 2017 at 10:41 AM, Arnaud de Montard <arn...@init5.fr> wrote:
> Looks quite similar to Cannon's logic in his OB module…
>
True. I like the way the code reads in this syntax. Also keep in mind
those methods I mentioned are for dealing with form objects, not c-objs.
The names get confusing.
I couldn't help to ask him recently why this:
> text:=OB_getText (obj;property { ;->optionalText)
> long=OB_getLong (obj;property { ;->optionalLong)
> pict=OBJ_Get_Picture (obj;property { ;->optionalPict)
> etc.
> instead of that:
> OB_get (obj;property;->mandatoryVarWithType)
>
Well, that's basically the native 4D approach isn't it?
Initially I tend to prefer methods that are less restrictive. But as I've
worked with them I have come to appreciate defining what kind of value we
are getting right from the start. There are more methods but they're less
complex and usually faster.
In the second approach, there is one method, but it has to read the
> variable type to convert correctly.
> I tried to compare on a simple example (read a set of virtual names, ~180
> tables and thousands of fields): using OB_get is slower. Pointers, maybe…
>
> But with a form variable, the pointer cannot be avoided. So could you say
> more about your choices?
>
Frequently dealing with form objects convenience is the major motivator.
The most common form object I tend to deal with is a text object so that's
where I started. It's easy for me to go off on some tangential line of
development that winds up not really helping me do what I was trying to do.
So rather than stop and write a whole suite of form object handling methods
right off the bat I wrote a few that did things I was doing a lot then
wrote better ones once I know what I was doing.
And to your question I think the issue of the time it takes to process
pointers becomes important in methods iterating thousands of times, like
your example. On a form this usually isn't the case. If it is then I need
to come at it a different way. But for typical forms the limiting factor
tends to be the human more than the machine or the code.
--
Kirk Brooks
San Francisco, CA
=======================
**********************************************************************
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
**********************************************************************
