Keith:
Very interesting points that you raise.
On Sat, Oct 1, 2016 at 3:07 PM, Keith Goebel <keit...@clear.net.nz> wrote:
> Several people have said that passing a 4D object as a parameter is easy
> to debug.
> Using 4D v15.2, I think I must be missing some new feature of 4D as I
> don’t understand how you can easily trace and/or debug an object when
> - only the first small part of the object is visible in the debugger?
>
Having used ObjectTools for forever, one of the things that I do like about
4D's object is that the Object contents is visible in the debugger. You can
view the object "in line" or you can click the expander and the debugger
window will display the object content in a vertical and hierarchical
manner. While I did get used to the opaqueness of OT, I will admit that
this is a nice feature in a 4D Object.
Another approach is that, since an Object contains "structured text", put
an instance of the object on a form and you will be able to see it update
in real time. The way I did this is to put a text object on a form with the
object name of "objText". When working with the object, just use code to
update the text variable with the string of the object
> - a Design search cannot show the methods flow that use a particular
> parameter?
>
If you mean where the object it used, you can use "Find in design" to find
the object that's passed as a parameter. OTOH, if you're wondering how you
find where an item/value in an object is used, you're getting to a fork in
the road.
One of the reasons why I have climbed on my soapbox about using accessor
methods is that *without* accessor methods you have to either be familiar
with the code to know where an item is used or use "Find in design" to
search for the tag/name. 4D V6 was the new version when I started using OT
and you might remember how incredibly slow 4D was to do that version's
version of "Find in design". It was horrid and that was one of the reasons
why I gave up on using "naked" calls to OT and went with accessor methods.
Fast forward to V11 or newer and Find in design is very snappy (Thank you,
4D!) so it's faster to find all of the places where a given tag is used.
But Find in design only tells you the methods contain the tag- it doesn't
answer the question"What methods use the object/tag in the code that I'm
trying to debug?".
The best way that I've found to slay *that* dragon is to write accessor
methods. When you want to see where a value is…accessed, just put a break
point in the _Set or _Get routine, then run the code, and the debugger
opens when it hits the break point. That's much, much easier than click,
click, click to see where the value of something changes.
And, yes, I write accessor methods for process variables when I work in OPC
("other people's code"). I'm working with one application that's rife with
process data. It's a 25 year old system that supports just under 100 users
and it was written using a main event loop. The application is rife with
process data and, at times, the only way that I can figure out what's going
on is to create an accessor method and then use Replace in content to
update the code. That only takes a few seconds to create the accessor
methods and to do the update so it's extremely cost effect and it makes
maintenance much, much easier.
Okay, wandering back on topic now…
"I’m not for or against the idea - just trying to understand the enthusiasm
for hiding parameters."
For me, it wasn't about hiding parameters, it was about getting around the
fixed parameter list.
Traditionally, 4D programmers have used Count parameters to make code more
flexible. A lot of code uses optional parameters, too. While that seems
to "solve the problem" of making code more flexible it makes the code
more complex ("OK, I want to pass a value to $6 - so what are parameters 3,
4, and 5?"). And complex code has more bugs, is less flexible, and is
harder to understand.
Rather than use Count parameters, you can pass data by reference but that
can be a hassle. It wasn't until the end of the 1990's that you could pass
pointers to locals and then there's the issue of not passing by reference
unless you don't have to. Pointers are more complex than passing the value
directly and there's a performance penalty in terms of memory and execution
speed. During the Q&A session at the end of the last Summit I asked about
the speed issue and the response I got was that it's 1.6 time slower to
work on a dereferenced data item than it is to operate on the data item
itself.
I understand your position and this issue, for me anyway, is not easy to
explain or quantify. Like so many of us, you've been working with 4D for
decades and you have an intimate understanding of the product, how it
works, and how it doesn't work. You're able to work quickly and effectively
with the practices that you've honed over the years and that,
understandably, leads to a "Why bother?". When I read Peter's posting, one
thought I had was "If it's working, don't change." and I think that's a
very appropriate train of thought. If you're *not* running into some of the
issues that people have raised then it's hard to justify changing your
programing habits.
One reason to change, however, is that as you learn a new tool or new
technique, you're able to tackle different tasks or create interfaces and
functionality that you weren't able to create before. Over the past few
years, that's been my experience - I've created functionality using OT of
sufficient complexity that I shudder to think of the complexity of the code
that I'd need had I *not* been using objects.
--
Douglas von Roeder
949-336-2902
**********************************************************************
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
**********************************************************************
