Perl 6 OO and &bless

In reading over the Synopsis again in hopes of finding more
information regarding the different repr types (see the warnocked
post entitled "Construction and Initialization of repr types other
than P6opaque"), I stumbled onto some issues with the Perl 6 OO model
and &bless.

In S02 it says:

Perl 6 is an OO engine, but you're not generally required to
think in OO
when that's inconvenient. However, some built-in concepts such
as filehandles
will be more object-oriented in a user-visible way than in Perl 5.

Now taking this statement one (logical) step further, and I assume
that this means things like arrays and hashes will (underneath) just
be objects. So we will have an ^Array class, and a ^Hash class, and
[] and {} will actually construct instances of ^Array and ^Hash
respectively. (Of course I am simplifying it here, these may be roles
instead of classes, but this is not relevant to the discussion really).

Then later on S12 says:

As in Perl 5, a constructor is any routine that calls bless.
Unlike in Perl 5,
you call it as a method on the class, passing the candidate as
the first
argument. To bless a hash as in Perl 5, say:

$object = $class.bless({k1 => $v1, k2 => $v2, ...});

Are we not just re-blessing an instance of the class ^Hash into
whatever $class is? That does not seem to be what is intended,
however, if {} is a constructor for an instance of ^Hash, and I can
call methods on {} like any other object ({}.keys, {}.exists($key),
etc.), then what happens when I bless {} with a class? Do I loose
access to the methods of ^Hash? Are the methods only allowed to be
called in the non-invocant syntax (called like functions and not
methods)?

Which brings me to my real question:

Do we really still need to retain the old Perl 5 version of &bless?
What purpose does it serve that p6opaque does not do in a better/
faster/cleaner way?

Thanks,

Stevan

Interoperability with Perl 5 code.

Now if you want to write a p6opaque <-> Perl 5 thunking layer....

-- c

Well, for one thing, you can't write OO code in P5. You can write code
that behaves like you're in OO-land and that talks with an OO accent
(so long as you don't look behind the curtain), but it's not OO.

Given that, I'm not sure that conceptual interoperability with P5 code
should be a design goal, particularly in the OO-space. Allowing
methods to be called on references that have been associated with a
given package is an easy addition to the current MOP. Just add
.blessed_into and have a step right before AUTOLOAD (or method_missing
or whatever) to check .blessed_into and try that package, if one is
set.

Also, given that the semantics of a number of items is changing (
"".split(':') anyone?), how closely will P6 really mirror P5 behavior
given identical code?

Rob

I'll play your semantic game if you play my what-if game.

I have a fair bit of Perl 5 code. Ponie works. I want to migrate my Perl 5
code to Perl 6 slowly. Everything new is Perl 6 code. When I have a chance,
I migrate classes and modules from Perl 5 to Perl 6 code.

I have a handful of Perl 5 classes. One day, I need to subclass one of them.
Per my goal, I do so in Perl 6. Of course, it has to interoperate with the
Perl 5 in the system, per that pesky Liskov rule. If I can specify an
alternate internal representation for the object corresponding to the
appropriate internal representation for the Perl 5 class I'm extending,
great!

If not, your programming language sucks and doesn't do what the box leads me
to believe that it should do -- especially if the answer is "Well you
shouldn't want to do that."

-- c

PS - You can't write procedural code in Haskell. You can't write functional
code in C. You can't write readable code in Ada.

Okay, I think that's out of my system now.

How so? Please elaborate how you see this working?

Are you thinking that one would be able to bless a Perl 5 reference
into a Perl 6 package?

I would argue then that we really don't need Perl 6 &bless for this,
and we can just use Perl 5's &bless. After all, if Perl 5 can call
Perl 6 functions, then Perl 5 will need to understand Perl 6's
packages, and vice-versa. If this is true then Perl 5's bless should
be able to accept a Perl 6 package value and DWIM. However, this
would probably be a somewhat ugly solution to whatever problem it is
you are trying to solve since your Perl 6 code would be weighted down
with Perl 5 OO-isms. In fact, I would argue that doing it this way is
not the right way, and instead using Perl 6 OO and delegating to a
Perl 5 object is a better option.

Or are you thinking that a Perl 6 value should be blessed into a Perl
5 package?

I think there is a real serious issue here since the hash the Perl 5
package would be expecting is a ref to an HV, and the Perl 6 value it
would be getting would be an instance of the ^Hash class (itself a
subclass of ^Object). This is actually where i see the fundemental
problem with a Perl 6 &bless which is capable of blessing Perl 6
references. There are no Perl 6 references like we had in Perl 5,
they are *all* objects now. Would not the Perl 5 layer see the Perl 6
instance of ^Hash as an object? If not, then we must already have a
Perl 6 opaque (the ^Hash instance) to Perl 5 HV converter/proxy/magic-
jellybean/thunk so I don't need to write it :)

Or maybe you are you thinking that a Perl 6 class can inherit from a
Perl 5 class?

To be honest, i think this is better handled with delegation, and can
even be automated using the attribute delegation features described
in A/S12.

The biggest problem with this would be object initialization. The
normal Perl 6 BUILDALL/BUILD code could not be used here since Perl 5
does not have the meta-object protocol to support such behaviors, nor
is there a common enough Perl 5 object initialization idiom to work
with here. The end result is that you probably end up having to do a
bunch of manual initialization code.

And let's not forget that our Perl 6 blessed hash is not the same as
the Perl 5 blessed hash, so there might be confusion/issues there
too. We also have the issue here of where does ^Object fit into our
inheritance now? Is the Perl 5 package the top of our @ISA tree? or
do we insert ^Object in there somewhere too?

Or maybe you are you thinking that a Perl 5 class can inherit from a
Perl 6 class?

Well since Perl 5 inheritance is really just a package name in the
@ISA, this is trivial to get method inheritance since Perl 5 already
can understand Perl 6's packages. And lets assume that the Perl 5
&new uses the (somewhat common) idiom and just calls SUPER::new(@_)
and re-blesses the returned Perl 6 instance. Let's assume too that
the Perl 6 constructor just blessed a Perl 6 instance of ^Hash. Again
we have the mismatch between the ref to an HV and the ref to an
instance of ^Hash. This brings us back to our Perl 6 opaque (the
^Hash instance) to Perl 5 HV converter/proxy/magic-jellybean/thunk
thingy.

So in conclusion, I think that a Perl 6 &bless which acts like a Perl
5 &bless is not as useful as your seem to indicate. It is certainly
not the magic bullet of interoperability. I don't think we can really
avoid not having a p6opaque->p5-blessed-ref magic-thunker.

However, maybe I am missing something here, if so, please elaborate
and explain.

Thanks,

Stevan

I think the more relevant question is "How do I subclass a Ruby class
in Python and delegate to it from a Perl6 object that's used in a
Perl5 module that's implementing the event loop for a Java app?"

The answer, of course, is that everything is mediated by Parrot (or
whatever VM they all choose to target). Just because one side is Perl6
and the other side is Perl5 doesn't mean that they should have any
closer of a relationship than Ruby and Python would. They are separate
languages, related only through a common creator, a shared community,
and the same VM. Nothing less, nothing more.

As for how that will be handled, I would think that it would be as follows:
- in Perl6, objects created in another language will be treated as
p6opaque (unless some other unbox is a more suitable $repr).
- in Perl5, objects created in another language will be treated as
inside-out objects.

The box you're talking about is the box with "Parrot" on the cover,
not Perl6. And, you most definitely want to be able to do what you're
suggesting and it will be possible.

You'll just have to give up on the mismeme of &bless, and I think
you'll find that oddly freeing.

Rob

Not really, but depending on the what Perl 6 bless() does it might work.

In the long-term sure. However, I don't know how far interoperability will
get if we expect everyone to do everything The Right Way all at once.

That's closer to what I had in mind.

Why would Perl 6 bless() bless references? I've always seen it as specifying
the underlying storage container for the object's instance data. (Hey, my
last rigorous reading of S12 predates my current project. I could be wrong.)

If Ponie is there and this code runs on Parrot and Ponie uses Perl 5 PMCs,
they're theoretically available to Perl 6, with the proper invocations or
magic or thunking or whatever.

Absolutely.

I have serious doubts about round-tripping with delegation, having tried to do
it. I want to subclass a Perl 5 class with Perl 6 code and use objects of
that class within Perl 5 code without them having to know that I'm doing
something sneaky.

It'll be a true pity if that's *truly* impossible.

Sure, but that's a per-representation thunking layer writable in Perl 6 code.
It might be somewhat tricky, but it's not completely hideously unsolvable
code -- if it's possible.

I'm not nearly Australian enough for that kind of madness.

I'm pretty sure that's not what I was advocating. I'm pretty sure the design
thinking has always been:

1) by default, your object is opaque
2) if you don't want this, you can always use bless()

