The `if' command

On 2008-05-02, Rod Dorman <rodd@panix.com> wrote:
> In article <9mDSj.76$Vd7.68@edtnps92>,
> Duke Normandin <dukeofperl@ml1.net> wrote:
>> ...
>>Now I see how easily "naked References" could quickly produce spaghetti
>>code. But why use them at all? Is there a _speed_ advantage? Something
>>else?
>
> Used properly I find theres a readability advantage and reduced chance
> of a typo. e.g.
> SET VehicleID=^CustomerCars(Country,State,City,Street, OtherSubscript,"VIN")
> SET MilesPerGallon=^("MPG")
> SET SomethingElse=^("Whatever")
> -or-
> SET ^("Count")=^Something(Here,There,Anywhere,"Count") +1
>
> The danger in using naked references comes from assuming that the
> naked indicator wont change when making subroutine or function
> calls. It might work fine when you write and test it but break at some
> point in the future if/when the subroutine is changed.
>

So the most prudent course to take would seem to be to refrain from
using such potential booby-traps, would it not?
--
Duke Normandin

On 2008-05-02, Pete <peter.charbonnier@gmail.com> wrote:
> On May 2, 4:59 am, Duke Normandin <dukeofp...@ml1.net> wrote:
>> On 2008-05-02, Pete <peter.charbonn...@gmail.com> wrote:
>>
>>
>>
>> > On May 1, 5:05 pm, Duke Normandin <dukeofp...@ml1.net> wrote:
>> >> On 2008-05-01, Rilian <no...@nohow.com> wrote:
>>
>> >> > Naked references are bad - nude variables are encouraged.
>>
>> >> > Figure that one out. 8^)
>>
>> >> > Duke Normandin <dukeofp...@ml1.net> wrote in news:lFaSj.3318$PM5.2947
>> >> > @edtnps92:
>>
>> >> >> Thanks for the great explanation! What is _your opinion_ of
>> >> >> "naked references" -- if you dare to go there.
>>
>> >> You've _got_ to be sh....ing me!!
>> >> --
>> >> Duke Normandin
>>
>> > He is....a little.
>>
>> > Here's a quick explainer:
>>
>> > SET ^Cars("pickup",1)="Tundra" --- * Full global reference *
>> > SET ^(2)="Rabbit" --- * Naked global reference *
>>
>> So this implies that there pre-exists something like:
>> SET ^Cars("compact",2)="Rabbit" ??
>>
>> > SET ^(3)="ChevyS10" --- * Assume subscript level 2 *
>>
>> as well as:
>>
>> SET ^Cars("pickup",3)="ChevyS10" ??
>>
>> > SET ^(3,1)="ChevyS104liter" --- * Go to subscript level 3 *
>> > SET ^(2)="ChevyS106liter" --- * Assume subscript level 3 *
>>
>> > So a naked global reference is one where the fully qualified global
>> > name "^Cars("pickup"," is implied and can be called with just the
>> > caret and the subscript number. You can see how naked global
>> > references are unnessecarily confusing because they don't "spell it
>> > out" for the person reading the code. You've got to pick back through
>> > in order to see what you're referencing and it drives me nuts.
>>
>> Now I see how easily "naked References" could quickly produce spaghetti
>> code. But why use them at all? Is there a _speed_ advantage? Something
>> else?
>> --
>> Duke Normandin
>
> The Rabbit was technically a pickup, described in my global example on
> the same level as the S10 and the Tundra, with just a name. In this
> example the logical extension would put:
>
> SET ^Cars("pickup",2,1)="RabbitLX"
>
> Where the LX was the version with the slightly larger engine. I
> think. I probably should have used a modern car reference.

Hey Pete....

Sorry! I wasn't critisizing your choice of models etc etc. I'm trying
understand the workings of Mumps, its database and subscripting and
indexing AND trying to figure what the hell a naked reference is
vs a not-so-naked one. I made the wrong assumptions. So is _this_
correct:

SET ^Cars("pickup",1)="Tundra" --- * Full global reference *

SET ^Cars("pickup",2)="Ranger"
SET ^Cars("pickup",3)="S10"
SET ^(4)="Sonoma"
SET ^(5)="F150"

So to my un-trained eye, the on;y way that I know that ^(4) "points"
to ^Cars("pickup", ) is the very close proximity of the context. 50
lines of code later, the context would not be so obvious. Secondly,
how do I know for sure that ^(4) does in fact still "point" to
^Cars("pickup", ) ?? Seems like using these "naked references" is like
"an accident waiting to happen", no?
--
Duke Normandin

> Seems like using these "naked references" is like
>"an accident waiting to happen", no?

You hit the nail right on the head. That's why I avoid them like the
plague. Stick to explicit global references.

---

Rob Tweed
Company: M/Gateway Developments Ltd
Registered in England: No 3220901
Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR

Web-site: http://www.mgateway.com

SlipstreamUSA: April 2, Renaissance Hotel, Orlando
http://www.OutOfTheSlipstream.com

In article <FFQSj.209$KB3.87@edtnps91>,
Duke Normandin <dukeofperl@ml1.net> wrote:
>On 2008-05-02, Rod Dorman <rodd@panix.com> wrote:
>> ...
>> The danger in using naked references comes from assuming that the
>> naked indicator wont change when making subroutine or function
>> calls. It might work fine when you write and test it but break at some
>> point in the future if/when the subroutine is changed.
>>
>
>So the most prudent course to take would seem to be to refrain from
>using such potential booby-traps, would it not?

The choice is yours. I find if you use naked references only when the
execution sequence is linear (i.e. no extrinsic function or subroutine
calls) it isn't a problem.

Note that this assumes you don't have a coding style that (shudder)
includes GOTO Tag+Offset

--
-- Rod --
rodd(at)polylogics(dot)com

On 2008-05-04, Rod Dorman <rodd@panix.com> wrote:
> In article <FFQSj.209$KB3.87@edtnps91>,
> Duke Normandin <dukeofperl@ml1.net> wrote:
>>On 2008-05-02, Rod Dorman <rodd@panix.com> wrote:
>>> ...
>>> The danger in using naked references comes from assuming that the
>>> naked indicator wont change when making subroutine or function
>>> calls. It might work fine when you write and test it but break at some
>>> point in the future if/when the subroutine is changed.
>>>
>>
>>So the most prudent course to take would seem to be to refrain from
>>using such potential booby-traps, would it not?
>
> The choice is yours. I find if you use naked references only when the
> execution sequence is linear (i.e. no extrinsic function or subroutine
> calls) it isn't a problem.

You bet! Because the context of the naked references is immediately
apparent because of its close proximity to the original global
variable.

> Note that this assumes you don't have a coding style that (shudder)
> includes GOTO Tag+Offset

Can't comment because I'm not there yet in the tutorial. I'll will keep
this in mind and experiment further when I get there. Thanks.
--
Duke Normandin

you need to put the second in pren's
I i<j&(k>j) W "yes",!

"Duke Normandin" <dukeofperl@ml1.net> wrote in message
newsURRj.3093$PM5.3083@edtnps92...
> set i=1,j=2,k=3
> if i<j&k>j write "yes",!
>
> i _is_ less than j AND k _is_ greater than j
>
> so why is _yes_ NOT printed?
>
> The logical operator & tells me that both relational expressions must
> be true in order for the _yes_ to be printed. That's exactly what it is,
> so what am I missing? TIA......
> --
> Duke Normandin