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 th
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 ref
On 1/18/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> "Bob Rogers (via RT)" <[EMAIL PROTECTED]> wrote:
> >
> > The attached code compiles to byte code OK in r11235, until you
> > comment out the push_eh indicated by the patch, which makes
> > compute_dominance_frontiers take forever. (So
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
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
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 t
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
Here's some further background:
On 14-Jan-06 I had done some hacking on my compiler using r11187, and
all worked fine when I did my last checkin that day. When I updated to
r11220 late on 16-Jan-06, doing the standard "make clean test" on my
code broke mysteriously in a number of places. I
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
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
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 r
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
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
failur
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 nee
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
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-o
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:
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
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, an
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 turn
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.
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 l
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 d
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
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 po
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 s
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
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
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, 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). Howeve
In message <[EMAIL PROTECTED]>,
"Jonathan Worthington via RT" writes:
: "Greg Bacon" <[EMAIL PROTECTED]> wrote:
:
: > I'm still seeing a link failure with r11221.
:
: Discovered I have cygwin on this PC, went to investigate and..the link failure is gone as well as the auto-import warnings.
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 ir
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, b
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
34 matches
Mail list logo