For interoperability with Perl 5 classes, I don't want to use an opaque
object. Ergo, I want to use bless() (or something, but does that explain why
I think bless() is important?).

I don't want to translate opaque objects into blessed references. They should
be opaque everywhere. I do want the option to rewrite as little Perl 5 code
as possible just to get the program to work, though.

-- c

... and I specify this exactly how?

-- c

I was intending for that to mean that Parrot might indicate that the
representation in Perl6 for a Perl5 object could be p6hash instead of
p6opaque, but that might be a little too clever.

I was thinking, actually for interoperability with something like C++
where your classes are laid-out-in-memory structs (which is the best
reason I've heard for having alternate $repr). There certainly is no
good reason within Perl6 itself to muddy up the waters like that.

You really want to read
http://svn.openfoundry.org/pugs/docs/notes/piln_object_repr_types.pod

Rob

Trey

> No, you want to specify the $repr in CREATE(). But, p6hash will still
> not be the same as a ref to an HV. Frankly, I think you're better off
> letting Parrot mediate things the same way it would mediate Ruby and
> Perl6 or Perl5 and Python. Worrying about it in userland is just going
> to cause you headaches.

Answer me this then -- under your scheme, can I subclass a Perl 5 class with
Perl 6 code, instantiate the subclass, and use that object in Perl 5 code as
if the subclass were Perl 5 code, without rewriting all of my Perl 5 code?

-- c

No, you want to specify the $repr in CREATE(). But, p6hash will still

Rob

That's what the .meta and the MetaObject Protocol is for. Not to
mention that 90% of the hacking done in Class:: and Object:: will
handled by the fact that Perl6 has actual OO syntax. ("Look Ma, no
hands!") You won't need Class::MakeMethods because Perl6 will make
your accessors for you. You won't need Class::Std to protect your
instance data because p6opaque will ... well, it's opaque. :-)

As for the ability to "hook into" the P6 OO system, you'll have
CREATE, BUILD, BUILDALL, true NEXT semantics, and the ability to
completely rewrite the method dispatcher (if you really feel like it).
I think we've gone well beyond &bless.

Rob

You have two cross-language interactions.
1) Subclass a LangX class in LangY
2) Instantiate a LangY class and use that object in LangZ
That LangX === LangZ is irrelevant to the discussion.

