I know that feeling :-) and yeah I also had that experience when first encountering typeglobs. But, here's the simple explanation I arrived at for my own understanding:
Perl allows you to create different types of global things using the same name, like '$foo', '@foo', '%foo', 'sub foo' and so on. To store them internally, one logical design would have been to have a hash table of "ScalarGlobals", another hash table of "ArrayGlobals", another hash table of "HashGlobals", and so on. In perl-speak, it might look like $globals{$package_name}[Scalars]{$scalar_name}. But, that makes a lot of hash tables per package name. Larry chose instead to create one hash table per package, and then store a struct which has a "slot" for each type of thing. In perl-speak, it might look like $globals{$package_name}{$thing_name}[ScalarSlot] The end result is lower use of memory by having fewer hash tables.
In the original language, NAME referred to the file handle, $NAME the scalar, @NAME the array, %NAME the hash, and &NAME the subroutine. But, for reasons I am uninformed of, it was decided that people needed access to these slots in the perl language (probably so that Exporter can be written in Perl instead of written in C) and so *NAME gives you access to this C struct that has a slot for each type of thing. The notation *NAME{IO} is how you access the file handle slot of that struct.
Now that bare-word file handles are discouraged, that implementation detail of the C-side typeglob structs (and the awkward Perl syntax for it) is more in-our-face than ever, especially since there is no native '$' variable for STDIN, STDOUT, STDERR, or DATA.
In reply to Re^3: Filehandles and CSV_XS
by NERDVANA
in thread Filehandles and CSV_XS
by Melly
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |