|
|
Ralf Fassel <ralfixx@xxxxxx> wrote:
>| My own opinion is, that this change would
>| get rid of more wtf's than it adds.
>| % set b(0) foo; set b bar; # assignment not ok wtf?
>
> In this particular case, there would be no WTF, since the error
> message
> can't set "b": variable is array
> should give a vague hint [TM] what the problem is.
Ok, there is a problem, and a descriptive error.
Where, again, was the "problem" with the unified container? :-)
> Whereas in
> set a foo
> set a(someval) bar
> if {$a(soemval) eq bar} {
> # something nice happens
> } else {
> # something not so nice happens
> }
I hope you wouldn't make me responsible for the not so nice
things that you programmed into the else clause :-)
You could afterall have just as likely made a typo comparing
the correct indexed array-element to "bra" instead of "bar".
Also, the key "soemval" may actually exist in the array due
to another occurrance of that typo some where else in your
code.
Leaving also aside that the expression will error for the invalid
bareword "bar", it isn't to be expected that code unaware of
possible array defaults will reuse a name for a scalar and
an array.
> I could spend hours debugging the wrong path until I realize the
> spelling error in the index.
This is of course just a personal transition problem.
This problem exists only, because you're not used to the
concept of an array-default values regardless of how it
was set up.
I'd like to discuss disadvantages inherent with the goal
of the proposal, and not so much those with temporary
surprise about previous vague assumptions having bit-rot :-)
> Another question which needs clarification:
> set a default-value
> set a(3)
> => default-value
> array get a 3
> => default-value? (currently: empty string)
still empty string.
That's a good one. One may see it as just a command-equivalent
to $a(3), but it defintely isn't! The last argument (3) is actually a
glob-pattern to filter the keys, and none of the really defined keys
in the given example matches the filter "3".
Thus, we still get an empty dict/list/string as result.
The array command doesn't have a "return value for given key"
getter subcommand. [set arr(key)] is the only command-based
way to get an array-element, leaving aside obtaining a dict,
and using dict get.
> I would not oppose to your idea if it were not for the inherent
> coupling of scalars and arrays.
I wouldn't call it "coupling". It's just one variable in the end.
It just has two faces, to allow access as scalar or as array, with
a (imho) consistent natural connection betwen the two faces.
> What about explicitely connecting scalars and arrays:
> array scalar a s
> array default a s
>=> use scalar variable s as default value for unset values in array a
> You could not use the same variable name for array and scalar, though.
Either this, or some new command to explicitly enable the two faces
would seem like an acceptable initial cut-down of my proposal. e.g.:
% set a(12) 84
% set a 42;# ==> error: var is array
% array enable_twoface_mode a
% set a 42;# ok, and serves as default for the array.
% set b 42
% set b(12) 42;# ==> error: var isn't array
% array enable_twoface_mode b
% set b(12) 84;# ok now.
# and it should work across upvar-links.
I'm quite sure, that as soon as programmers would get used to
that, they'd find the need for explicit unlocking to become
increasingly annoying, even if the subcommand was shorter :-).
|
|