So long as you aren't peeking behind the curtain (method calls only),
Parrot should be able to mediate everything. In other words, if your
code is good OO code, then you shouldn't have any problems.

Rob

There's more to life than simple get/set accessors. Method-makers will have
and a long and glorious life in Perl 6, I assure you :)

-John

Actually &bless only partially plays a role in all those whacky
things which so many whacky people have done with Perl 5. Without
AUTOLOAD, symbol table hacking and closures, &bless would not be that
exciting.

However, given a proper MOP (meta-object-protocol) the amount of
Object Oriented experimentation which will be possible in Perl 6 will
far exceed what you can do in Perl 5. Not to mention that it will
also be type-safe and far more reliable (read: you could *actually*
use it in production).

And not to put down all of the brilliant OO experimentation that has
been done in Perl 5, but it is not always as cutting edge as one
might think. A good amount of the really crazy cutting edge OO work
is being done with either Smalltalk or CLOS and the fact they both
have well defined and studied MOPs is probably a major reason for that.

Stevan

Nonsense. OO isn't a set of features, and OO isn't syntax.

Granted, syntax can really help to understand OO, and a set of features
is nice, because it avoids having to re-invent wheels.

But OO is just that: object orientation. It is a way of programming, and
that can very well be done without any syntax or features for that in
place.

C's filedescriptors are objects/invocants, and so are PHP's MySQL
resources.

Perl 5 has syntax for OO, and even a few useful features. Even though
these are not needed at all to write OO code, it certainly does help
people to stick to OO design.

And if more features are needed, CPAN has them.

Object orientation is still object orientation if you write it
differently: "$bar->{foo}->()", if that's how you decide to write a method
call on $bar, is still OO.

Classes, like OO syntax, are not necessary for OO.

Your definition of OO is far too specific for a 2-letter acronym.

Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

I've said those very same things on Perlmonks. I stand by them, yet I
still maintain that you cannot write truly OO code in P5.

OOP is all about black-box abstraction. To that end, three items have
been identified as being mostly necessary to achieve that:
1) Polymorphism - aka Liskov substitutability
2) Inheritance - aka specialization
3) Encapsulation

P5 excels at #1, does #2 ok, and fails completely at #3. Now, one can
argue whether the programmer should make the decision as to whether
strong encapsulation is desirable, but the point is that you cannot
create encapsulation in Perl that someone else cannot violate.

Hence, you cannot write OO code in Perl.

I point you to http://www.perlmonks.org/?node_id=112180 where I say
that Perl's scalars are objects. I have since realized that tilly is
right, particularly after learning a more OO language (which just
happened to be Ruby).

Javascript is a good example of this. Yet, even in JS, you have the
"prototype", which is the "class". Unless you plan on building
everything by hand, you still need a model for the new instance you're
creating. That model is the class. It's not an OO requirement, but an
OO consequence.

OO is a spectrum, not a point. What I was trying to say was that when
comparing the OO you can do in P5 with the OO you will be able to do
in P6, it seems silly (to me) to cripple P6 out of a misguided effort
to maintain backwards compatibility with P5.

Rob

This is probably the fundament of our disagreement.

OO is about objects, which CAN BE but DO NOT HAVE TO BE
black-box/opaque.

It is customary, and good style, to treat objects as black boxes, but
their actual implementation can differ, given proper abstraction.

I'd say these are extremely useful and highly desired, but theoretically
optional.

Neither can you in any language that lets you poke into its internals.
However, that means that the internals define a property of the
language, which I think is reversed logic.

It's as useful as Inline::Java. That means different things to different
people. To me, it means I can re-use code more easily.

If that predates the latest update then you should read again. It
hasn't changed all that much on this subject though so maybe not.

I think the problem is that S12 is kind of fuzzy about this
"underlying storage"/"alternate repr for opaque" issue. Without a
really clean and well reasoned description of all that, and how it
all works together there will be little hope of Perl 6<->Perl5
interoperability on the level you desire.

Well, yes, we can push this all down to Parrot, which IMO is the
right place for it to be handled. But in that sense then Perl 6's
interaction with Perl 5 will be no different than Perl 6's
interaction with (Python | Ruby | Tcl | etc). Which means there will
be some restrictions on the depth of the interaction.

If we want to have the level of interoperability which you seem to
think we should have (and I tend to agree with you that it would be
nice), then we need to either;

1) Have a Perl 6 OO -> Perl 5 OO thunking layer

This would mediate things between the two OO models so that neither
would have to be restricted by the other. This would be possible with
some minor (but fairly complex) extensions to the Perl 6 MOP.
Basically we would need to create a Perl 5 MOP of sorts which would
have the appropriate thunks in the appropriate placed to make things
Just Work.

2) Force some basic rules/restrictions upon the interoperability.

Well to start with, if Perl 5 code would need to treat the Perl 6
code as black boxes. It wouldn't be able to do $self->{attr}, it
would have to do $self->attr(). The Perl 6 code would have to handle
the Perl 5 data structures in a similar way (not sure the details of
that though). There would also need to be some rules about
inheritence. Perl 6 uses the C3 algorithm to determine the method
resolution order, while Perl 5 uses the depth-first-left-to-right
approach. This would mean that a Perl 5 class which uses multiple
inheritence with some Perl 5 classes and some Perl 6 classes would
have a rather hairy time determining the method resolution order.
Maybe we would say that the Perl 6 class would *have* to use pre-
order (depth-first-l-to-r) and could not use C3.

