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
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
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
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;
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
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
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
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
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
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,
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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.
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
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
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
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
29 matches
Mail list logo
