|
|
|
|
|
by G3rn0ti
1114 days ago
|
|
> And half the time it doesn’t work because the hash is actually a ref Perl still supports both „copy by value“ and „copy by reference“. For example: my @copy = @original;
my %hash_copy = %orig_hash;
my @processed = foo_func(@copy);
my $ref = \@copy;
bar_func($ref); # modifies @copy in place
That’s why it uses these sigils to distinguish between references being scalar values (“$”) and actual lists/dictionaries (“@“ and “%”). Since Perl is also dynamically typed if it weren’t for the sigils, it would be quite confusing when reading “array[i] =“ somewhere not knowing whether it modifies an array created remotely or locally. Sigils communicate that because it reads “$array[$i] =“ for a local array or “$$array[$i]”
for a remote one.In other languages like JavaScript or Python everything is basically a reference and, hence, you don’t quite need sigils there. However, on the flip side, you need to be more careful and constantly remind yourself of the fact you are dealing with references and not to accidentally modify the objects you get passed into your function. |
|
Yes, good language design allows the programmer to ignore details such as how an object was created or where it is stored.
Having to remember something like that violates so many design principles. Why would a programmer using the array need to know how it was created? It just adds unnecessary complexity to the code, making the programmer's job harder than it needs to be. It's accidental complexity ossified in the programming language.