I could go on here, but there are enough mismatches between the two
OO models that there would have to be some kind of ruleset.

See the inheritence/MRO mismatch I described above. This would apply
here big time. It is not a trivial issue either.

Maybe delegation would be nasty, but so would be mixed MROs. You say
TOE-mato, I say TOW-mAto.

Of course, everything is possible on some level, but making it easy
for the newbie is the really really hard part.

I don't think it's madness, and I am not Australian. If it goes one
way, it *should* go the other way, period.

I am forking this part of the discussion to another thread. I think
that Perl 5 interoperability is not dependent upon bless and that
bless in Perl 6 is inherently broken. (more on that later :)

Then you will limit your interoperability. The Perl 5 code needs a
way into the Perl 6 opaque type, and vice versa, otherwise we end up
with only behavioral inheritance and no state inheritance.

I agree.

Stevan

[...]

[sarcasm]
Indeed. In fact, in any language where coders can discover the
implementation
of your code they might depend upon or circumvent your wishes. Ergo, no open
source code can be considered OO. In fact, if p6 isn't going to compile
programs down to a binary representation-indeed, if it doesn't encrypt
the resulting binary-there's no reason for anyone to ever use "object"
and "perl6" in the same sentence. Woe are we.
[/sarcasm]

Dude, this isn't slashdot. Taking some recondite position and then
defending it against all comers doesn't earn karma, or get you
clickthroughs, or earn you mod points. If you think that trying to be
backward compatible will have negative impacts in the long run, say
that. As it is, I've just spend an hour reading

"Can't do it"
"Can too!"
"Can not!"
"Can too!"
"Well, it might awkward, is all I'm sayin'"

There's $150 you owe me. That's 180 bottles of Yuengling.

As for the encapsulation thing, here's my take on it: I'm not a "perl
programmer". I'm a coder. I write stuff in whatever language makes
sense: PHP, sh, perl, C, Batch. That means that I don't keep track of
the status of all the CPAN modules, not do I particularly care about the
personal lives and traumas affecting their authors.
BUT, CPAN makes Perl rock IMO because it can really increase my
productivity (and I'm a consultant, so I always need to be more
productive than everyone else). So if there's a problem I can easily
state, I go look on CPAN to see if someone has already solved it.

Sadly, it's only very rarely that the module is really "drop-in". The
rest of the time it goes like this:

1. Given this module, can I drop it in and have it work?
2. No. Okay, can I change some of my code to interface to it?
3. No. Can I write a hook that will get the behavior I want?
4. No. If I subclass/extend it, can I trivially get what I want?
5. No. Is there another module I should consider?
6. No. Is the code itself readable and comprehensible so I can extend it?
7. No. I guess I write it myself.

(Any yes answer returns, or at least yields.)

Encapsulation isn't something you have to strive for. Encapsulation is
something you have to work really hard to avoid. Because the only time
I'm looking at (gasp!) violating encapsulation is when I have determined
that your module is the best of the bunch (or at least closest to what I
want) and IT DOESN'T WORK. So I'm opening the hood to answer questions 4
(unless your docs are good) or 6.

That means that apparently the stars are in alignment, because I'm
agreeing with Chromatic (for the second time, I think). Backward
compatibility means a bunch of modules that will work, and that can be
extended. I don't have to insert question 3a: "Is this written in P6 so
I can do stuff with it?"

I'm sure a lot of the "obvious" modules will be rewritten in P6 really
soon. DBI, for instance. A lot of the "bottom feeders," are only really
useful when you're in a rare circumstance. They're REALLY useful,
though, when you're in that circumstance. Statistically, some authors
are dead. Some have seen the sacred light and switched over to
programming Ruby (or the LOTW). Some are zoned out in a crack house in
some dark metropolis. But if the compatibility is good I can still use
their code. Saved! (By someone who really wanted to code a Maori
calendar module...)

=Austin

Unless, of course, if $omeone had promised backwards compatibility with LangZ
5 from LangY 6.

In other words, your answer to my question is "no". Fine.

Next question. If Ponie and Perl 6 are both running on Parrot, and if Ponie
has PMCs that represent Perl 5 data containers, such as p5hash, p5array,
p5symbol, and so on, what's the problem with having a Perl 6 object that uses
one of those PMCs as its internal storage?

I realize one of Stevan's objections is "But if you use a Hash, does your
object automatically support the .keys method and .kv and so on?" to which I
reply "No, of course not. That's silly. It just uses the Hash for
*storage*."

Is that your objection to bless()?

I don't mean to handwave here -- there are definitely issues to consider when
crossing a language boundary related to method dispatch (and the last I
remember from design meetings was "things change there and you shouldn't
expect that they stay the same"), but the resistance to allowing different
storage types for objects completely baffles me.

Or is the question about "Why is there a need for bless() when you can already
pass arguments to CREATE()?" In that case I dunno.

-- c

If you're a purist, paranoid "nobody better touch my code, ever"
mindset[1], then you're right, Perl 5 fails at encapsulation.
However, you could also say that Java fails at encapsulation because
it provides reflection, C++ fails at encapsulation because it allows
direct memory access, leaving only Eiffel which doesn't fail at
encapsualtion because its designers were paraniod idiologues :-p.

Perl the language, like a natural language, is interwoven with its
culture. Perl does not fail at encapsulation when you consider the
cultural mores that one shouldn't touch the inside of an object and
that one shouldn't rebless an object. Saying that Perl 5 has no
encapsulation means that you break these mores on a regular basis, and
deserve to be punished by society :-)

