Re: Object Numify/Stringify-ing to Unique values
Yuval Kogman
> Hello all.
>
> In the processing of working with mugwump's shiny new perl6 OO Set.pm. I realized that we
> do not currently have a way to uniquely identify objects in Pugs like the way we have in
> perl5 (object stringification).
>
> So I asked Autrijus, and he promptly implemented a rudimentary object numification
> scheme, and requested I query the @Larry as to how this should really behave.
I think numification and stringification has given us lots of
unnecessary pain in p5. Look at all the broken modules which need to
be using Tie::RefHash or Set::Object but don't.
overload::StrVal($obj) is annoying to type, and annoying to read.
It's defensive programming that should have nicer means builtin to
the language. Furthermore, reliable, 100% correct (always) behavior
should be easier to do than broken behavior that seems OK, so that
people don't use it when they aren't future-proofing.
Overloading operators are there to allow us to pretend objects
really are the things they represent, for equality, printing, and
whatnot.
This is something else, and does not have to do with the fact that
the object is a perl object, a part of the data that the language
offers us. This has to do with the meaning we put into the building
blocks.
I think this should not be a behavior of the data, but something
returned from a meta method.
I'd like to be able to say
Or something with a similar meaning, but in a more concise way.
Perhaps an operator with ':' in it would be suitable.
--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me climbs a brick wall with his fingers: neeyah!
Stevan Little
In the processing of working with mugwump's shiny new perl6 OO Set.pm.
I realized that we do not currently have a way to uniquely identify
objects in Pugs like the way we have in perl5 (object stringification).
So I asked Autrijus, and he promptly implemented a rudimentary object
numification scheme, and requested I query the @Larry as to how this
should really behave.
So I ask ye, oh wise and powerful @Larry!!!! How is it we shall
uniquely identify our objects??? Please give us a sign?
your humble and over-(tired & caffinated) servent,
Stevan
... sorry, it has been a long day :)
Larry Wall
: Hello all.
:
: In the processing of working with mugwump's shiny new perl6 OO Set.pm.
: I realized that we do not currently have a way to uniquely identify
: objects in Pugs like the way we have in perl5 (object stringification).
That's what .id is supposed to do, without the bogus numorstringification
semantics. It should return something opaque that matches with ~~.
On the other hand, the point of =:= is that you can use it without
resorting to .id. Basically
$a =:= $b
should do the same as
Perhaps an id has a printable representation if you ask it nicely,
but you ought to be able to us an id as a key to an object hash without
going through stringiness, for instance.
In any event, it should be more like stringification than numification,
which is just asking for problems as soon as you get out of a uniform
memory model.
Larry
Autrijus Tang
> That's what .id is supposed to do, without the bogus numorstringification
> semantics. It should return something opaque that matches with ~~.
Okay, implemented as such.
What does unboxed values return for their "id", though?
3 =:= 3; # always true?
3.id ~~ 3.id; # ditto?
Thanks,
/Autrijus/
Larry Wall
I think immutable values could work that way, especially if we want to
store only a single representation of each immutable string. Basically
anything with an id can use that id as its hash key. On the other
hand, we don't want to start hashing a boxed immutable value as some
different value just because it got transparently boxed up, so we have
to be careful about that.
And in particular, if hash keys are to work as in Perl 5, we're really
taking an immutable snapshot of the mutable string and using that for
the key. In essence, whenever you modify a string, you're changing
its identity.
Larry