Re: split on empty string
On Jan 18, 2006, at 1:18 AM, Jonathan Scott Duff wrote: On Tue, Jan 17, 2006 at 12:35:57PM -0500, Mark Reed wrote: On 2006-01-17 12:24 PM, Gaal Yahas [EMAIL PROTECTED] wrote: [split on empty string] doesn's seem to be specced yet. I would prefer the current pugs behavior; it's consistent with the general case, in which a string which does not match the splitting regex results in a single-item list containing the original string. This is the Python behavior. I find the Perl5 (and, surprisingly, Ruby) behavior rather counterintuitive. FWIW, I agree with Mark. -Scott Just to show opposite, I've always found that behavior (i.e. returning the original string unchanged) confusing. Csplit works based on sequential examination of the target string to locate matching substrings on which to split. There is a matching empty string substring between every character. Naturally, what you get back is an array of characters. Plus, it's a useful idiom. --Dks
Re: split on empty string
On 2006-01-18 10:04 AM, David K Storrs [EMAIL PROTECTED] wrote: Just to show opposite, I've always found that behavior (i.e. returning the original string unchanged) confusing. Csplit works based on sequential examination of the target string to locate matching substrings on which to split. There is a matching empty string substring between every character. Naturally, what you get back is an array of characters. Plus, it's a useful idiom. You misunderstand. We're not talking about splitting a string with the empty string as the delimiter. We're talking about splitting the empty string (as the target), with any delimiter whatsoever. If you do that, what you get back is an empty array. Perl6 .split(/whatever/) is equivalent to split(/whatever/,) in Perl5. It's not like the silly Python idiom where the invocant is the delimiter string. :) So this is the Perl5 to which I was referring: my @result = split(/whatever/, ); print [EMAIL PROTECTED],\n;# -- 0 The general case I was comparing it to is when the target string is *not* empty but doesn't match, in which case you get the original string back: my @result = split(/foo/, bar); print [EMAIL PROTECTED],\n;# -- 1 print $result[0],\n; # -- bar
Re: split on empty string
Mark Reed wrote: Perl6 .split(/whatever/) is equivalent to split(/whatever/,) in Perl5. I'm hoping that the perl 5 syntax will still be valid in perl 6. -- Jonathan Dataweaver Lang
Re: Indeterminate forms for the Num type.
At 09:38 +0800 1/18/06, Audrey Tang wrote: Also, would you be happy with different treatments of Int/Int versus Num/Num? 0/0 # fail illegal division by zero 0.0/0.0 # NaN I plead guilty. I was not aware that perl6 was going to allow types to be defined like int and float. While learning perl 5 I was frustrated by that lack at first but I came to like it after a while because the treatment of strings that happen to be numbers is well done. $serial = 48; behaves like a numeric 48 if I add to it but I don't have to perform an sprintf to get the zeros back if my goal is to repeat the value read from some HTML page or cookie. As a Gegenbeispeil try entering that or even a date in M$Excel. It will be immediately converted to a floating point seconds after the epoch and there is no way to recover the input text. I hate it. So. . . If perl6 will allow me to define a variable as type int64, int32, or things like that then division by zero should be an exception as should overflow on addition. If the perl way is the goal then users who don't want to go to C should be treated to $numerics that allows for strings, scientific notation, and the like while doing the right thing. For that, converting 0/0 to a floating point division with a NaN result is quite proper. The important thing is that ($aa + $bb)/$aa should return 1.0 when $bb is a NaN underflow or if $aa is a NaN Inf. Those may not be the best examples but you get the idea. Some intermediate results can return NaN's in a way that inclusion in a later calculation can produce a correct result in spite of the NaN. Numeric values often come from an external source. Unnecessary and confusing validation of that kind of input should not be required just to keep a program running. Just let the final answer show as a NaN and keep the programming clear and short. -- -- There are 10 kinds of people: those who understand binary, and those who don't --
Re: Indeterminate forms for the Num type.
On Wed, Jan 18, 2006 at 09:38:04AM +0800, Audrey Tang wrote: : Also, would you be happy with different treatments of Int/Int versus : Num/Num? : : 0/0 # fail illegal division by zero : 0.0/0.0 # NaN I'd like to point out that there's no reason in principle that a failure undef can't return NaN in numeric context, so we don't actually have to distinguish those two cases normally (though use fatal might distinguish them). By and large I agree with Darren. The boxed types should opt for consistency over efficiency while the unboxed types should opt for efficiency of consistency. So perhaps we just say that boxed NaN is indistinguishable from undef--in particular, unboxing one in numeric context gives you back the NaN. I don't know whether it makes sense to extend that to ±Inf though. Maybe it does. We're kinda fuzzing that idea anyway already. Undefined numbers vary in definedness much like undefined generic prototype objects, aka classes. All undefs are created unequal, but some are more unequal than others. Long term I think we'll end up asking these objects whether they're defined according to one of their roles. So the infinities know they have a defined sign, for instance, but not a defined magnitude (except insofar as infinity is considered a separate defined concept). And an object might be considered defined as a Mammal but undefined (so far) as a Dog or Cat. So instead of $num.defined or $animal.defined we might have $num.defined(Sign) or $animal.defined(Dog|Cat). If you omit the arg then .defined devolves to something like what we have now, where the definedness is decided by the class of the object. Note this is not quite the same as .does(Dog|Cat), since an undefined proto object returns true for that but false for .defined(Dog|Cat) unless one of those roles thinks the object is sufficiently initialized to be considered defined. For most roles that could implicitly determined by whether the BUILD for that role has run, assuming BUILD always produces a complete initialization. Maybe defined is the wrong word for it anymore. It's more like okay or normal or nominal or functional. I could go for $Fido.good(Dog). :-) Larry
Class methods vs. Instance methods
Today on #perl6, Audrey, Stevan and I were talking about $repr. A
tangent arose where Audrey said that the difference between class
methods and instance methods was simply whether or not the body
contained an attribute access.
Is this true? If it is, then I think it violates polymorphism as
demonstrated by the following:
class Dog {
method tail { brown and short }
};
class Chihuahua is Dog {
has $.color;
method tail { $.color _ and short }
};
You can say Dog.tail, Dog.new.tail, Chihuahua.new.tail, but not
Chihuahua.tail. That's extremely counter-intuitive.
I think that class methods should be explicitly defined as class
methods and you cannot call a class method upon an instance, just as
you cannot call an instance method upon a class. Plus, this should be
determinable (for the most part) at compile time, which is a bonus,
imho.
Thanks,
Rob
Re: split on empty string
On Tue, Jan 17, 2006 at 07:24:14PM +0200, Gaal Yahas wrote:
: While cleaning up tests for release:
:
: .split(':')=
:
:()# Perl 5
:(,) # pugs
:
: Which is correct? It doesn's seem to be specced yet.
This has nothing to do with splitting on the empty string, per se, but
with Perl 5 stripping trailing null fields by default:
@results = split(/:/,'');
print @results + 0; # prints '0'
I think we could make that behavior optional now with :trim or some
such. The original motivation has largely gone away with the advent
of autochomping filehandles, so split /\s+/ won't produce a spurious
null field after the \n.
Larry
Re: split on empty string
Jonathan Lang skribis 2006-01-18 7:26 (-0800): Mark Reed wrote: Perl6 .split(/whatever/) is equivalent to split(/whatever/,) in Perl5. I'm hoping that the perl 5 syntax will still be valid in perl 6. Don't worry, it is. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: split on empty string
On Wed, Jan 18, 2006 at 09:08:07PM +0100, Juerd wrote: : Jonathan Lang skribis 2006-01-18 7:26 (-0800): : Mark Reed wrote: : Perl6 .split(/whatever/) is equivalent to split(/whatever/,) in Perl5. : I'm hoping that the perl 5 syntax will still be valid in perl 6. : : Don't worry, it is. Yep, it's mostly just the semantics we're screwing around with. :-) Larry
Re: Class methods vs. Instance methods
On Wed, Jan 18, 2006 at 01:56:53PM -0500, Rob Kinyon wrote:
: Today on #perl6, Audrey, Stevan and I were talking about $repr. A
: tangent arose where Audrey said that the difference between class
: methods and instance methods was simply whether or not the body
: contained an attribute access.
:
: Is this true? If it is, then I think it violates polymorphism as
: demonstrated by the following:
:
: class Dog {
: method tail { brown and short }
: };
:
: class Chihuahua is Dog {
: has $.color;
: method tail { $.color _ and short }
: };
:
: You can say Dog.tail, Dog.new.tail, Chihuahua.new.tail, but not
: Chihuahua.tail. That's extremely counter-intuitive.
I don't think it's counterintuitive. You've defined Dog with an
invariant .tail but not Chihuahua. It's doing exactly what you asked
for under a prototype view of reality.
: I think that class methods should be explicitly defined as class
: methods and you cannot call a class method upon an instance, just as
: you cannot call an instance method upon a class. Plus, this should be
: determinable (for the most part) at compile time, which is a bonus,
: imho.
I believe this is already determinble at compile time for the most part.
But I have a strong gut-feeling that over the long term it's going to
be important to be able to view a given object as either a partially
instantiated class or a partially undefined object, and for that we have
to break down the false class/instance dichotomy. And to the extent
that the dichotomy *isn't* false, we're trying to sweep classness into
the .meta object, which is the *real* class object in Perl 6.
Larry
Um... this week's summary
Unless Matt takes pity on me, and writes a summary at disgustingly high speed, there won't be a summary this week. Assorted things got in the way on Monday or Tuesday, and I'm now at my consulting gig 'til the end of the week with no time for summarizing. I'm really, really sorry. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/
Re: Class methods vs. Instance methods
Larry~ On 1/18/06, Larry Wall [EMAIL PROTECTED] wrote: But I have a strong gut-feeling that over the long term it's going to be important to be able to view a given object as either a partially instantiated class or a partially undefined object, and for that we have to break down the false class/instance dichotomy. And to the extent that the dichotomy *isn't* false, we're trying to sweep classness into the .meta object, which is the *real* class object in Perl 6. Perhaps I am just being short sighted, but I never saw this as a false dichotomy. In fact, every time I hear about these partially instatiated I cringe in horror about the strange halfway lands we might end up in... Oh no, this method can only be called on an object that is 3/4 initialized, and you supplied one that is 2/3 initialized that causes undefined behavior. 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? Thanks, Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Perl 6 OO and bless
Hello All,
In reading over the Synopsis again in hopes of finding more
information regarding the different repr types (see the warnocked
post entitled Construction and Initialization of repr types other
than P6opaque), I stumbled onto some issues with the Perl 6 OO model
and bless.
In S02 it says:
Perl 6 is an OO engine, but you're not generally required to
think in OO
when that's inconvenient. However, some built-in concepts such
as filehandles
will be more object-oriented in a user-visible way than in Perl 5.
Now taking this statement one (logical) step further, and I assume
that this means things like arrays and hashes will (underneath) just
be objects. So we will have an ^Array class, and a ^Hash class, and
[] and {} will actually construct instances of ^Array and ^Hash
respectively. (Of course I am simplifying it here, these may be roles
instead of classes, but this is not relevant to the discussion really).
Then later on S12 says:
As in Perl 5, a constructor is any routine that calls bless.
Unlike in Perl 5,
you call it as a method on the class, passing the candidate as
the first
argument. To bless a hash as in Perl 5, say:
$object = $class.bless({k1 = $v1, k2 = $v2, ...});
Are we not just re-blessing an instance of the class ^Hash into
whatever $class is? That does not seem to be what is intended,
however, if {} is a constructor for an instance of ^Hash, and I can
call methods on {} like any other object ({}.keys, {}.exists($key),
etc.), then what happens when I bless {} with a class? Do I loose
access to the methods of ^Hash? Are the methods only allowed to be
called in the non-invocant syntax (called like functions and not
methods)?
Which brings me to my real question:
Do we really still need to retain the old Perl 5 version of bless?
What purpose does it serve that p6opaque does not do in a better/
faster/cleaner way?
Thanks,
Stevan
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: Class methods vs. Instance methods
On 1/18/06, Larry Wall [EMAIL PROTECTED] wrote:
On Wed, Jan 18, 2006 at 01:56:53PM -0500, Rob Kinyon wrote:
: Today on #perl6, Audrey, Stevan and I were talking about $repr. A
: tangent arose where Audrey said that the difference between class
: methods and instance methods was simply whether or not the body
: contained an attribute access.
:
: Is this true? If it is, then I think it violates polymorphism as
: demonstrated by the following:
:
: class Dog {
: method tail { brown and short }
: };
:
: class Chihuahua is Dog {
: has $.color;
: method tail { $.color _ and short }
: };
:
: You can say Dog.tail, Dog.new.tail, Chihuahua.new.tail, but not
: Chihuahua.tail. That's extremely counter-intuitive.
I don't think it's counterintuitive. You've defined Dog with an
invariant .tail but not Chihuahua. It's doing exactly what you asked
for under a prototype view of reality.
Except there are no such things as classes in a prototype view of
reality. Everything is an instance and there are no such things as
class methods. The entire idea that an object (::Dog) can call methods
that are for another object ($fido) is ... well ... it's a little off.
That's like saying any object can call any method from any other
object so long as that method is invariant.
: I think that class methods should be explicitly defined as class
: methods and you cannot call a class method upon an instance, just as
: you cannot call an instance method upon a class. Plus, this should be
: determinable (for the most part) at compile time, which is a bonus,
: imho.
I believe this is already determinble at compile time for the most part.
But I have a strong gut-feeling that over the long term it's going to
be important to be able to view a given object as either a partially
instantiated class or a partially undefined object, and for that we have
to break down the false class/instance dichotomy. And to the extent
that the dichotomy *isn't* false, we're trying to sweep classness into
the .meta object, which is the *real* class object in Perl 6.
I'm sure you understand the distinction you're making. I know I don't
and I've been trying to follow this discussion for the past year. I'm
may not be the brightest bulb in the chandelier, but I'm no 15W dimmer
switch, either.
Frankly, you should be using people like me, Matt Fowles, and the
other programmers on the list as sounding boards. If we're having
problems understanding the concept, then how are we going to explain
partially-instantiated classes on Perlmonks or #perl or clmp? Like
it or not, we're the sergeants in the Perl army. We're the guys
explaining all this stuff to the privates coming up the ranks. It may
be a nice extension to have, but I'm not sure this should be part of
the standard MOP.
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.
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
Do chained comparisons short-circuit?
Suppose I have code that looks like this: my ($x, $y, $z) = (1, 2, 3); say sorted backward if ++$x ++$y ++$z; Will $z be incremented even though the chained comparison is known to be false after ++$x and ++$y are compared? Joe Gottman
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: Do chained comparisons short-circuit?
On 1/19/06, Joe Gottman [EMAIL PROTECTED] wrote: Suppose I have code that looks like this: my ($x, $y, $z) = (1, 2, 3); say sorted backward if ++$x ++$y ++$z; Will $z be incremented even though the chained comparison is known to be false after ++$x and ++$y are compared? I don't see a reason for chained comparisons not to short-circuit, besides the surprise factor. But anyone who knows about , and understands chained comparisons as expanding to , should understand short-circuiting behavior. Luke
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
Re: Do chained comparisons short-circuit?
On Thursday 19 January 2006 04:25, Luke Palmer wrote: On 1/19/06, Joe Gottman [EMAIL PROTECTED] wrote: Suppose I have code that looks like this: my ($x, $y, $z) = (1, 2, 3); say sorted backward if ++$x ++$y ++$z; Will $z be incremented even though the chained comparison is known to be false after ++$x and ++$y are compared? I don't see a reason for chained comparisons not to short-circuit, besides the surprise factor. But anyone who knows about , and understands chained comparisons as expanding to , should understand short-circuiting behavior. Although that may lead to _longer_ code, which (when extended) is likely to be broken: $x++; $y++; $z++; say sorted backward if $x $y $z; To be honest, in this example it mostly doesn't matter; if $x $y, then ($x+1) ($y+1). But in many quickly written scripts I did some numeric operation to force the value to numeric, even if I got a parameter like string (which becomes 0 when numyfied) How about some flag saying don't short-circuit this? Regards, Phil
