| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 381.1 | FN$STRING is virtually OA$NULL? ;') | 57826::VICKERS | If it helps a customer, DO IT | Tue Mar 31 1992 23:48 | 22 |
| Mike,
It appears to my under educated mind that FN$STRING does nothing but
take some more CPU cycles. This reminds me of when I wrote the
OA$STRING DSAB many years ago and wanted to have an UPCASE option and
discovered that no code was required. All I had to do was to return
the string.
<GET FN$STRING(PI)
is the same as
<GET PI
They both give you the same piece of PI.
I suspect that there may be some obscure use of the lexical but I
cannot think of one. Of course, it's far better to have too many
lexical functions than not enough.
Keep smiling,
don
|
| 381.2 | | SIOG::T_REDMOND | Thoughts of an Idle Mind | Tue Mar 31 1992 23:51 | 3 |
| Gee Don... where did you pick up that silly example ;)
Tony
|
| 381.3 | From a book right above (over?) my head | 57826::VICKERS | If it helps a customer, DO IT | Wed Apr 01 1992 00:42 | 7 |
| At least the really poor pun was mine.
I guess that I should have given credit to the author but I knew him to
a kind soul.
Stay happy,
don
|
| 381.4 | Maybe not what it was intended to do | SHALOT::NICODEM | Who told you I'm paranoid??? | Wed Apr 01 1992 15:37 | 11 |
| Not that this exonerates FN$STRING, but it also seems to concatenate
whatever arguments are passed to it. For instance, if #A = 1, #B = "asdf", and
#C = 3535, then FN$STRING(#A + #B + #C) returns "1asdf3535" -- something that
normal string concatenation could have done anyway, or course.
I think perhaps that the intention of FN$STRING was to duplicate the
F$STRING lexical function... only it failed. Because in the case of the
F$STRING lexical, F$STRING(#A + #C) with the above values would have returned
3536 (i.e., the sum), not 13535 (i.e., the concatenation).
F
|
| 381.5 | Wish: FN$LOWER | SHALOT::LAMPSON | Whatever ya do, ya gotta have FUN! | Wed Apr 01 1992 17:49 | 9 |
| While we are discussing lexicals, why is there a FN$UPPER (something
that is easy to do in ALL-IN-1 without the lexical) and no FN$LOWER
which is much harder?
Thanks Frank for the hint of another usage for FN$STRING. It would
help if the documentation explained what "expression" was since no
other lexical uses a parameter of this type.
_Mike
|
| 381.6 | I've asked the code author to join this discussion! | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Wed Apr 01 1992 18:09 | 0 |
| 381.7 | Not sure of the usefulness... | SHALOT::NICODEM | Who told you I'm paranoid??? | Tue Apr 07 1992 18:22 | 13 |
| Since there's been no reply from the "code author" (see .6), I just
thought I'd confirm what we've been saying all along -- namely, that FN$STRING
really does nothing more than evaluate the parameter. As a matter of fact,
the entire code for FN$STRING (after, of course, parsing out parameters, etc.)
consists of:
� Status = Str$Copy_DX(.Output_String,.Input_String);
which, for the uninitiated, basically says that the result you're going to get
back (i.e., Output_String) will be a copy of whatever you passed it (i.e.,
Input_String).
F
|
| 381.8 | Talking to him that knows | IOSG::TALLETT | Just one more fix, then we can ship... | Wed Apr 08 1992 08:43 | 15 |
|
I spoke to "the code author" and asked him what FN$STRING was
for, (I am preparing a talk on this stuff and thought I might
get asked! :-) and it was apparently originally supposed to be similar
to DCL F$EDIT but it only half made it. It does convert its
argument to a string, but we couldn't think of a place where
ALL-IN-1 wouldn't do this anyhow.
By the way, I also came across FAO(..., OUTPUT=#x) which is in V3.0
but not the documentation because it found its way into the product
by devious means. I love it as I never did like OA$FAO (which also
found its way in by devious means! Sorry Jim).
Regards,
Paul
|