perl6-language@perl.org
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's &bless is (seriously) broken
Rob Kinyon skribis 2006-01-19 20:54 (-0500): > > > There are no references in Perl6. > > Is your Perl the same as that of other people on this list? :) > There are no references in Perl6 in the way Perl5 conceives of references. There are references in Perl 6. Do note that @foo evaluates to a reference to itself in scalar context, which isn't some magical auto-referencing thing. Likewise, a reference to an array is dereferenced when used as an array. This is automatic, but still not quite magical. References, their terminology, and their semantics still very much exist. > I'd say "learn Ruby to know what OO is", but I happen to know you > already know a nearly-pure OO language - Javascript. Somehow that makes me think you don't happen to know that I already know Ruby too. :) > Every single 'thing' in JS is an object - you can hang methods off of > a string literal or a number. Most objects in JS aren't references. They are what one would call a reference if the language were Perl. I'm very strictly limiting my jargon to Perl's, unless explicitly stated otherwise. For example, PHP's references are not references, but more like pointers and/or symbolic references, depending on which you choose to call "references" in PHP. Note, by the way, that JS has "primitive" strings, and Strings, only the latter being objects. Fortunately for us, though, a string is automatically promoted to a String when the string is USED AS an object. > > > &bless was a brilliant idea for Perl5. It's wrong for Perl6. > > I think it's needed to be able to convert Perl 5 code > > semi-automatically. But you have probably thought about this more > > than I, so I'll ask you: what's the alternative? > Well, there's two scenarios - you either run your P5 code using Ponie > or you attempt to use Larry's "Wondrous Machine of Translation". How would the latter work, if there's no bless? > But, if you must use the WMoT, then I suspect the following will happen: > 1) The WMoT notices your use of &bless and marks that package as a > class and that method as a constructor. > 2) It creates a Perl6 class for your use, noting the accesses into > the Perl5 reference that you used and calling those attributes. > 3) It then creates your BUILD() method, putting all the non-bless > components of your new() into it. Doesn't solve the problems as mentioned in this thread, like overlapping methods. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
perl6-language@perl.org
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
perl6-language@perl.org
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
perl6-language@perl.org
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
perl6-language@perl.org
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.
perl6-language@perl.org
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's &bless is (seriously) broken
On 1/19/06, Juerd <[EMAIL PROTECTED]> wrote: > Rob Kinyon skribis 2006-01-19 16:10 (-0500): > > There are no references in Perl6. > I have to admit, though, that I've never seen this statement, or > anything implying it. It's entirely new to me. > > Is your Perl the same as that of other people on this list? :) There are no references in Perl6 in the way Perl5 conceives of references. > Perl still has non-object types. They may represent objects internally, > but they work differently from what we've historically been calling > objects. Especially in assignment, the differences are huge, because an > object is considered a reference, while "real" scalars, arrays and > hashes evaluate to (a list of) their values, or a useful representation > (like the number of elements) when used in non-OO fashion. No. Objects are *NOT* considered references in most languages other than Perl5. Even in C++, the least OO language that could be considered OO, you can have non-reference objects. I'd say "learn Ruby to know what OO is", but I happen to know you already know a nearly-pure OO language - Javascript. Every single 'thing' in JS is an object - you can hang methods off of a string literal or a number. Most objects in JS aren't references. > > &bless was a brilliant idea for Perl5. It's wrong for Perl6. > > I think it's needed to be able to convert Perl 5 code > semi-automatically. > > But you have probably thought about this more than I, so I'll ask you: > what's the alternative? Well, there's two scenarios - you either run your P5 code using Ponie or you attempt to use Larry's "Wondrous Machine of Translation". Me, I choose the former. Now, I don't worry about how objects are mediated between languages - Ponie and Parrot have to do that for me. And, before you start worrying, this is a feature that was planned into Parrot from Day 1. Ruby and Python and Perl6 all have to interoperate, including inheritance from each others' classes. Perl5 <-> Perl6 will be no different. But, if you must use the WMoT, then I suspect the following will happen: 1) The WMoT notices your use of &bless and marks that package as a class and that method as a constructor. 2) It creates a Perl6 class for your use, noting the accesses into the Perl5 reference that you used and calling those attributes. 3) It then creates your BUILD() method, putting all the non-bless components of your new() into it. That's it. No &bless in Perl6 needed. Rob
Re: Perl 6's &bless is (seriously) broken
On Jan 19, 2006, at 5:19 PM, Jonathan Scott Duff wrote:
On Thu, Jan 19, 2006 at 11:07:49PM +0100, Juerd wrote:
Stevan Little skribis 2006-01-19 16:59 (-0500):
2) what if the role conflicts with other roles being does-ed by Foo?
Debugging hell there.
Very good point.
Aren't role conflicts resolved at composition time (possibly by
failure)? That doesn't sound like debugging hell to me, but rather
clear indication of a problem and the location of that problem.
Role conflicts are resolved when a role (or set of roles) is composed
into a class. In this case the (automatically generated) code would
look something like this:
method new ($class: %params) {
my $self = $class.bless(%params);
$self does Hash;
return $self;
}
Or it would have to detect it in the class definition itself, in
which case it would add a does Hash; to the class def somewhere.
The reason this would be debugging hell (IMO at least) is that *I*
never told it to does Hash, so as far as I knew there was no clashes
in the roles I composed. Sure if was educated in the finer points of
Perl 6 I would know what happened, but a random newbie would be half-
way to PHP by now.
Stevan
Re: Perl 6's &bless is (seriously) broken
On Jan 19, 2006, at 5:09 PM, Juerd wrote: Stevan Little skribis 2006-01-19 17:06 (-0500): This turns "everything is an object" into "everything can be used with OO syntax", which I think is more true Alternatively and simultaneously, "everything represents an object". Well, if "everything is NOT an object", then the synopsis need to reflect this. I was more thinking along the lines of "NOT everything is an object", "but some things are". Hmm, maybe we can add an "Object context" then. It would allow an something to be an object only when it is convienent for it to be so. ;) Stevan
Re: Perl 6's &bless is (seriously) broken
On Thu, Jan 19, 2006 at 11:07:49PM +0100, Juerd wrote: > Stevan Little skribis 2006-01-19 16:59 (-0500): > > 2) what if the role conflicts with other roles being does-ed by Foo? > > Debugging hell there. > > Very good point. Aren't role conflicts resolved at composition time (possibly by failure)? That doesn't sound like debugging hell to me, but rather clear indication of a problem and the location of that problem. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl 6's &bless is (seriously) broken
Stevan Little skribis 2006-01-19 17:06 (-0500): > >This turns "everything is an object" into "everything can be used with > >OO syntax", which I think is more true > >Alternatively and simultaneously, "everything represents an object". > Well, if "everything is NOT an object", then the synopsis need to > reflect this. I was more thinking along the lines of "NOT everything is an object", "but some things are". 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's &bless is (seriously) broken
Stevan Little skribis 2006-01-19 16:59 (-0500):
> But we cannot automagically inject a role into a class, for a number
> of reasons.
> 1) thats just plain evil
But then, so is bless, so the two can play along.
> 2) what if the role conflicts with other roles being does-ed by Foo?
> Debugging hell there.
Very good point.
> 3) What if Foo wants to have a .keys, .value, .exists, etc? Do they
> shadow the Hash version? What if Foo.keys is implemented using
> Hash.keys? Many issues abound here.
Even better point.
> >Sure, in Perl 5, you could have different kinds of references as
> >instances of the same class. But I don't recall ever having
> >encountered
> >that.
> bless([] => 'Foo');
> bless({} => 'Foo');
> bless(\*Foo => 'Foo');
> bless(\(my $var) => 'Foo');
Okay, now I did encounter it...
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's &bless is (seriously) broken
Juerd, On Jan 19, 2006, at 4:21 PM, Juerd wrote: Juerd skribis 2006-01-19 22:18 (+0100): Could you live with @foo being an array, and @foo in scalar context returning a reference to that array? And with arrays being interfaces to underlying Arrays, which are objects, which makes arrays non-objects that can be used *as* objects? This turns "everything is an object" into "everything can be used with OO syntax", which I think is more true Alternatively and simultaneously, "everything represents an object". Well, if "everything is NOT an object", then the synopsis need to reflect this. I was under the impression that everything was an object, some of that "object-ness" is more hidden in some than others, but it does not mean they are not still objects. My point though was not to debate OO theory, but to reconcile a problem in the Synopsis and it's description/usage of &bless. Currently it is broken, and we need to fix it. One fix, yes, is to say "arrays and hashes are not objects, they are literals as in perl 5". Personally I am not sure that is a good approach, and seems to contradict more of the Synopsis then it agrees with. Stevan
Re: Perl 6's &bless is (seriously) broken
Juerd,
On Jan 19, 2006, at 4:10 PM, Juerd wrote:
Stevan Little skribis 2006-01-19 15:45 (-0500):
class Foo {
method new ($class: %params) {
$class.bless(%params);
Wouldn't that be %params.bless($class), or more directly,
%params.blessed = $class?
Nope, according to S12:
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.
It then does on to give this code example:
$object = $class.bless({k1 => $v1, k2 => $v2, ...});
In fact all example using &bless us it as a method of the $class.
This *won't* work the same in Perl 6 though. This is because,
what is blessed is not a literal "hash", but an instance of ^Hash.
The mistake here is that Foo doesn't "does Hash", I think.
But we cannot automagically inject a role into a class, for a number
of reasons.
1) thats just plain evil
2) what if the role conflicts with other roles being does-ed by Foo?
Debugging hell there.
3) What if Foo wants to have a .keys, .value, .exists, etc? Do they
shadow the Hash version? What if Foo.keys is implemented using
Hash.keys? Many issues abound here.
Sure, in Perl 5, you could have different kinds of references as
instances of the same class. But I don't recall ever having
encountered
that.
bless([] => 'Foo');
bless({} => 'Foo');
bless(\*Foo => 'Foo');
bless(\(my $var) => 'Foo');
It silly, but you could do it. However this is not really related to
my point. The issue I am describing looks more like this in perl 5:
package Hash;
sub new { ... }
sub keys { ... }
sub values { ... }
sub exists { ... }
package Foo;
sub new {
my ($class, $hash) = @_;
($hash->isa(Hash)) || die "hash needs to be an instance of Hash";
bless($hash, $class);
}
Why would you ever want to do such a think in Perl 5? So why would
that be how &bless works in Perl 6?
Stevan
Re: Perl 6's &bless is (seriously) broken
On Jan 19, 2006, at 4:10 PM, Rob Kinyon wrote: Packages don't have anything to do with the class system. Actually ^Class.isa(^Package) ;) Stevan
perl6-language@perl.org
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's &bless is (seriously) broken
Juerd skribis 2006-01-19 22:18 (+0100): > Could you live with @foo being an array, and @foo in scalar context > returning a reference to that array? And with arrays being interfaces to > underlying Arrays, which are objects, which makes arrays non-objects > that can be used *as* objects? This turns "everything is an object" into "everything can be used with OO syntax", which I think is more true. Alternatively and simultaneously, "everything represents an object". 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's &bless is (seriously) broken
Rob Kinyon skribis 2006-01-19 16:10 (-0500): > There are no references in Perl6. When you said that one can't use OO in Perl 5, I had something to say because it's a recurring subject. I have to admit, though, that I've never seen this statement, or anything implying it. It's entirely new to me. Is your Perl the same as that of other people on this list? :) > In fact, the only think you have in Perl6 is objects, so why do we > need to take something that isn't an object (which doesn't exist) Could you live with @foo being an array, and @foo in scalar context returning a reference to that array? And with arrays being interfaces to underlying Arrays, which are objects, which makes arrays non-objects that can be used *as* objects? Perl still has non-object types. They may represent objects internally, but they work differently from what we've historically been calling objects. Especially in assignment, the differences are huge, because an object is considered a reference, while "real" scalars, arrays and hashes evaluate to (a list of) their values, or a useful representation (like the number of elements) when used in non-OO fashion. > &bless was a brilliant idea for Perl5. It's wrong for Perl6. I think it's needed to be able to convert Perl 5 code semi-automatically. But you have probably thought about this more than I, so I'll ask you: what's the alternative? 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's &bless is (seriously) broken
On Thursday 19 January 2006 13:10, Rob Kinyon wrote: > &bless was a brilliant idea for Perl5. It's wrong for Perl6. Perhaps you meant to write "Tagging a reference with a package name worked for Perl 5. It's wrong for Perl 6." Certainly I can agree with that. Yet this whole discussion feels like the argument that there should be no system() operator in Perl 6 because the system() operator in Perl 5 returns the wrong value. -- c
Re: Perl 6's &bless is (seriously) broken
To further extend Steve's argument (which I wholeheartedly agree with), I wanted to point out one thing: &bless has nothing to do with OO programming as conceived of in Perl6. It does one thing and only one thing: - tag a reference with a package name. This is used in a few places: - to determine what package the 'meth' function lives in when the syntax $foo->meth( @parms ) is encountered - to determine what ref() should return There are no references in Perl6. In fact, the only think you have in Perl6 is objects, so why do we need to take something that isn't an object (which doesn't exist) and do anything to it, let alone tag it with a package name? Packages don't have anything to do with the class system. If you want to change the behavior of something at runtime, you can do so through .meta, roles, mixins, traits, and the like. &bless was a brilliant idea for Perl5. It's wrong for Perl6. Rob
Re: Perl 6's &bless is (seriously) broken
Stevan Little skribis 2006-01-19 15:45 (-0500):
> class Foo {
> method new ($class: %params) {
> $class.bless(%params);
Wouldn't that be %params.bless($class), or more directly,
%params.blessed = $class?
> This *won't* work the same in Perl 6 though. This is because,
> what is blessed is not a literal "hash", but an instance of ^Hash.
The mistake here is that Foo doesn't "does Hash", I think.
Sure, in Perl 5, you could have different kinds of references as
instances of the same class. But I don't recall ever having encountered
that.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Perl 6's &bless is (seriously) broken
Hello,
I am forking this off the "Perl 6 OO and bless" thread since that
seems to have gotten bogged down in what it all means to Perl 5
interoperability. This was not really my intent with the original
thread, but I think it is still a fruitful discussion so I will re-
make my original point here with more detail.
First I need to establish a few things on which my argument rests.
So, S02 says that Perl 6 is an OO engine. Which means that a hash is
not a literal "thing" but an instance of the class ^Hash. This means
that a hash now has methods which can be called on it, and inherits
from ^Object.
Because @Larry does not want the OO-ness of the language to get in
the way of doing ones job, all the methods of ^Hash are either
transformed into pseudo-built-in-functions using macros (see the Hash/
delete/UnaryForm part of S29), or would be aliased as multi-subs
which dispatch using MMD.
Take this (very simplified) pseduo-code for &exists:
method Hash::exists (^Hash %h: Any $label) return Bool {
%h{$label} ?? bool::true !! bool::false
}
And lets assume that a macro has been written to make it callable in
the built-in function style which will transform this:
exists %h{'foo'}
Into this:
%h.exists('foo');
Now, what happens when we bless a hash.
class Foo {
method new ($class: %params) {
$class.bless(%params);
}
method bar ($self:) { ... }
}
The result of Foo.new is an instance of ^Foo. In Perl 5, the hash
would be tagged with the package name it was blessed into, but it
would still be a hash reference, only now you could also call methods
on it. This *won't* work the same in Perl 6 though. This is because,
what is blessed is not a literal "hash", but an instance of ^Hash. If
we follow the Perl 5 logic, then we can now call methods on this
blessed hash, but we cannot use the hash built-in functions since
they are just macro transformations into method calls. Take this code
example:
my $foo = Foo.new({ one => 1, two => 2 });
exists $foo{'one'}; # this will not work
The reason this the above code will not work is because "exists $foo
{'one'}" will be transformed by the macro to "$foo.exists('one')",
which will fail since no &Foo::exists exists. Even if we tried to do
this (and assuming the macro would DWIM):
Hash::exists $foo{'one'};
This would fail anyway since Hash::exists is expecting a ^Hash
instance as it's invocant arg, and not a ^Foo instance, so it would
fail on the parameter/argument type check.
I think this is a deep problem with how &bless works, how the
container types work, and maybe even how our MMD system works. I
think we need to have a well reasoned solution to this which is
devoid of any magic hand waving.
Thanks,
Stevan
Re: Class methods vs. Instance methods
On Thursday 19 January 2006 06:48, Rob Kinyon wrote: > "Any practical programming language with structural subtyping will > probably let you create and use aliases for type names (so you don't > have to write the full form everywhere). However, the underlying type > system will only consider the structure of the type when doing its > job." > > What's wrong with Perl doing things that way? duck-typing with names > ... sounds like a plan to me ... Accidental structural equivalence is a problem -- it's one of the things wrong with C's so-called type system, for example. I like to think of roles as nominally-tagged (and checked) structural subtyping. When you're *defining* a type, its structure matters. When you're *using* it, its behavior matters. It would be nice to keep those two separate. -- c
perl6-language@perl.org
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 i
Re: Class methods vs. Instance methods
Rob Kinyon wrote:
> "Any practical programming language with structural subtyping will
> probably let you create and use aliases for type names (so you don't
> have to write the full form everywhere). However, the underlying type
> system will only consider the structure of the type when doing its
> job."
>
> What's wrong with Perl doing things that way? duck-typing with names
> ... sounds like a plan to me ...
The thing is that people using .does(Name) and .isa(Name) is probably
expecting a nominal answer, not a structural one.
Although I do think Visual Basic's explicit duck-subtypes makes a lot of
sense:
my subset Duck where {
has $.half_life;
can doom:();
can quake:(--> Wolfenstein);
};
then you can apply it as a ducktype with names:
my Duck $donald = some_function();
$donald.quake; # assured to return a Wolfenstein object
It's already part of S12, by the way.
Audrey
signature.asc
Description: OpenPGP digital signature
perl6-language@perl.org
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: Class methods vs. Instance methods
On 1/18/06, Audrey Tang (autrijus) <[EMAIL PROTECTED]> wrote: > http://cakoose.com/wiki/type_system_terminology#13 "Any practical programming language with structural subtyping will probably let you create and use aliases for type names (so you don't have to write the full form everywhere). However, the underlying type system will only consider the structure of the type when doing its job." What's wrong with Perl doing things that way? duck-typing with names ... sounds like a plan to me ... Rob
Re: Class methods vs. Instance methods
On 1/19/06, Matt Fowles <[EMAIL PROTECTED]> wrote: > Could you provide a concrete example of the advantage of this approach > please? Failing that can you try and expand on your gut feeling a > bit? May or may not be of use, but Larry's view sounds a bit like reconcilling the (again considered irreconcilable) gap between nominal and structural subtyping: http://cakoose.com/wiki/type_system_terminology#13 Where the "empty" class object is the degenerate case of the smallest possible structural type, so it can be fulfilled by anything more structurally rich as long as they share the same nominal constraint. Audrey
perl6-language@perl.org
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
perl6-language@perl.org
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
