[32633] in Perl-Users-Digest
Perl-Users Digest, Issue: 3908 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 22 21:09:22 2013
Date: Fri, 22 Mar 2013 18:09:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 22 Mar 2013 Volume: 11 Number: 3908
Today's topics:
a logic excursion <rweikusat@mssgmbh.com>
Re: a logic excursion <jimsgibson@gmail.com>
Re: a logic excursion <rweikusat@mssgmbh.com>
Re: a logic excursion <rweikusat@mssgmbh.com>
Re: a logic excursion <ben@morrow.me.uk>
Re: a logic excursion <ben@morrow.me.uk>
Re: die alias <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Re: die alias <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Re: Identifying functions in C files and replacing them <tzz@lifelogs.com>
Issue: unexpected value in $2 (Perl 5.10.1) <john@castleamber.com>
Re: Issue: unexpected value in $2 (Perl 5.10.1) <ben@morrow.me.uk>
Re: Object attribute representation <rweikusat@mssgmbh.com>
Re: Object attribute representation <ben@morrow.me.uk>
Re: Object attribute representation <tzz@lifelogs.com>
object representation redux (term?) <rweikusat@mssgmbh.com>
Re: object representation redux (term?) <tzz@lifelogs.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 22 Mar 2013 14:03:42 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: a logic excursion
Message-Id: <87r4j7zg3l.fsf@sapphire.mobileactivedefense.com>
This is going to be totally dull and of no interest or use to anyone
except a logic geek.
------------
A programming language can only be used if it is useful for solving
real problems.
Java is being used. [*]
Therefore, Java is useful for solving real problems.
The Java object system is restricted to single inheritance.
Java is useful for solving real problems.
Therefore, an object system restricted to single inheritance is useful
for solving real problems.
An object system useful for solving real problems cannot have
limitations precluding such use.
An object system limited to single inheritance is useful for solving
real problems.
Therefore, 'being limited to single inheritance' does not preclude an
object system from being useful to solve real problems.
XXX is an object system limited to single inheritance.
Being limited to single inheritance does not preclude an object system
from being useful to solve real problem.
Therefore, XXX is not precluded from being useful to solve real
problem because it is limited to single inheritance.
-------------
It should be noted that 'Java is being used a lot' figures only insofar
in here as it makes [*] 'an undisputed fact'. This obvsiously still
needs some goodwill on the part of an interpreter because of the
'fuzziness' of natural language.
A 'real' ad populum fallacy:
Only good tools can ever become popular.
Hashes are a popular way to represent Perl objects.
Therefore, hashes are a good way to represent Perl objects.
------------------------------
Date: Fri, 22 Mar 2013 10:05:59 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: a logic excursion
Message-Id: <220320131005599328%jimsgibson@gmail.com>
In article <87r4j7zg3l.fsf@sapphire.mobileactivedefense.com>, Rainer
Weikusat <rweikusat@mssgmbh.com> wrote:
> This is going to be totally dull and of no interest or use to anyone
> except a logic geek.
>
> ------------
> A programming language can only be used if it is useful for solving
> real problems.
>
> Java is being used. [*]
I am using Java ...
>
> Therefore, Java is useful for solving real problems.
... to solve real problems.
>
> The Java object system is restricted to single inheritance.
... and Java includes the concept of Interfaces, plus many other useful
characteristics.
>
> Java is useful for solving real problems.
>
> Therefore, an object system restricted to single inheritance is useful
> for solving real problems.
... as long as that object system includes something akin to Interfaces
and other useful constructs.
>
> An object system useful for solving real problems cannot have
> limitations precluding such use.
>
> An object system limited to single inheritance is useful for solving
> real problems.
... as long as that language has sufficiently useful other
characteristics (such as Interfaces).
>
> Therefore, 'being limited to single inheritance' does not preclude an
> object system from being useful to solve real problems.
>
> XXX is an object system limited to single inheritance.
>
> Being limited to single inheritance does not preclude an object system
> from being useful to solve real problem.
>
> Therefore, XXX is not precluded from being useful to solve real
> problem because it is limited to single inheritance.
You seem to be focusing only on the single-inheritance characteristic
of languages to determine whether or not they are useful. I believe
that you must consider all the characteristics of a language in
deciding whether or not it is useful for a particular task. I find both
Perl and Java useful in my work, for different reasons and for
different tasks.
> -------------
>
> It should be noted that 'Java is being used a lot' figures only insofar
> in here as it makes [*] 'an undisputed fact'. This obvsiously still
> needs some goodwill on the part of an interpreter because of the
> 'fuzziness' of natural language.
>
> A 'real' ad populum fallacy:
>
> Only good tools can ever become popular.
>
> Hashes are a popular way to represent Perl objects.
>
> Therefore, hashes are a good way to represent Perl objects.
I don't believe anybody is claiming that hashes are a good way to
represent Perl objects because they are popular. I believe that hashes
are popular because they are good. The advantages the hashes have over
other schemes have been discussed. Personally, I prefer the simplicity
of hashes, but then I don't do a lot of OO programming in Perl.
--
Jim Gibson
------------------------------
Date: Fri, 22 Mar 2013 17:27:23 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: a logic excursion
Message-Id: <87mwtvibus.fsf@sapphire.mobileactivedefense.com>
Jim Gibson <jimsgibson@gmail.com> writes:
> Weikusat <rweikusat@mssgmbh.com> wrote:
>
>> This is going to be totally dull and of no interest or use to anyone
>> except a logic geek.
>>
>> ------------
>> A programming language can only be used if it is useful for solving
>> real problems.
>>
>> Java is being used. [*]
>
> I am using Java ...
>
>>
>> Therefore, Java is useful for solving real problems.
>
> ... to solve real problems.
>
>>
>> The Java object system is restricted to single inheritance.
>
> ... and Java includes the concept of Interfaces, plus many other useful
> characteristics.
>
>>
>> Java is useful for solving real problems.
>>
>> Therefore, an object system restricted to single inheritance is useful
>> for solving real problems.
>
> ... as long as that object system includes something akin to Interfaces
> and other useful constructs.
That's besides the point here since this was supposed to provide a
chain of proper 'premises and conclusions' showing that pointing at
Java as an example of a widely-used OO system limited to single
inheritance and claiming that this would demonstrate that single
inheritance OO systems are useful for solving real problems is not 'an
appeal to popularity'.
As I wrote in another posting: 'Interfaces' in Java are essentially a
workaround for (intentional) limitations of the Java compiler. It is
necesary to inform this compiler 'somehow' that two unrelated objects
provide compatible methods in order to be able to exploit this
fact. This isn't necessary in Perl because it is rather a message
passing system and 'methods' (as represented by their names) are not
tied to the classing implementing them.
[...]
>> Therefore, XXX is not precluded from being useful to solve real
>> problem because it is limited to single inheritance.
>
> You seem to be focusing only on the single-inheritance characteristic
> of languages to determine whether or not they are useful.
In this was, this was "demonstrating that single-inheritance cannot be
a crippling limitation of an OO system".
[...]
>> A 'real' ad populum fallacy:
>>
>> Only good tools can ever become popular.
>>
>> Hashes are a popular way to represent Perl objects.
>>
>> Therefore, hashes are a good way to represent Perl objects.
>
> I don't believe anybody is claiming that hashes are a good way to
> represent Perl objects because they are popular. I believe that hashes
> are popular because they are good.
That's exactly the same reasoning error: Hashes may be a good 'general
purpose solution' but whether they are a popular general purpose
solution doesn't matter for this (except if 'good' is defined as
'popular').
> The advantages the hashes have over other schemes have been
> discussed.
This disadvantages have been 'discussed' to some degree (namely, by
me) but a discussion of the advantages is still missing. "Can somehow
be used to implement multiple inheritance" isn't one since arrays can
also "somehow be used to implement multiple inheritances" and since
"multiple inheritance" isn't something which is useful because of
itself: There are a good many situation where it isn't needed.
------------------------------
Date: Fri, 22 Mar 2013 18:01:16 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: a logic excursion
Message-Id: <87ip4jiaab.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> This disadvantages have been 'discussed' to some degree (namely, by
> me) but a discussion of the advantages is still missing.
There's actually a 'covert point' about that in Jim Gibsons posting,
namely
| Personally, I prefer the simplicity of hashes
Which could be understood as 'they can be used to access properties by
name without declaring them' and they can also be used to provide
data inheritance 'without declaring anything' based on the convention
that all packages sharing an anonymous has must use unique property
names.
I'll leave that as it stands because these are valid concerns.
------------------------------
Date: Fri, 22 Mar 2013 18:42:20 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: a logic excursion
Message-Id: <c9lu1a-r603.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> This is going to be totally dull and of no interest or use to anyone
> except a logic geek.
>
> ------------
> A programming language can only be used if it is useful for solving
> real problems.
Vague. 'Useful' implies more than simply 'can be used', and a language
'can be used' for purposes other than 'solving real problems'. A more
precise statement would be
A programming language can only be used for solving real problems if
it can be used for solving real problems.
which is obviously a tautology (but then, this is logic).
> Java is being used. [*]
...to solve real problems.
Haskell (for example) is 'used' extensively, but not I think 'to solve
real problems' in the sense you mean.
> Therefore, Java is useful for solving real problems.
Therefore Java can be used to SRP.
> The Java object system is restricted to single inheritance.
>
> Java is useful for solving real problems.
...can be used...
> Therefore, an object system restricted to single inheritance is useful
> for solving real problems.
...can be used...
> An object system useful for solving real problems cannot have
> limitations precluding such use.
A object system which can be used to...
> An object system limited to single inheritance is useful for solving
> real problems.
>
> Therefore, 'being limited to single inheritance' does not preclude an
> object system from being useful to solve real problems.
Being limited to single inheritance does not make an object system
impossible to use, it just makes it a lot less convenient.
> XXX is an object system limited to single inheritance.
>
> Being limited to single inheritance does not preclude an object system
> from being useful to solve real problem.
>
> Therefore, XXX is not precluded from being useful to solve real
> problem because it is limited to single inheritance.
You are missing the step which takes you from
XXX can be used to solve real problems.
to
XXX is a better solution, in general, than YYY.
for some YYY which is not limited to single inheritance of attributes.
Assembler can be used to SRP, and was, frequently, in the past. That
doesn't mean I would recommend it.
> A 'real' ad populum fallacy:
>
> Only good tools can ever become popular.
>
> Hashes are a popular way to represent Perl objects.
>
> Therefore, hashes are a good way to represent Perl objects.
Nobody is making that argument.
Ben
------------------------------
Date: Fri, 22 Mar 2013 20:18:51 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: a logic excursion
Message-Id: <buqu1a-kv03.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> This is going to be totally dull and of no interest or use to anyone
> except a logic geek.
In fact, there's a logical error here, as well as the semantic
imprecision: reasoning correctly in natural language is not easy. The
core of your argument is:
Let U be the set of all object systems which can be used to solve
real problems.
Let S be the set of all object systems which only allow single
inheritance of attributes.
Let j be the Java object system.
Let s be the 'slots' object system.
Axioms:
j is in U.
j is in S.
s is in S.
j is in U, and j is in S, therefore the intersection of U and S is
non-empty, and U and S are not disjoint.
Therefore 's is in S' does not imply 's is not in U'.
However, your assertion was 'Java is usable, therefore slots is usable';
that is, 'j is in U implies s is in U', which you have not proved, since
you have not proved the intersection of S and not-U is empty.
Ben
------------------------------
Date: Fri, 22 Mar 2013 15:08:33 +0200
From: George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Subject: Re: die alias
Message-Id: <kihl35$2o5m$1@news.ntua.gr>
Στις 22/3/2013 01:39, ο/η J. Gleixner έγραψε:
> On 03/21/13 17:01, George Mpouras wrote:
>> perldoc -f die and perldoc perlvar (search for __DIE__) for details.
>>
>> die is solved . Now I have to solve the print alias
>
> How many times are you going to post that?? Once is enough...
>
>
> http://lmgtfy.com/?q=perl+override+print
>
> I didn't really read about Devel::UncheckedOps because I'd never go that
> route.
>
> But seriously, it's going way beyond *normal* to go this route. Maybe a
> search/replace of 'print' to 'my_print' or something simple like that
> is enough.
# the following is doing the job
package IO::Override;
use strict;
use warnings;
use base qw<Tie::Handle>;
use Symbol qw<geniosym>;
sub TIEHANDLE { return bless geniosym, __PACKAGE__ }
tie *PRINTOUT, 'IO::Override';
our $OLD_STDOUT = select( *PRINTOUT );
sub PRINT
{
no strict;
shift;
my $var = $_[0] +1 ;
CORE::print $OLD_STDOUT ">>$var<<\n";
}
print 99;
------------------------------
Date: Fri, 22 Mar 2013 15:31:46 +0200
From: George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Subject: Re: die alias
Message-Id: <kihmem$75c$1@news.ntua.gr>
#simpler ,but there is no reason any more, the "remote" guy agreed to
use a printcustom
use strict;
use warnings;
tie *PRINTOUT, 'main';
sub TIEHANDLE { return bless {}, 'main' }
my $NORMALPRINT = select( *PRINTOUT );
sub PRINT
{
shift;
no strict;
print $NORMALPRINT ">>$_[0]<<\n";
}
print 'hello';
------------------------------
Date: Fri, 22 Mar 2013 10:09:03 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Identifying functions in C files and replacing them with a keyword through PERL
Message-Id: <87fvzny1a8.fsf@lifelogs.com>
On Mon, 18 Mar 2013 20:59:48 +0000 Ben Morrow <ben@morrow.me.uk> wrote:
BM> Well, Inline::C has a limited C grammar, but I don't know if it will do
BM> what you want. You may have to start with the grammar in the C standard,
BM> and Parse::RecDescent.
BM> If I were doing this I might try mucking around with nm and objdump to
BM> get the compiler to find the functions for me. gcc -gstabs followed by
BM> objdump -G on the object file seems to give some useful information (the
BM> n_desc field of an SLINE entry seems to be a line number).
BM> Alternatively, ctags -x also looks quite promising.
According to
http://digitocero.com/en/blog/exporting-and-visualizing-gccs-abstract-syntax-tree-ast
you can use `gcc -fdump-tree-original-raw ./test.c' to dump the AST in a
pretty easily parseable format like this:
@43 function_type size: @35 algn: 8 retn: @8
prms: @48
@44 parm_decl name: @49 type: @8 scpe: @31
srcp: test.c:3 argt: @8
size: @13 algn: 32 used: 0
@45 identifier_node strg: char lngt: 4
Perhaps that approach works for the OP? It will tell them exactly where
the function is declared in the source.
Ted
------------------------------
Date: Fri, 22 Mar 2013 16:21:11 -0600
From: John Bokma <john@castleamber.com>
Subject: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <87wqsz3wko.fsf@castleamber.com>
The following piece of code assigns an unexpected value to $2 in a
program I am working on. When I run tests, it works as expected, but
when I run the actual program (which parses currently 2 large XML files)
$2 gets assigned a random value when the second XML file is parsed [1]:
$iso_gmt =~ /^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)Z$/
or croak "Not a valid ISO GMT date time: '$iso_gmt'";
# Note: without the assingment below $2 might be set to a different
# value for an unknown reason (bug in XML::Parser C code?)
# perl, v5.10.1
#my $month = $2;
my $seconds_since_epoch;
my $error;
$seconds_since_epoch = timegm( $6, $5, $4, $3, $2 - 1, $1 - 1900 );
$iso_gmt = '2012-10-30T21:05:01Z';
Examples of errors:
Month '20129103' out of range 0..11
Month '11826511' out of range 0..11
Month '20079951' out of range 0..11
Month '15160655' out of range 0..11
Month '21972303' out of range 0..11
Month '10208591' out of range 0..11
0133254f - 20129103
00b4754f - 11826511
0132654f - 20079951
00e7554f - 15160655
014f454f - 21972303
009bc54f - 10208591
^^^ looks like there is a pattern.
Uncommenting the assignment of $2 to $month removes the effect.
Reversing the parse order of the 2 XML files also removes the effect.
Anyone a suggestion (or 2) to pin point what goes wrong here (or is this
a know bug?). It looks like memory accidentally gets overwritten.
[1] using XML::Parser
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: Fri, 22 Mar 2013 23:44:23 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <nv6v1a-ue2.ln1@anubis.morrow.me.uk>
Quoth John Bokma <john@castleamber.com>:
>
> The following piece of code assigns an unexpected value to $2 in a
> program I am working on. When I run tests, it works as expected, but
> when I run the actual program (which parses currently 2 large XML files)
> $2 gets assigned a random value when the second XML file is parsed [1]:
>
> $iso_gmt =~ /^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)Z$/
> or croak "Not a valid ISO GMT date time: '$iso_gmt'";
> # Note: without the assingment below $2 might be set to a different
> # value for an unknown reason (bug in XML::Parser C code?)
> # perl, v5.10.1
> #my $month = $2;
> my $seconds_since_epoch;
> my $error;
> $seconds_since_epoch = timegm( $6, $5, $4, $3, $2 - 1, $1 - 1900 );
This code doesn't call XML::Parser. Where are you calling it?
Also, I would usually want to assign the return value of m// rather than
relying on globals:
my ($year, $month, $day, $hour, $min, $sec) =
$iso_gmt =~ /.../;
> $iso_gmt = '2012-10-30T21:05:01Z';
>
> Examples of errors:
>
> Month '20129103' out of range 0..11
> Month '11826511' out of range 0..11
> Month '20079951' out of range 0..11
> Month '15160655' out of range 0..11
> Month '21972303' out of range 0..11
> Month '10208591' out of range 0..11
>
> 0133254f - 20129103
> 00b4754f - 11826511
> 0132654f - 20079951
> 00e7554f - 15160655
> 014f454f - 21972303
> 009bc54f - 10208591
>
> ^^^ looks like there is a pattern.
Where does this output come from?
> Uncommenting the assignment of $2 to $month removes the effect.
> Reversing the parse order of the 2 XML files also removes the effect.
>
> Anyone a suggestion (or 2) to pin point what goes wrong here (or is this
> a know bug?). It looks like memory accidentally gets overwritten.
The output of Devel::Peek::Dump($2) at various points would be helpful.
If you can it would also be worth trying with a perl built with
-DDEBUGGING, to see if you get an assertion failure.
Ben
------------------------------
Date: Fri, 22 Mar 2013 02:08:50 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Object attribute representation
Message-Id: <87zjxwyyml.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
> a. Who, exactly, do you think cares about this little rant?
Since you apparently can't get over this 'efficient' habit, any
attempt at discussing anyhting with you is evidently a waste of time.
------------------------------
Date: Fri, 22 Mar 2013 03:01:40 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Object attribute representation
Message-Id: <k5us1a-6bh2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> > a. Who, exactly, do you think cares about this little rant?
>
> Since you apparently can't get over this 'efficient' habit, any
> attempt at discussing anyhting with you is evidently a waste of time.
Rants about copyright, or whatever it is you were complaining about, are
OT for clpmisc. Also, your habit of continually digressing into
unpleasant remarks about someone or something irrelevant is starting to
get on my nerves.
Ben
------------------------------
Date: Fri, 22 Mar 2013 17:16:05 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Object attribute representation
Message-Id: <87boabw2y2.fsf@lifelogs.com>
On Fri, 22 Mar 2013 03:01:40 +0000 Ben Morrow <ben@morrow.me.uk> wrote:
BM> [Rainer's] habit of continually digressing into unpleasant remarks
BM> about someone or something irrelevant is starting to get on my
BM> nerves.
Phew, I thought I was the only one annoyed by that. AWKWARD!
Ted
------------------------------
Date: Fri, 22 Mar 2013 10:51:15 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: object representation redux (term?)
Message-Id: <878v5fso64.fsf@sapphire.mobileactivedefense.com>
To pull this again together for the benefit of people who might be
interested in the issue iself or who have or want to solve actual
problems with Perl:
It is easier to provide data inheritance with arrays than it is with
hashes because arrays 'decouple' the problem of providing a
user-friendly way of accessing object properties from the problem of
allocating 'locations to store properties' to individual packages/
classes: Only the number of slots a package needs matter for reserving
a suitable number of array locations and not their names. This means a
derived class can make a request like 'I need five properties' and
these can be placed in the array immediately after any superclass
allocations and so forth. The obvious problem that accessing
properties by index number isn't sensible can be resolved by declaring
constants which map 'friendly names' to slot numbers and with the help
of some fairly simple 'slot allocation code' like the one I posted in
the first posting of the 'needless flexibilities' thread, the
allocation itself can be automated altogether: All which remains to be
done for code which needs a number of reserved array slots accessible
by name is to declare the names and the name of the immediate
superclass in the data inheritance hierarchy (which might but doesn't
necessarily have to be identical to one of the packages listed in
@ISA --- this may be considered a needless complication [especially by
'deer oil' salesmen] but adding 'metaproperties' to @ISA beyond its
language-defined meaning doesn't seem sensible to me).
Such a scheme is inherently limited to single-inheritance situations
because there is no (easy) way to allocate different slot numbers to a
package appearing at different relative location in more than one
'data inheritance graph' (Is this the right term? I think a 'tree' is
something can only have a single root but this may be
wrong). Considering that languages which don't provide multiple
inheritance are widely used (IOW, Java), this restriction doesn't seem
to cripple an 'OO system' beyond the point of usefulness (which
coincides with my experience from 20+ years of 'OO
programming'). Since the problem of possible name collisions would
need to be resolved for hashes 'somehow', they don't offer an
out-of-the-box solution either and using hashes when their more
flexible slot allocation scheme is actually needed remains an option.
In addition to this, array accesses will usually be faster than hash
accesses because the mapping of names to slot numbers always happens
at compile time, a slot can be located by doing a simple calculation
(start of the array + slot number * size of a pointer) and there's no
risk that different names actually map to the same slot number (aka
'hash collisions') and that the accessing code has to perform a linear
search for a certain string key on a linked list (hash tables can be
implemented in other ways but this is the easiest, most common and
IMHO most sensible way). Because a hash table needs to be larger than
the number of keys actually stored in it, arrays will also tend to be
more compact than hashes (they will usually be larger than necessary
when growing dynamically in order to reduce the number of
reallocations which are need to cope with adding a sequence of new
elements to the end of an array).
Because of all this, I consider arrays a better choice as 'general
purpose' object representation object than hashes.
A remark about accessor methods
-------------------------------
Class users are not supposed to be aware of class implementation and
because of this, most 'object properties' shouldn't need "getter" and
"setter" methods (people who mutiliate their mother language in this
way without even thinking about it are generally not people whose
opinion on 'how to use language sensibly' matters ...). They usually
shouldn't be needed for access to the properties itself, either,
because derived classes are also class users and they also shouldn't
have to worry about implementation details of their ancestor classes,
not even at the (pseudo) 'abstract' level of 'somehow provided
properties with specific names'.
Since people are so fond of 'authorities':
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dbec07bac614a61e3392c1e7c08cc6a49ad43f7a
NB: 'Accessor funtion' here isn't supposed to mean
static inline unsigned
get_core_internal_state__do_not_mess_with_it(struct ... *)
static inline void
set_core_internal_state__do_not_mess_with_it(struct ... *, unsigned)
That's just the 'next best option' the "But I WANT !! [Waeeeh!] to
mess with it" people have found for convincing others that they should
really be allowed to.
------------------------------
Date: Fri, 22 Mar 2013 17:13:08 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: object representation redux (term?)
Message-Id: <87fvznw32z.fsf@lifelogs.com>
On Fri, 22 Mar 2013 10:51:15 +0000 Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
RW> To pull this again together for the benefit of people who might be
RW> interested in the issue iself or who have or want to solve actual
RW> problems with Perl:
[rest omitted]
Please, stop. You've written enough (on this).
Ted
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3908
***************************************
