...
> > However that would preclude a CI function from being qualified.
Donna writes...
> ewwwww, that's ugly :-(
I suppose the same reasons script writers qualify command file names
can be applied to user functions. In general, I prefer not to
qualify script files, so that their name and or location are easy
to change. And, as a work-around, a qualified script could be used in
place of the function.
...
> however, not being
> able to qualify a function may create challenges during testing.
>
> imagine i've got a script that calls functions a(), b() and c(). i'm
> working on b() and have the modified copy sitting somewhere else.
> continue imagining
> that another person is working on c() and the new c() is in the same
> location as my updated b(). for whatever reason, i don't want to use
> the new c() (it's not ready; it's got a bug that does 'bad'
> things...). changing hpppath clearly isn't the solution. at this point,
> i'm kinda stuck...i am not without hope (i probably could move my b()
> but maybe i can't (oh dear))....but i've got "one arm tied behind my
> back" because i can't reference my b() explicitly.
Agreed, but you could always choose to have a development group which
is never referenced by a production HPPATH. If you had this you'd
need to copy the new b to a production location and leave c alone.
I would think your argument could be applied to any production system
which also hosts a development environment, and it is not limited to
CI programming but also applies to general s/w development.
> i'll add that i liked the suggestion of being able to issue a file
> equation for a function.
I missed that suggestion, but then I haven't seen any 3000-L email since
10:34 this morning, so who knows what's going on. Without seeing the
suggestion I see the '*' as being overloaded in an expression. Is it
multiply or referring to a file equation?
> i'll also add that to use this capability,
> the function would need to use an asterick -- *b(). allowing for
> potentially anyone to say:
>
> :file b=my.evil.function
> :xeq innocent.cmd "which uses function b"
I don't see the '*' being used in this example. Did you mean
something more like:
:file b=blah...
:setvar x *b(p1,p2)
I guess with more sophisticated parsing we can distinguish an * multiply
operator from an * back reference to a function. The same applies to
a / used for division vs. used in a function filename, as long as all
functions (even those with zero parms) have parenthesis. I think a
user function would need higher precedence and that might not be
good.
We'd need to handle:
setvar x a**b()*c
x *b()*c
x a*b() <-- today I think this will push a multiply and we'd
need code to unwind this or do some fixup. All new.
x a/b()/c
x /a()*c
x a/b/c**d() <-- pretty nasty syntax to me. Disallowing qualified
names makes the coding safer and the use of the
function simpler.
x a/b/c() <-- is the function a/b/c() or b/c() or c()? I think
this ambiguous example pretty much eliminates
supporting qualified POSIX names. It seems a bit
inconsistent to allow qualified MPE names but not
POSIX names. And, of course MPE names cannot have
an embedded lockword.
The CI uses a different parser than the evaluator. You can argue that this
was a mistake but nonetheless it is a fact. There is increasing risk of
breaking existing expressions if we change the evaluator's parser.
> and have it *work* is a dreadful security risk. once i'm done testing
> b(), i'd need to remember to take out the asterick (thinking that i'm
> also modifying the calling script) -- but imo that's acceptable.
I don't see file equations as a security risk, but I do agree that they
offer more flexibility and thus more ways to mess up. My preference (still)
is no file equations and no qualified function names.
Jeff
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
