Posted 21 September 2004 - 09:55 PM
And more than 255 logics, and 999 lines, and the total function size should be made bigger, since its fairly easy to blow the size of a function, with just a few large filedefs and arrays. Since most of us are coding apps for machines with have more that 16K memory, it should be unlimmited.
Although, any paging screen with 32000+ records need to be thought about, because it cant be very usable by the user...
Posted 22 September 2004 - 08:17 AM
If you code clearly, and have plenty of comments, its not too bad
Oh, and while were at it, more than 999 lines in FDESC would also help, since lots of people use this for versioning a function and 999 runs out in busy functions...
Posted 22 September 2004 - 09:56 AM
I asked proiv to remove these silly limitations at the last two European User Groups.
Things like all the above and 8 character file/function names...
Apparently this would be difficult, so they are not going to do it <_<
Edited by Tony Waszkiewicz, 22 September 2004 - 09:56 AM.
Posted 22 September 2004 - 03:18 PM
Our major problem is with the 255 logic limit per function. Each global logic uses one of those slots, so if you have more than a few globals in a function, you can lower your ceiling quite quickly. For us, this is compounded by the fact that we often have global logics calling other global logics.
If we were asked today what limits we would like to see eased, I would ask for them to increase the function max size, and increase the 255 logic count per function. Others of you obviously bump into the other limits, but those are ours.
PRO-IV's argument, which does carry some weight, is that with the advent of global functions and the ability to call them from just about anywhere, you should be coding using smaller called functions. This approach though does not always lead to the best design and/or performance.
I doubt we will see much movement on this by PRO-IV in the near future unless we, as a unit, make a good case for it. Remember though, PRO-IV has finite resources. Is making these changes the best use of those resources? If they embark on these changes it would mean something else, possibly more important, would move down on the list. Unless we know what is on that list, we are shooting in the dark. I would like to know what features they are working on now, and what they are planning for the future.
Anyone at PRO-IV willing to give us a short and long term heads up on the next release and beyond?
Edited by Lewis Mccabe, 22 September 2004 - 03:19 PM.
Posted 22 September 2004 - 04:06 PM
To remove the basic limits they'd effectively have to create a ProIV clone that emulated all the subtle interactions that go back to the year dot to make it backwards compatible.
Some years ago, when Sushil was more interested (and probably still remembered something about it!) MDIS were trying to get him to assist him to work it all out.
If it was a simple fix then it would have been done ages ago! That's also why the basic structure and limitations of the language haven't had major changes.
Posted 22 September 2004 - 04:19 PM
Since we have some fairly complex server code & calculations we're frequently bumping into these limits!
Posted 22 September 2004 - 04:28 PM
"... the core of the code is undocumented and not particularly meaningful..."
IMHO if they cannot easily make some simple changes what chance is there of catching up with other development languages?
tell me again why are we using this
Posted 22 September 2004 - 07:18 PM
This is the first I have heard of the assembler conversion not being well documented. It does make sense why they have been loathe to make what we feel are necessary changes to PRO-IV. They had to have made that conversion back in the 80's when they first came out with version 1.5. So hopefully much of the work since then is clean and documented. How big an albatross is that old converted code? I'm sure no one will freely admit. I have to say, it does make me nervous knowing the source is not up to par. Were the various attempts at rewrites (Jade, etc.) driven in any way to get the source cleaned up?
Is there any "guest" who knows enough to fill in the blanks and give us some warm fuzzies for the future?
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users