Folks, this has passed the event horizon of what’s appropriate for the
Beginners list a good while back. If y’all wanna continue this conversation,
please kindly do so outside the bounds of this mailing list.
thanks,
john,
the resident list mom.
> On 25May2017, at 10:52, Uri Guttman <u...@stemsystems.com> wrote:
>
> 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/
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
