On 27 May 2017 at 00:01, lee <l...@yagibdah.de> wrote:
> You have a variable.
Even in C, you'd have a variable as well. It would be a variable that
contains a *pointer* to a data structure.
The variable may be *typed*, but *types* don't impact anything about
the data storage in memory.
*types* in C are mechanisms that direct the compiler how to handle the
memory the variable deals with.
>
>> Because as far as I'm concerned, I have both data structures and
>> references in play.
>
> As far as I'm concerned, you seem to have assigned a reference to the
> variable, and what it might be referring to is difficult to figure out.
>
> Some sort of construction that resembles a hash seems involved. As far
> as I'm concerned, hashes are key/value pairs. I don't consider them as
> data structures any more than, for example, an integer. They are a
> given element of the language which can be useful when you have a bunch
> of values you want to refer to by names.
>
> So I'm not sure what you have there.
It is a variable that references a hash, whos values in turn reference hashes.
Accessing the value "total" is as simple as:
$var->{memory}->{total}
This is not entirely unlike C where you look up a struct member of a
struct which has a nested struct within.
var.memory.total
( I think )
The real distinctions being that structs are compile-time semantics
that boil expressions down to memory offsets in the block, whereas the
Perl equivalent is not quite so bounded, and the memory addresses are
computed at runtime.
They're rather different at the machine level in how the actual data
is laid out, but from a users perspective, multi-level structs and
multi-level hash references are equally convenient.
How you define a "Data structure" and how the C version being "a data
structure" and the Perl version "not a data structure" is a little
confusing to me, because to me, a data structure is supposed to be an
abstract idea for laying out your data in a way convenient to coding,
and the implementation details of how that data structure works under
the hood are not too important, as long as the user visible promises
remain the same.
>> References are not a low level mechanic that only the Perl VM needs to
>> care about.
>>
>> References are a mechansim to allow data structures to be passed
>> *without copying*
>
> Yes, that works nicely in C.
>
>> my $x = 5;
>> my $y = $x; # x is a copy of y
>>
>> However, if I do:
>>
>> my $x = 5;
>> $y = \$x
>>
>>
>> Y is now a reference to X
>
> $y = 5;
>
> Now $y is 5. That is what's evil.
All you're saying here is there's no strong typing.
That's pretty much just par for dynamic languages.
That is, it doens't mean there are no data structures, it means there
are no compile time constraints that prevent storing bits classes as
one type of data in a container that previously held another.
>
>> If I now do:
>>
>> ${$y} = 10
>>
>> X changes.
>
> Yes, and that's a horrible notation.
That's a matter of preference really. Pointer notation in C is worse
because it uses the same syntax for multiple different purposes.
>
>> Its a useful tool, that programmers have uses for.
>>
>> If you think they're evil, then you're probably thinking too much in C.
>
> They are evil in perl because the notation is unwieldy, especially when
> you need to de-reference a reference. That they are indistinguishable
> from non-references doesn't help.
They're not entirely indistinguishable, the Perl VM can tell, that's
what the "ref" built-in is for.
They're not *visually* indistinguishable, but C is no different if the
scope where the variable was defined is not currently in your screen.
fun( foo, bar );
^ Tell me what foo and bar are, _and_ tell me what types fun() takes
in C from that statement alone.
>
> Perhaps I do think too much in C --- at least such things are much
> easier to deal with there. It could be easier in perl, too.
>
>> Because you can't do any real work in perl *without* references.
>
> Why is that? Because arrays are transformed into lists when passed as
> arguments to functions?
>
> What do you consider "real work"?
>
>> *Objects* in perl are blessed references.
>
> I don't know yet what "blessed" is supposed to mean.
Consider a struct in C like:
{
void *data,
char *class,
}
All perl reference types are somewhat analogous to this, but normal
references have the "class" slot undefined.
"blessing" a reference sets the class slot to a class name.
Then later,
$object->method
The "->" resolves the "Class" slot of the reference, and then does
method-resolution on the named class for the method "method", and then
invokes:
Resolved::Class::method( $object )
"blessing" is simply what we call the act of filling the class slot,
which turns a "reference" into a "blessed reference"
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
