Protected Variables w/in a block.

[jassing]

Given the example below, I would have liked to see the line [Debug "2: "+cFish] error out; this would be inline with things like c & c++

Code: Select all

Procedure m()
	If 1
		Protected cFish.s = "HI"
		If 1
			Debug "1: "+cFish
		EndIf
	EndIf
	Debug "2: "+cFish
EndProcedure

m()

[skywalk]

Huh

[BorisTheOld]

I think he wants "cFish" to be local to the If statement.

Seems to me that it's just one more way to write stupid code, since it implies that the following would be valid:

Code: Select all

Procedure m()
   Protected cFish.s = "World"
   If 1
      Protected cFish.s = "Hello"
      If 1
         Debug "1: "+cFish
      EndIf
   EndIf
   Debug "2: "+cFish
EndProcedure

m()

[jassing]

I guess you never used C... that's very common; in that a block of code can have it's own variables, or share with parent blocks...

No need to shit on me because you don't agree.

[Shield]

I agree with jassing, I'd like to see that.

The code shown by BorisTheOld will of course be invalid since variables
are passed down the scopes and cannot be redefined.

[skywalk]

I was just thrown by the example with 'If 1' always true.
If you change to 'If 0' and use EnableExplicit then I am curious why no error?
Maybe look to the ASM to see that all procedure variables are declared regardless of condition?

Code: Select all

EnableExplicit
Procedure m()
  If 0
    Protected cFish.s = "HI"
    If 1
      Debug "1: "+cFish
    EndIf
  EndIf
  Debug "2: "+cFish  ;<-- Why no error for undefined variable cFish?
EndProcedure
m()

[freak]

The code shown by BorisTheOld will of course be invalid since variables
are passed down the scopes and cannot be redefined.

In PB they can be redefined though. Also, without EnableExplicit a variable is declared on its first use. Both of these rules do not fit well with this kind of block scoping.

[BorisTheOld]

Yes, that was my point - we're talking about PB and BASIC.

I was expressing the opinion that it's a bad idea to allow local scope within If/EndIf blocks and similar constructs. I've seen this type of usage in other languages and the aftermath is not something one would wish to debug.

[Shield]

@freak

Well they can be redefined now, that behavior obviously has to go if this feature gets implemented.
I didn't realize they can be "defined" again, because I never did this (why should I?). IMHO, this shouldn't
even be possible and since types can't be changed, I guess the keyword just gets ignored the second
time it is used.

The second part seems to be a valid point though (however, I always use EnableExplicit).

[skywalk]

What can be redefined?

[Shield]

You can use Protected / Define / Global multiple times on the same variable without getting an error message.
Most other languages I know will throw an error if there is an attempt to redefine a variable.

[skywalk]

PB gives an error too

Code: Select all

EnableExplicit
Procedure m()
  If 0
    Protected cFish.s = "HI"
    If 1
      Debug "1: "+cFish
    EndIf
  Else
    ;Protected cFish.s = "NO"  ;<-- Local variable already declared
  EndIf
  Debug "2: "+cFish  ;<-- Why no error for undefined variable cFish?
EndProcedure
m()

[Shield]

For some reason I didn't check protected, but it doesn't throw an error with Define / Global.
Arguably it does make sense to allow that for Shared / Global usage, even though that's
very likely bad programming practice in most cases.

[langinagel]

Just a question:

what is the advantage to use the very same name of a variable in a certain block?

From my point of view it decreases readability and the proper understanding of the code.
Security of knowledge by obscurity?

By the way: why not extracting the block into a procedure?

See: Robert Martins "Clean Code".

Greetings
LN

[Tenaja]

IMHO, it there is no benefit. However, perhaps someone likes using variable named (such as i) for every single For-loop that has no significance in the var name... that would be the only reason (as bad as it may be) that I can think of.