Re: Variable declarations
Derek Parnell wrote:
>
> [snip]
>
> I'm sure you will enjoy using it. The improvements to the language now are
> mainly in the syntax-sugar arena. With the upcoming 2.5's crash handling,
> I feel confident that it can be used in commercial, responsible
> applications.
Thanks for that vote of confidence in Euphoria, let's me know to keep
investigating.
>
> [snip]
>
> You are right about the argument passing change. However the effect on your
> code would be zero because currently a program fails if you pass an
> uninitialized variable, but if that was relaxed, your program would still
> fail when that parameter was used by your routine. So the only difference
> is *when* it fails, not *why* it fails. And because using IsInitialized()
> would not be mandatory, you can choose to add it as appropriate to
> give your code more flexibility.
It's mostly distributed libs I would be concerned about. A distributed lib
which assumed initialized args used by a newbie who passed an uninitialized
arg and received the uninitialized message would potentially assume it's
my library which is at fault rather than in their own care to ensure all
their variables are initialized.
> > > > Personally I despise dealing with
> > > > Null in other languages, it's too ambiguous.
> > >
> > > I don't see this. Its either initialized or not. What is ambiguous?
> > > Currently, this is true for all variables. Its just that we can't test
> > > for it programatically.
> >
> > Ambiguous in that a boolean is true/false/null it is not really a boolean
> > but a tristate. Ambiguous in that a string is either a value, a null
> > string ( ie. empty string ), or null.
>
> I suspect if people realize that we are not talking about the *value* of
> a variable, but about a *property* that it possesses, then they can see
> that even current programs must deal with this situation. A boolean is
> not true/false/null it is initialized or uninitialized. If initialized
> it can then either be false or true. This is not new because all Euphoria
> programs work like this today. There is no new concept or change to the
> way Euphoria is working today. Its just that developers today cannot query
> a variables 'is-initialized' property. All existing code that runs today
> would still run if we had access to this property.
Yes I see your point, just still dislike Null. My real start in programming
came in various forms of ML and ASM where variables were declared via some
type of data directive which would reserve the memory, in some cases
initialized, in other cases not, but there was never a pre-built means to
determine if it was initialized, it was up to you as a programmer to
habitually declare and initialize. This held true even for allocated heap
where the allocation reserved the memory but it was then up to you as the
programmer to make sure the memory was set to your initialized state.
Null may provide for the ability to detect an uninitialized state, but I
guess with my background I don't want to allow for an uninitialized state
but rather like the language to point out to me when I fail to initialize.
Just thought of another situation where Null allowances would affect me
as a decidedly non-null kind of guy - return values. I could happily code
without Nulls even with a Null allowance in the interpreter, but if I use
your libraries to do XY and Z I may be forced to deal with Nulls if you
choose to return nulls from some of your functions.
The example you gave a few messages back on this thread where you are
attempting to create a more OOP like functional syntax with optional
arguments, why not stick with the Euphoria way? By that I mean you are
calling the root routine with a sequence of args, you count the args and
dynamically call the proper routine based on how many args were in the
sequence. Why not have the 1 routine in which your initial block of code
determines what args are missing and coding the whole routine in 1 place
filling in the missing with defaults or whatever?
I realize that using the Euphoria way doesn't allow for type checking in
the routine declaration, but this seems a small price to pay in having to
add argument type checking validation.
Jim
|
Not Categorized, Please Help
|
|
