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/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
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
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
31 matches
Mail list logo