On 05/25/2017 01:33 PM, lee wrote:
Uri Guttman <u...@stemsystems.com> writes:
<forwarded to the list as i was emailed off list. no reason to keep
this private IMO>
On 05/24/2017 08:20 PM, lee wrote:
Uri Guttman <u...@stemsystems.com> writes:
you can get an array of hashes, where each hash is one row.
learning dereferencing will do you much more good than using eval
EXPR. references are key to deeper data structures in perl and are
used all over the place. it is a core skill you should focus on as it
will solve your current problem and many to come.
Since when are there any data structures in perl? Variables are even
virtually typeless.
since when is a variable a data structure? :)
It is when it has a type.
typedef struct {
unsigned long MemTotal;
unsigned long MemFree;
unsigned long Buffers;
} meminfo;
meminfo test;
meminfo foo[20];
int bar;
int baz[20];
The difference between 'int' and 'meminfo' is that 'int' is pre-defined
while 'meminfo' is defined by the programmer. Both are data types of
which you can declare variables. The variables you declare are
instances of the data structures that correspond to the type of the
variable. For practical purposes, the variables 'test', 'foo[]', 'bar',
'baz[]' are all data structures.
that is c, not perl. why do you keep bringing up c? languages are
different for various reasons. perl doesn't do strong typing so if you
want to use and learn perl, you can't say it should be like c. that
isn't the way to learn anything.
and those are trivial data structures in c. perl has hashes for simple
data structures. and YES, hashes are data structures, no matter what you
say in opposition.
Perl doesn't have data structures, so variables in perl are not data
structures. That is unfortunate.
wrong. i won't argue this again. you haven't the experience in
programming to defend that point.
the key is again references which still seems to confuse you. a scalar
can hold only one thing.
A scalar can hold many different things, like an integer, a float, a
double, a string, and at least three different types of references. You
never really know what it happens to be.
you code so you know what it can be.
Why would I need a reference to put a hash into an array or into a
hash? Perl may need that internally, which isn't relevant to the
programmer in the first place.
huh??? that is how you build complex data structures in perl. you
haven't learned that yet. please learn references before you rant about
them.
if you need help with references, this list is the place to ask.
Why is it so awfully difficult to dereference a reference to an array
that contains references to arrays, and why does DBI, for example,
provide a function that returns such a reference? It involves holding
the data in memory, so what is the supposed advantage of using cascaded
references?
how will you organize the data without references?
I put it into a database.
and when you get it out of the database what do you do with it? what
about complex cross connected tables? how do you manage that in memory.
you haven't dealt with complex data yet if you think that is a solution.
they are the branches in the tree of data. returning a single
reference is much more efficient than returning the whole array or
hash. that would involve copying the array/hash onto the stack and
then copying it again to a variable in the caller. that is very slow.
Programming is even slower when you have to mess around with nested
references, trying to figure out how to de-reference them correctly. I
did spent hours with that ...
hours? i spent years. decades even. experience helps. :)
you say cascaded references. i call that a data tree.
Arrays do not look like trees to me, they look like rows.
arrays of arrays of hashes of arrays and hashes. no rows there but a
complex data tree.
it is incredibly valuable and used all over the place.
I'm avoiding it as much as I can.
then you are not learning or using perl effectively. do you want to get
better at perl? or do you want to just use trivial data forever?
as i said above most real world data is more complex than what a
single hash or array can hold. think about something like what is
needed to manage an editor or word processor. they need complex data
trees (usually in c/c++ but the same idea). so references aren't an
evil to be handled but the key to better management of data.
In perl, references are evil. This is not for their technical aspects
and advantages but for the lack of data structures, the typelessness of
variables and the lack of decent ways to de-reference references in
perl.
A C compiler will tell you when you mistakenly pass a variable as an
argument to a function rather than a reference to a variable. Perl
tells you nothing.
have you ever used pointers in c to build a tree or anything else? ever
had a null pointer cause a core dump? that is infinitely harder to debug
than perl references. having done both for decades, i think i can say
that accurately.
a phrase i use is compleity arises from layers of simplicity. a single
hash is simple, a large data tree which is made from simple hashes can
be very complex. references are how that works.
How do you manage that?
i manage by know how to code with references. :)
The program(mer) will want to work with the data rather than with
cascaded references to it, and in the unlikely case cascaded references
would be wanted, they could still be created. The references are merely
an obstacle.
then how will you organize that data without references? think about it
for a minute. there is no good answer to that question. if you think
refs are obstacles, you have plenty to learn. data is complex so they
they complex structures. life can't live in single hashes.
Like I said, I put it into a database. That allows me to work on a very
simple layer with just the data I need to work with, saving me all
problems with organizing the data because I can leave that to the
database.
huh? again what about cross connected tables, external links and such?
db's don't make that magically appear in memory.
Of course, I need to design the database in a suitable and reasonable
way. That isn't too difficult.
you haven't designed complex databases i bet.
References make this worse, not any better.
that makes no sense. you don't like them because you don't understand
complex structures and how to build them. i mentioned c pointers and you
haven't said anything about them. have you worked with c pointers? they
are cousins of references (a ref actually contains a c pointer in it)
all complex structures in ANY language need some way to have one
structure hold another. perl uses references. c uses pointers. lisp uses
dotted pairs. etc.
i am out of this thread. you are not interested in learning references.
i can't do more for you in that case.
thanx,
uri
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