Perl 5's "class" is the package and the body of "new".

Luke

[1] Which I argue is not a productive mindset in all cases. Sure, it
works most of the time. Most of the time it ends up creating better
code. But not all the time. Sometimes, to get our jobs done, we need
to look inside the modules we are using; modules which weren't
designed to be extended in the way we have in mind. Yes, it makes it
so your code could break when the module is updated by the authors,
however it beats the pants off of implementing the module yourself,
especially if you don't know anything about that domain. It is an
easy trade to exchange a little maintenance effort when the author
updates the module for the reuse of 10,000 lines of code.

Broken encapsulation is not the root of all evil. However, it's
possible that premature broken encapsulation is; that is, when you
trade breaking encapsulation for a little extra work to create a
better design, you're digging yourself into a hole. But sometimes a
better design isn't "a little extra work" away; sometimes it's a heck
of a lot.

I'm not sure how that promise is broken if Perl 6.0.0 includes Ponie
as part of the distribution.

Nothing. Just like it's not a problem if Perl6 uses one of the
Ruby-specific PMCs for storage. In fact, the alternate $repr idea is
specifically to allow for the use of foreign datatypes as storage.
Luke's excellent example is to use a C-struct as your storage.

Storage of what? What are you trying to do that you need to use an
object to store your attributes? Why aren't you just using the method
-that- object is using?

And, for the record, I'm currently working on a proposal to p6l to
restrict object representations to unboxed types. So the problem that
Stevan is worried about in this objection would become moot.

No. My objection to bless() is BUILD() and CREATE(). There's already a
mechanism in the P6 OO system for specifying the internal
representation of the instance. In fact, if you're crazy enough, you
can specify that at runtime. In other words, the functionality of
bless() has already been subsumed into the OO system and is called by
a few different names.

Exactly. :-)

Rob

... but ...

I can't reconcile these two paragraphs.

This is Perl. The "there should be one obvious way to do it" ship, canoe,
raft, and water wings have sailed, paddled, floated, and inflated.

-- c

Okay, so when you say alternate storage then you mean that a class
like this:

class Foo {
has $.bar;
method new ($class, %params) {
$class.bless('p5Hash', %params);
}
method baz {
$.bar += 1;
}
}

should use a PMC representation of a p5 hash as it's storage, and
that the method baz does the right thing here?

Because that makes sense to me. However, what doesn't make sense
would be if I had to write &baz like this:

method baz {
self->{'bar'} += 1;
}

In other words, if this is just a detail of the storage, and does not
affect user code at all, then I am okay with it. This though would
mean that you would not have direct access to the underlying data
structure (the p5 hash).

Okay, then I assume you mean it to behave the same way as with the
p5hash, that it is completely transparent to the user that you are
using a p5hash or a p6hash or a p6opaque?

In which case,.. I say okay. But note again that you have not
provided access to the underlying data structure (the p6hash a.k.a -
an instance of ^Hash).

Yes, that is my objection, because while the alternate storage
approach discussed above is actually a very interesting feature, it
does not fit with the p5 vision of &bless.

With p5, you /can/ get to the underlying data structure. This is a
break which will hamper the backwards compatibility effort I think.

Yes, this will be an interesting one :)

Well as you say in your reply to Rob, TIMTOWTDI. I will agree with
you here if they are in fact 2 ways to do the same thing. This would
actually solve and simplify some issues in the metamodel currently.

And to be honest, I have absolutely no real "objection" to &bless. I
just don't think the current treatment of it is consistent with some
of the stated goals of the Perl 6 design.

Stevan

Now there's the actual problem in its baremost form: indeed the *P6* OO
system has that, but the *P5* OO system (excuse me for calling it that)
did not. The two are wildly incompatible, but we do want both. Well,
perhaps you do not, but many of us here do.

It is possible to have one's cake and eat it too. Consider:

Foo.bless($x)

where $x contains an Bar object. We can check if Foo is a subtype to
Bar -- for example, Foo.bless({some => 'hash'}) would check whether Foo
conforms to the Hash interface.

If so, then we safely reuse the underlying representation for storage:

class Foo does Hash { has $.a; has $.b }
my %args = (a => 1, b => 2);
my $obj = Foo.bless(%args);
%args.{'a'} = 999;
say $obj.a; # 999
say $obj.{'a'}; # 999

If not, we explode $x into named arguments and dispatch to .CREATE to
make an p6opaque representation. Hash and Array are thus turned to
pairs; a Scalar would have to contain an arglist or a pair, otherwise
it'd fail the named-only prototype check. To wit:

class Bar { has $.a; has $.b }
my %args = (:a<1>, :b<2>);
my $obj = Bar.bless(%args);
%args.{'a'} = 999;
say $obj.a; # 1, not 999
say $obj.{'a'}; # Error -- no such method: postcircumfix:<{ }>

Note that A12 used to say that all Objects does Hash, and %$obj even
returns private attributes when used inside the class scope.
Fortunately, S12 doesn't mention anything like that, so I think the
treatment above is safe.

Audrey

The second paragraph was referring solely to where you're dealing with
Parrot datatypes only. If you have to go outside of Parrot (to a C
lib, for instance), then you do need to know about the storage
specifics.

