Take. It. Off. The. List.
I've asked nicely. Now I'm telling you. Take it off the list.
John
List moderator.
--
John Anderson // j...@genehack.org
> On May 26, 2017, at 19:09, Kent Fredric <kentfred...@gmail.com> wrote:
>
>> 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/
>
>
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
