Re: What's new in 2.5?
----- Original Message -----
From: "Christian Cuvier" <Christian.CUVIER at agriculture.gouv.fr>
To: <EUforum at topica.com>
Sent: Tuesday, September 07, 2004 5:24 AM
Subject: Re: What's new in 2.5?
>
>
> >>- local include (make an identifier visible to the including file only)
> >
> >
> > This is already in the language. Any non-global identifier declared
> > in an include file, and not inside a routine, is visible to the
> > routines in that include file and nowhere else.
> >
> >
> Ok, let me restate it. What is missing is a way for the including file,
and no
> one else but the included file,
> to see globals in the included file, so as not to pollute the "universal"
> namespace, generating name clashes.
>
> There are several approaches to solve this:
> -define a "nonlocal" (or whatever) keyword to qualify variables that are
to be
> seen from the current file and any directly including file only;
> -define "scopes" as namespaces with no communication with the 'default)
> namespace. Currently "include ... as" creates two identifiers (myid and
> name:myid).
> -define an "import ... as" statement so as the imported file's globals are
> visible from the importing file onl.
> -and probably more.
>
> At least, all these can't break any existing code. I'd be satisfied with
any
> of the above.
> >
> >
> >>> - Something I had not mentioned before: assume i+3 falls of the valid
indexes
> >>> of sequence s. The current behaviour is that
> >>>
> >>> if s[i+3]<3 then...
> >>>
> >>> crashes as the bound check fails. But no logical condition holds true
when
> >>> some of its args doesn't exist. As a result, it would be much simpler
to code
> >>> if any such test quietly returned false.
> >>>
> >>> Thus, we'd have, whenever x doesn't exist: x<y = x=y = x>y = 0. Not a
problem,
> >>> as x doesn't exist...
> >
> >
> > A guaranteed source of bugs, for sure.
> >
> > One could however use a function to check index validity before using.
> > Like ...
> >
> > if valid(s,i+3) and s[i+3]<3 then..
> >
> > if valid(s,{b,c}) then
> > a = s[b..c]
> > end if
> >
> > where 'valid' is defined as ...
> >
> > function valid(sequence s, object x)
> > if integer(x) then
> > return x >= 1 and x <= length(s)
> > end if
> > if length(x) = 0 then
> > return 1
> > end if
> > if x[1] >= 1 and x[1] <= length(s) and valid(s, x[2..$]) then
> > return 1
> > else
> > return 0
> > end if
> > end function
> >
> > -- Derek Parnell Melbourne, Australia
>
> Oh sure, and that's what one has to do. That's a major source of errors
> designing the function or just forgetting the preliminary test, plus the
> coding overhead.
> As an answer to the "this will hide bugs" issue, there might be the
addition
> of a new keyword, say "ifx". "(els)ifx" is to behave just like "if",
except
> that it returns false when some conditional expression fails to evaluate.
> This way, the of statement is not modified,, andthe benefits of useless
data
> validation may be bypassed. I say "useless" since the coder has to supply
a
> check that the interpreter will carry out anyway. Unless it cleverly
optimizes
> away, of course :).
>
> Further, any undefined index real bug will show up anyway, most likelly in
the
> same conditional block, when attempting to read or write from a
nonexistant
> element, which must remain an error condition in a nonconditional
statement.
> This challenges the very idea that the proposed change will hide bugs.
> CChris
>
>From what I've read.
This if exist() type of thing is more than laziness. You are promoting a
bad
coding style. eh, so I created a vairable I don't need or use. No big
deal.
Just ignore me, I'm stupid. So you want the computer to be smarter than
you because you simply want to be lazy and not pay ANY attention to the
mess you leave behind. Sure, just cleanup behind me EVERY time you run.
yeah, that sounds real mature.
Maybe I'm just not understanding your suggestion.
unkmar
|
Not Categorized, Please Help
|
|