And there is. You can create your own meta-object protocol on top of
p6opaque or any other representation you want. This is *Perl6* - you
can rewrite the whole damn grammar if you want to. You can use another
VM if you want to. (PIL^N runs on Javascript!)

I think this entire issue is rising out of the fact that very very few
people in this discussion are familiar with the design of the MOP.
Stevan and a few others are the primary movers and I'm lucky enough to
have been Stevan's sounding board for a few pieces. Once you grok the
MOP, it's really hard to imagine wanting to use bless(). It's
literally like trying to explain to a BASIC programmer why recursion
is good or trying to explain to a C programmer why automatic memory
management is handy. The frames of reference are so different that the
meaning being trasmitted is not the meaning being received.

Rob

We still need something to bridge that gap, whether that particular
mechanism is available or not. The p5-to-p6 translator needs to
figure out what to do with things like this:

$x->{whatever}

In isolation, we can't know whether that should translate to

$x<whatever>

or

$x.whatever

So either p5-to-p6 does type inferencing (from some very dynamic p5 code!)
or we fudge it to emit some construct that defers the decision to p6, at
either compile time or run time, but p6 compile time still only works if
we have a compile-time typed $x, which is likely to be undecidable for
a lot of code coming from the p5 universe.

On the assumption that p6 has to make the decision then, we have three
alternatives:

Write $x.whatever, fall back to hash subscript on method call failure
Write $x<whatever>, fall back to method call on non-hash
Write $x.punt('whatever'), and take an extra redispatch hit every time

My original intent was #2, hence the wording in A12. But to speak to
some of Stevan's concernes, there's something going on here which is
not quite "Object does Hash". It's more like "Object can do Hash",
in the linguistic sense that a "Noun can do Verb", but nonetheless
remains a noun. A fallback role is not the same as a normal role.
Maybe there's some way to mixin in a fallback Hash role without
clobbering a real Hash role that is already there, so that if your
Hash container is an object you don't see methods for its keys.

Something like this might also let us distinguish p5ish scalars that
are simultaneously Num and Str from scalars that, say, intrinsically
do Num but can emulate Str in a pinch without caching the result.
I don't think we have a good way of expressing that distinction right
now.

This seems to imply that a given role like Hash could have two default
implementations--one for an actual Hash container, and one that emulates
a Hash by deferring to the Object. It's sort of like a role that can
delegate back to its own object.

For simplicity, we might prefer to leave the Hash role alone as a
normal hash, and provide some way of registering emulation fallback
capabilities, in a tie-ish sort of way, but tied to types instead
of to individual containers, so you could know to look for a FakeHash
role or some such.

But rather than forcing people to register fallbacks, it might be a lot
nicer to establish some intrinsic relationship between a role actually
does the thing and a role that merely fakes it in terms of something else.

But maybe all this is already possible in the current setup, if

role ObjectFakeHash does Hash {...}
role Object does ObjectFakeHash {...}
class Hash does Hash {...}

So ObjectFakeHash would just grab the Hash interface but override the
default implementation. I think that would give us the fallback semantics
I'm looking for without doing great violence to anything else.

But maybe someone can come up with a better way. Maybe we can come
up with some kind of lexically scoped solution instead, if we decide
it's just a language emulation issue. But my hunch is that it's
a deep tagmemic/metaphorical problem we're trying to solve here.
Such issues arise whenever you start making statements of the form
"I want to use an A as if it were a B." The problem is much bigger
than just how do I translate Perl 5 to Perl 6. It's questions like:

What makes a particular metaphor work?
Will the cultural context support use of an A as if it were a B?
How do we translate the user's thoughts to the computer's thoughts?
How do we translate one user's thoughts to another user's thoughts?
How do we know when such a translation is "good enough"?
How do we know when our mental model of an object is adequate?
How do we know when the computer's mental model of an object is adequate?
What does adequate mean in context?
Will the culture support partially instantiated objects? :-)

That's tagmemics, folks. The main problem with tagmemics is that, while
it helps you ask good questions, it doesn't give you easy answers for 'em...

Anyway, I'd still kinda like to find some way to use an object
"as if" it were a hash, partly to solve my immediate problem, but
also because I think a good computer language might address the
"as if" problem better than any of them do currently. In general,
hypotheticality is still something that humans are much better at
than computers. We're still just nipping around the edges with "fail",
"let", environmental variables, STM, roles, and junctions. But we'll
not get true AI until a computer can understand a sentence like

In a hole in the ground there lived a hobbit.

as if it were a human. A human has the ability to execute "new Hobbit"
before "class Hobbit" is even defined! Humans are not much into
strong compile-time typing, and when they are, we call it stereotyping,
or racism, or whatever.

Well, I'm just blathering now...

Larry

I don't have much to say on the deeper question, but I have a few
ideas on the P5 -> P6 translation question, especially as it relates
to OO:

1) Don't translate at all. Ponie, delegating to Parrot, is
supposed to handle all of that OO garbage in the same way that Ruby
and Python are going to interact with Perl6. Perl5 and Perl6 are as
similar as Ruby and Python, so you might as well write a translator
between them as one between Perl5 and Perl6.

Pros: Larry doesn't have to do anything more on the WMoT.
Cons: The community, for some reason, really wants this
auto-translator, even though there wasn't one for P4->P5 and P5->P6 is
a greater leap than P4->P5 was.

2) Don't attempt to translate $x->{whatever} (or $x->[2] or
$x->('whatever') ... ) in isolation. If it occurs within a function
defined in a package that has a function that uses bless and it's the
first parameter, it's an attribute access. Otherwise, it's a hash
access.

