Re: A question about certain language features
I've got a few minutes before the next crisis so I'll add my tuppence worth...
13/02/2002 3:51:43 AM, Igor Kachan <kinz at peterlink.ru> wrote:
>
>
>----------
>> > > 1) Variables can not be initialized when declared, but
>> > > rather, must be initialized via an assignment statement.
>> > > Based on other languages, this seems like one of those
>> > > convenience type issues. Is there some programming
>> > > philosophy that says that an initialization in a declaration
>> > > is a 'bad thing'? What is the 'bad thing'? I also note
>> > > that standard Pascal does not allow variables to be
>> > > initialized when they are declared.
>> >
>> > There is good article by Travis Beaty about this point.
>> > Visit please:
>> > http://www.RapidEuphoria.com/hotnew.htm
>> > There is the link to that article in this html.
>>
>> Hmmm. I read the article, but I still don't understand why:
>>
>> function foo()
>> integer a
>> a = someNastyComputation()
>> -- lots of code that massages a snipped
>> return a
>> end function
>>
>> is ok, whereas:
>>
>> function foo()
>> integer a = someNastyComputation()
>> -- lots of code that massages a snipped
>> return a
>> end function
>>
>> is 'dangerous'? (if it were allowed, which it is not)
>
>Your question is just about this
>catastrofic, terrible, weird difference
>as:
>
>integer x=5 -- not supported
>
>against:
>
>integer x x=5 -- supported
>
>Yes ?
>
>But you can write in Euphoria
>
>constant a=1,
> b="good luck",
> c={1,{1,{1,{1,2,3,45678999999.01},"foooo"}}}
>
>
>I do not understand your problem at all, I'm sorry.
>I think, thing with integer x above is like to a storm
>in a cup of tea. Sorry again.
>
Firstly, as you know full well, constants and variables are not the same. Sure
one can do:
constant x = 5
but then you can't go and do:
x += 1
I think that the primary reason for wanting to initialise variables when they
are being declared is
simply because it is convenient and reduces the chance of forgetting to do it.
The current syntax
for doing this only works outside of routines:
integer x x = 5
integer y y = 6
the argument is that this is not a particularly pretty solution. For example:
integer CustomerResidentialAddressIndex CustomerResidentialAddressindex = 1
integer CustomerMailingAddressIndex CustomerMailingAddressIndex = 1
(Yes, I know they have the same value. This is because it might have to change
at run-time for some
valid reason.)
It might be said that :
integer CustomerResidentialAddressIndex = 1
integer CustomerMailingAddressIndex = 1
was cleaner. However, did you notice the subtle bug in the proper Eu syntax
example? I made an error
because I had to type the variable name twice and got it wrong the second time.
using standard Eu, some people might write:
integer CustomerResidentialAddressIndex,
CustomerMailingAddressIndex
CustomerResidentialAddressIndex = 1
CustomerMailingAddressIndex = 1
This looks a little cleaner (to me) but it is still too much typing and we are
getting away from
initialising at declaration time. However, this is how we might do it now inside
a routine. What is
being suggested is:
integer CustomerResidentialAddressIndex = 1,
CustomerMailingAddressIndex = 1
regardless of whether it is inside or outside of a routine.
Apparently, RDS believes that mixing declarations and executables outside a
routine is okay, but not
inside routines?
integer x
x = 1
integer y
y = 2
is okay but :
procedure a()
integer x
x = 1
integer y
y = 2
end procedure
is not!
Why not? It is inconsistent behaviour. I suggest it has been done this way just
so that writing the
interpreter was easier for RDS. I can not think of any other reason yet.
I remember in COBOL you could declare a variable and give it an INITIAL-VALUE
clause. This would
make the compiler generate code that not only gave the memory area reserved for
the variable the
initial value, in made another COBOL statement useful. One could say in your
program:
INITIALIZE var1, var2, var3.
And each of these variables would be set to their initial values again. A very
useful thing to speed
up coding.
>But real problem is the *initialisation* of variables
>and run-time control of that initialisation,
>Travis, in his article, explains the real problem,
>solved in Euphoria, not a problem of some individual taste.
>
>> > > 2) No support of call by reference. I understand that call
>> > > by reference can lead to unexpected side-effects, but since
>> > > changing global variables in a subroutine seems to
>> > > essentially cause the same problem, I don't understand this
>> > > omission.
>> >
>> > No any side-effects here with the *globals*. If you'll
>> > reference to gobal name from inside subroutine, then you
>> > change just that variable. Private variable name override
>> > global and local names inside subroutine and exists
>> > only inside subroutine.
The "side-effects" being discussed here are not of the type you mention, but
more along the lines
that - if I call a routine, how can I be sure, aside from looking at the
routine, that it doesn't
update any global variables? This problem is lessened (but not eliminated) by
using pass-by-
reference. In that case, you have narrowed down the potential scope of side
effects to the variables
being passed.
My feeling is that global variables should almost never be declared at all. And
if so, you probably
have not got an optimal design. I locks you in to potential maintenance problems
in the future.
For example, I seriously wish the win32lib.ew did not have all those onXXX
sequences globally
available. I has made serious issues with expanding its functionality. With the
current regime, I
cannot assume inside the library that somebody using the library hasn't altered
the values at any
time. And I want to be able to define new handler exits at run-time, which the
onXXX method doesn't
allow - because the names must be known by the interpreter at run-time.
---------
Cheers,
Derek Parnell
ICQ# 7647806
|
Not Categorized, Please Help
|
|
