HaloO Larry,
you wrote:
: >we need only provide an alternate comparison to
: >the constructor, and the set itself needn't remember it. On the
: >other hand, hashes behaving like mutable sets need to remember their
: >comparison operator if it is not the default.
:
: The slot accessor paradigma again...
: Isn't the comparator a free method subtype? Why interfering
: at construction time?
I haven't the foggiest idea what you are asking, but here are some
random answers.
Trying to lift the fog ;)
My point is to distinguish between on-board methods and self-contained,
free methods that are not stored or referenced through a vtable
or similar device from every object. Since slots are a metaphor on the
smallest part of an object I call these method invocations slot calls.
The syntactical destinction as pair juxtaposition $obj:action() is an
idea to make it more obvious that :action is firstly retrieved from
$obj somehow and then invoked by applying .() while $obj.action() looks
up .action and then dispatches according to the type of $obj.
A Comparator would be a free method. As such it defines a meaning and
users can hook in more implementations for certain types. In this approach
the method information is needed at compile time before the "search" of
syntactical invocant expressions starts. E.g. '.foo' needs the invocant to
the left or from some standard variable if there is nothing syntactically.
We don't want to force everyone to specify it every time, because defaults
are friendly.
So you want to install a Comparator into a Hash instance that is used
for *all* contained values? Or for enforcing unique keys? Or are you
talking about a Comparator that is to be used when the hash is compared
to a set value? But that would be the Method subtype Comparator[Hash,Set]
anyway.
Whose construction time? The hash's? Because that's when you'd want
to override the default.
Or are you just carping that you don't believe in OO-ness? The whole
point of OO is that objects have state.
Yes, of course. I think it's more likely that I don't understand why
Perlkind is so obsessed with the container versus value distinction
on the language level. The only importance I see in this is that objects
are heavy-weight and as such recommend handling per reference and in-place
mutation. The latter is carried out at some level through slot calls
provided by the object itself. But more generic concepts are provided
through free methods where class implementors can hook into. If this
hooking shall happen on a larger scale than single methods, roles can
be used to compose classes.
With
my $set = set(1,2,3); # correct syntax?
my %hash = { 1 => true, 2 => true, 3 => true };
questions like
if %hash eqv $set {...}
if 3 (in) $set {...}
if %hash<3> {...}
have to be compiled to an actual test if the only thing you know
is that their result type is bool. If the compile time knowledge
is more specific---either true or false---then the test can be
skipped. E.g.
if 3 (in) set(1,2,3) { say 42; }
is just a verbose form of
say 42;
Ohh, perhaps you were talking about inhomogenious cases like
my $set = set(1,'2',Dog.new);
my %hash = { 1 => true, '2' => true, Dod.new => true };
such that you could force e.g. stringified comparison for
if $set eqv %hash {...}
If one of those answers doesn't suit, please feel free to make up another. :-)
Another question or another answer?
--
$TSa.greeting := "HaloO"; # mind the echo!