Pros: It's a nice and easy rule which will work if the programmer
didn't violate encapsulation, only puts methods in classes, and is
generally an all-around nice guy.
Cons: See Pros.

3) Since about half of all classes in P5-land use some module in
Class::* to auto-generate stuff (thus providing a nice place to find
all the attribute names), ask the community to provide a translator
for each of those. Then, use #2 for the others.

Pros: The WMoT can punt in about half the cases.
Cons: The WMoT cannot punt in about half the cases.

Rob

I don't think that it's a fair assumption that, for example, I haven't
followed the metamodel discussions and designs. Nor do I think it's a fair
assumption that people who want to interoperate with a lot of Perl 5 code
should have to understand the finer points of metamodels and metaobject
protocols in the default case.

-- c

Yes.

I don't think it's impossible, but it's fairly ugly and I'm okay if you can't
do it by default from the Perl 6 side. I certainly wouldn't use it.

From the Perl 6 side, I would rather use Perl 6 looking code.

From Perl 6? Yes.

Agreed.

With Perl 5, you can *appear* to get to the underlying data structure. Yet
tie() is basically free on Ponie and there's a metaclass mediating access to
the underlying storage. I think that makes the problem solvable.

(Does using an alternate type of storage mean you need an alternate metaclass?
Perhaps, perhaps not -- but the practical effects of syntax have to come from
somewhere.)

As long as you can use Perl 5 classes in Perl 6 without rewriting all of the
Perl 5 code, I'm happy.

-- c

%

-- Larry Wall in <20060120203...@wall.org>

And now back to your regularly scheduled meaningful discussion already
in progress.
--
Jeff Stampes [ jeff.s...@xilinx.com ] -- Build and Release Tools
The older a man gets, the farther he had to walk to school as a boy.

But (as I understood it) the P4->P5 leap was not intended to be so great
that a translator would be needed. In fact, that confuses cause and effect.
Because the technology wasn't there to write a translator, it constrained the
size of the leap. The important part was that for Perl 5 to still be Perl,
it had to keep running the vast majority of Perl scripts.

In fact, Perl 5 still strives to maintain Perl 1 compatibility (and the
perl5-porters joke is that even thinking about breaking this is the fastest
way to summon the thought, er backwards compatibility police with a script
he's been running unchanged since 1987). Why else can you still:

$ perl -le '$h{1} = "Perl"; print values h'
Perl
$ perl -le 'push a, "Perl"; print @a'
Perl

I believe that the translator is seen as needed (even by @Larry, I think)
to maintain the same level of continuity in the Perl 5->6 transition as
Perl 4->5 - your existing monolithic script runs on the newer Perl
interpreter, and you can edit (within that same file) as and when you need
to.

Otherwise you're in the situation where you can only inter-operate languages
the whole file level. Which means that it's the same actions to migrate from
Perl 5 to (say) Python as from Perl 5 to Perl 6. And somehow I think that
$Larry has some bias about which language he'd prefer everyone to find it
easiest to migrate to, even if he's too modest to admit it.

Nicholas Clark

Yes, I think that's the way to go, as well as :coerce<as> for explicit
class-based (instead of role-based) conversions.

Audrey

Excellent.

Actually I was thinking this might be the best approach. I have been
dabbling more and more with CLOS lately and am not seeing where a
full-fledge attribute meta-object is probably a really good idea (in
the current model the meta-attribute is very very slim).

Yes, this is the ultimate goal. I never wanted to get rid of &bless,
only to resolve what I saw as an inconsistency with the use of &bless
and some of the other aspects of the Perl 6 design.

Stevan

I agree it is a hairy subject, but the more I think about this (and
the more i read about and play with CLOS) I think we might be able to
accomplish something very close to this by creating more special
purpose attribute meta-objects.

By moving much of the actual attribute accessing work to the attribute
meta-object, we can very easily have arbitrary object "types" since
all their access is mediated through the attribute meta-object.

In CLOS this would be accomplished by subclassing the standard-class,
and telling it to use the different attribute meta-object by default.
The of course you slap a juicy LISP macro around it, and you are ready
to go. Mmmmmm LISP macros :)

Basically my point is that the meta-classes and meta-objects govern
the behavior of the classes and object. So if we want to change the
behavior of our classes and objects, we just subclass the meta-classes
and meta-objects and specialize the behavior as we desire.

This should all be possible with attribute meta-objects. Basically
when we encounter this type of need (in p5->p6 translated classes, or
otherwise), the compiler (or possibly the translator) needs to
discover this need, and change the metaclass appropriately. The self
delegation then Just Works.

Of course this is all just hand-waving right now since the current
metamodel does not support such deep magic. But hey, I have been
thinking it might be time for a v3 soon anyway :)

I am actually working with Rob Kinyon on a meta object protocol for
Perl 5 for our $work. It does not try to make Perl 5 anything it is
not, instead it only attempts to define the workings of the Perl 5
object system and provide clean hooks into it. It is in the very early
stages, and needs lots of testing, but it might help to bridge the two
models.

Hmm, do you mean lazy objects? As in, only instantiated as much as is
absolutly necessary at a particular moment?

I recently read a paper on an extended version of CLOS (yay CLOS)
which demonstrated how lazy classes could be built, including ones
with strict initialization orders ($a must be initialized before $b,
but $b depends on $c, etc). But maybe this is not what you mean.

Or is this the "class but undef" idea again?

