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, b
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
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/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
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
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
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
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
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
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
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
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
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.
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 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
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
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:
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
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
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
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
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 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 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 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, 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 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 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:
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 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
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
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
34 matches
Mail list logo
