Re: Perl 6 OO and bless
John Siracusa [EMAIL PROTECTED] writes: On 1/18/06 11:06 PM, Rob Kinyon wrote: 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. 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 :) 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 [EMAIL PROTECTED] http://www.bofh.org.uk/
Re: Perl 6 OO and bless
On 1/19/06, chromatic [EMAIL PROTECTED] wrote: On Thursday 19 January 2006 19:50, Rob Kinyon wrote: 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. ... but ... 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? I can't reconcile these two paragraphs. 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. 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. 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. 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
Re: Perl 6 OO and bless
On Friday 20 January 2006 07:14, Rob Kinyon wrote: 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(). 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
Re: Perl 6 OO and bless
On Thursday 19 January 2006 21:53, Stevan Little wrote:
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?
Yes.
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).
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.
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?
From Perl 6? Yes.
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).
Agreed.
With p5, you /can/ get to the underlying data structure. This is a
break which will hamper the backwards compatibility effort I think.
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
Re: Perl 6 OO and bless
Rob Kinyon skribis 2006-01-18 20:57 (-0500):
Well, for one thing, you can't write OO code in P5.
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.
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.
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
Re: Perl 6 OO and bless
On 1/19/06, Juerd [EMAIL PROTECTED] wrote:
Rob Kinyon skribis 2006-01-18 20:57 (-0500):
Well, for one thing, you can't write OO code in P5.
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.
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.
C's filedescriptors are objects/invocants, and so are PHP's MySQL
resources.
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).
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.
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.
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.
Your definition of OO is far too specific for a 2-letter acronym.
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
Re: Perl 6 OO and bless
Rob Kinyon skribis 2006-01-19 9:15 (-0500): OOP is all about black-box abstraction. 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. To that end, three items have been identified as being mostly necessary to achieve that: I'd say these are extremely useful and highly desired, but theoretically optional. 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. 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 seems silly (to me) to cripple P6 out of a misguided effort to maintain backwards compatibility with P5. 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. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6 OO and bless
On 1/18/06, chromatic [EMAIL PROTECTED] wrote:
On Wednesday 18 January 2006 18:54, Stevan Little wrote:
Or are you thinking that a Perl 6 value should be blessed into a
Perl
5 package?
That's closer to what I had in mind.
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 :)
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 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.
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.
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.
Or maybe you are you thinking that a Perl 6 class can inherit from a
Perl 5 class?
Absolutely.
See the inheritence/MRO mismatch I described above. This would apply
here big time. It is not a trivial issue either.
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.
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.
Maybe delegation would be nasty, but so would be mixed MROs. You say
TOE-mato, I say TOW-mAto.
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.
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
Re: Perl 6 OO and bless
Rob Kinyon wrote: 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. [...] 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. [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
Re: Perl 6 OO and bless
On Wednesday 18 January 2006 20:02, Rob Kinyon wrote: On 1/18/06, chromatic [EMAIL PROTECTED] wrote: 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? 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. Unless, of course, if $omeone had promised backwards compatibility with LangZ 5 from LangY 6. 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. 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
Re: Perl 6 OO and bless
On 1/19/06, Rob Kinyon [EMAIL PROTECTED] wrote: 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. 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 :-) Javascript is a good example of this. Yet, even in JS, you have the prototype, which is the class. 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.
Re: Perl 6 OO and bless
On 1/19/06, chromatic [EMAIL PROTECTED] wrote: On Wednesday 18 January 2006 20:02, Rob Kinyon wrote: On 1/18/06, chromatic [EMAIL PROTECTED] wrote: 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? 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. Unless, of course, if $omeone had promised backwards compatibility with LangZ 5 from LangY 6. I'm not sure how that promise is broken if Perl 6.0.0 includes Ponie as part of the distribution. 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? 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. 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*. 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. Is that your objection to bless()? 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. 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. Exactly. :-) Rob
Re: Perl 6 OO and bless
On Thursday 19 January 2006 19:50, Rob Kinyon wrote: 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. ... but ... 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? I can't reconcile these two paragraphs. 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. 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
Re: Perl 6 OO and bless
On 1/19/06, chromatic [EMAIL PROTECTED] wrote:
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?
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).
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*.
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).
Is that your objection to bless()?
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.
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.
Yes, this will be an interesting one :)
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.
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
Re: Perl 6 OO and bless
Rob Kinyon skribis 2006-01-19 22:50 (-0500): There's already a mechanism in the P6 OO system for specifying the internal representation of the instance. 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. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6 OO and bless
On Wednesday 18 January 2006 14:13, Stevan Little wrote: 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? Interoperability with Perl 5 code. Now if you want to write a p6opaque - Perl 5 thunking layer -- c
Re: Perl 6 OO and bless
On 1/18/06, chromatic [EMAIL PROTECTED] wrote:
On Wednesday 18 January 2006 14:13, Stevan Little wrote:
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?
Interoperability with Perl 5 code.
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
Re: Perl 6 OO and bless
On 1/18/06, chromatic [EMAIL PROTECTED] wrote: On Wednesday 18 January 2006 14:13, Stevan Little wrote: 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? Interoperability with Perl 5 code. 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
Re: Perl 6 OO and bless
On Wednesday 18 January 2006 17:57, Rob Kinyon wrote: Well, for one thing, you can't write OO code in P5. 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.
Re: Perl 6 OO and bless
On 1/18/06, chromatic [EMAIL PROTECTED] wrote: On Wednesday 18 January 2006 17:57, Rob Kinyon wrote: Well, for one thing, you can't write OO code in P5. 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! 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. 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. 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
Re: Perl 6 OO and bless
On Wednesday 18 January 2006 19:11, Rob Kinyon wrote: 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). ... and I specify this exactly how? -- c
Re: Perl 6 OO and bless
On 1/18/06, chromatic [EMAIL PROTECTED] wrote: On Wednesday 18 January 2006 19:11, Rob Kinyon wrote: 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). ... and I specify this exactly how? 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
Re: Perl 6 OO and bless
On 1/18/06, chromatic [EMAIL PROTECTED] wrote: 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?). 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. Rob
Re: Perl 6 OO and bless
Excuse my ignorance of the finer points, but I thought the reason for bless's continued existence was so that the same sort of brilliant OO experimentation that Damian and others have done with pure Perl 5 can continue to be done in pure Perl 6 without having to hack p6opaque? Trey
Re: Perl 6 OO and bless
On Wednesday 18 January 2006 19:39, Rob Kinyon wrote: 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
Re: Perl 6 OO and bless
On 1/18/06, chromatic [EMAIL PROTECTED] wrote: On Wednesday 18 January 2006 19:39, Rob Kinyon wrote: 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? 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
Re: Perl 6 OO and bless
On 1/18/06, Trey Harris [EMAIL PROTECTED] wrote: Excuse my ignorance of the finer points, but I thought the reason for bless's continued existence was so that the same sort of brilliant OO experimentation that Damian and others have done with pure Perl 5 can continue to be done in pure Perl 6 without having to hack p6opaque? 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
Re: Perl 6 OO and bless
On 1/18/06 11:06 PM, Rob Kinyon wrote: 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. 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
Re: Perl 6 OO and bless
On Jan 18, 2006, at 10:41 PM, Trey Harris wrote: Excuse my ignorance of the finer points, but I thought the reason for bless's continued existence was so that the same sort of brilliant OO experimentation that Damian and others have done with pure Perl 5 can continue to be done in pure Perl 6 without having to hack p6opaque? 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