Audrey and I have "solved" this by creating a 'p6undef' repr type
which allows the class to be instantiated and methods called on it,
but if you try to access anything other than basic meta information,
it will fail (because it's just undef).

Actually, I think this partial object thing needs it own thread
really. But I will let you decide when you are ready for that one :)

Stevan

I refer the interested reader to all the handy dandy method makers
(and other tricksy class methods) to be found in the Ruby on Rails
framework...

--
Piers Cawley <pdca...@bofh.org.uk>
http://www.bofh.org.uk/

Let me take a (feeble) crack at this:

It sounds like we're talking about something vaguely akin to C++'s
typecasting, where you treat an object of a given class as if it were
an object of a different class. Another way to phrase this is that
you temporarily want to add role to the object. "but" doesn't work
because you don't want the new role's default behavior to clobber
existing behavior that the object already has. Perhaps "like"
instead, with the understanding that "$obj like Hash" means "try
$obj's dispatching first; if that doesn't work, try Hash's
dispatching".

The role in question needs to be an emulator, in that its methods
should have defaults that will make sense when mixed into the object
in question. Therefore, Hash probably _wouldn't_ work, since Hash
probably isn't set up to work with $obj's internals. You'd either
have to explicitly provide an appropriate emulator, or implicitly have
Hash find it (i.e., maintain a list of roles that do Hash, along with
a way to test each against $obj's class for compatability). The
latter is probably a bit too much effort.

Or am I completely missing the point?

The essence of this is that you don't need to know everything about
class Hobbit in order to make use of it. As with Stevan Little's
reference to "lazy objects", you only need to know as much about
Hobbit as is to be used to complete your current task. In this case,
you don't need to know _anything_ about a Hobbit, yet. By the time
you _do_ need to know something about it (such as how to form a mental
image of one), the script will presumably have given you the
neccessary information. If not, you're likely to say something like
"what's a Hobbit?"

a.k.a. "forward referencing". :)

--
Jonathan Lang

Actually this might not be a bad approach in this case. Take this for instance:

method foo (Foo $self, $key) {
((Hash) $self){$key}
}

The syntax is ugly, but it makes what you are doing more explicit. I
would also think that in most cases this could be compile time checked
(if we can check $self's type (Foo), we can make sure Foo does/isa
Hash).

Here are some other ideas for a typecasting syntax using "as" for the
keyword (which IIRC is taken for coercion??):

$self as Hash {
# $self is treated as a Hash inside the block
$self{$key} = $value;
}

# it could also return a wrapped
# $self for use in wider scopes
my $h = $self as Hash;
$h{$key} = $value;

Anyway, it's just a early morning (not enough coffee in my system) thought.

Stevan

Isn't typecasting a DesignSmell? This kind of overloading is, imnsho,
going to cause more coding bugs and is going to be considered a design
flaw in P6.

If there is need to treat something as a Hash, then provide it with a
postcircumfix<{}> and leave it at that. It's highly unlikely that you
will want to add Hash-like behavior to something that already has a
postcircumfix<{}> because it probably has that behavior already.

Rob

General typecasting is probably a really really bad idea, I agree. But
some tightly controlled typecasting (shhh dont call it that or the
C/C++/Java programmers will freak out), might be useful in this case.
If you like, you can think of this as coercion, and not typecasting,
in fact this is probably the better word for it anyway.

Well this is in relation to how to deal with an object which is a
blessed p6hash, in which case you may or may not want to have a
^Hash-like interface for it (you might even want to overload the
^Hash-like interface too).

So, let me explain myself (hopefully) more clearly.

Lets say we treat infix:<as> as a general purpose coercion operator.
So that things like:

$num as Str;

will pretty much DWIM since a number can be easily coerced into a
string (at least 99% of the time, I am sure some of the math whizzes
will tell me different so I leave the 1% for that ;).

Now, in order for C<$self as Hash> to make sense, $self would have to
be coercable into a Hash in some way. If $self is a blessed p6array
this might not make that much sense, so we would die because the
coercion failed. However, if $self is a blessed p6hash, then it would
make plenty of sense (IMO at least). It would allow us to get at the
underlying representation without having to sacrifice flexibility in
the class from which $self came. Basically you could do things like
this:

class Golum;

method new (Golum $class, Hash %params) {
$class.bless(%params);
}

method postcircumfix:<{}> (Golum $self, Any $key, Any $value) {
die "Nasssty Hobbitses" if $value.does(Hobbit);
$self as Hash {
$self{$key} = $value;
}
}

We could also do this with the p5hash representation too, assuming we
have a ^P5Hash of some kind (which is probably not a bad idea really).

Anyway, I now have some more caffine in my system (coffee,.. yummy),
not that it makes the idea any better, but at least it is more
detailed ;)

Stevan

[snip]

How about just inheriting from Hash?

class Gollum extends Hash;

$self.NEXT.{}( $key, $value );
}

Rob

Well, postcircumfix:<{}> is not just for emulating Hash :)

class struct;

has @.struct_def;
has $.struct_name;

method postcircumfix:<{}> ($class, Array of Pair @struct, $name) {
$class.new(
struct_def => @struct,
struct_name => $name
);
}

Then you could do something like this maybe:

my $jedi_struct = struct{(
first_name => 'Luke',
last_name => 'Skywalker'
)} = "jedi";

At least I assume you can, taking advantage of the "a class is
prototypical instance" thing to call postcircumfix:<{}> like that.

But I just might have had too much caffine at this point though ;P

Stevan