RE: stringification of objects, subroutine refs
[EMAIL PROTECTED]:
# I was wondering how perl6 would stringify (as in Data::Dumper):
As Dan said, that's serialization. I don't know if Perl will support
that built-in. But if it does...
# 1) objects with 'my' and 'our' variables
Those would have to be dumped from the pads or stashes. I don't think
there's any way around that.
# 2) $.property
Using their accessors?
# 2) subroutines (and coderefs)
See my comment below.
# 3) properties (both is/has)
'is' properties are part of the code, so I don't think they need
serialization. 'has' (or whatever it'll be called) properties can be
applied easily--remember, a 'has' returns its left operand.
# Right now, the fact that subroutines come out as 'sub {
# "DUMMY" }' is a minor pain to work around, having all of
# these as holes would be too much IMO.
That's fixed in 5.8--it uses B::Deparse to make a rough version of the
sub. Just hope it isn't a closure.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
"Attribute" vs. "Property"
I just want to verify that I properly understand the use of these two terms in Perl 6. * An "attribute" is a data member of a class. * A "property" is a piece of metadata on a...uh...thing -- e.g., on an attribute, on a class, or on a method. Do I have it right? For some reason, I've always referred to class data members as "properties", and thought of metadata on such things as "attributes" -- the reverse of the above. This despite the use of "attribute" in the above usage in Damian's book. So do I just need to turn myself around (at least when talking about Perl), or is there a chance that the language designers would decide that the way I use the terms is ever-so-much-better? ;-) Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Selective exporting of properties/methods
While thinking Eiffel-ish thoughts the other day, I began to wonder if
Perl6's classes could go beyond the simple private/public/protected
scheme by optionally allowing for a property or method to only be
accessed by a certain set of classes. For instance(as I understand
Perl6 syntax):
class Foo {
method hello is public {
return "hello";
}
method world is public_to(Bar) {
# is only public to objects of class Bar
return "world";
}
}
class Bar {
method say_hello {
# this works fine
print Foo.new.hello, "\n";
}
method say_world {
# as does this
print Foo.new.world, "\n";
}
}
class Baz {
method say_world {
# generates a run-time exception for trying to call a private method.
print Foo.new.world, "\n";
}
}
Re: Accessor methods ?
On Fri, May 10, 2002 at 11:27:53PM -0400, Chris Dutton wrote:
>
> On Friday, May 10, 2002, at 09:54 PM, Damian Conway wrote:
>
> >That's getting a little ugly, so maybe we'd "lift" the syntax from
> >Eiffel instead:
> >
> > method set_baz($newbaz is like($.baz)) { $.baz = $newbaz }
>
> This is exactly what went through my mind about a half second after I
> posted the message.
>
> $newbaz is like($.baz), I would think, would have to raise a run-time
> exception if $newbaz isn't "like" $.baz.
I've always found the word "like" to be very wishy-washy in a computer
langauge. In what way is newbaz like baz? And just how alike are they?
There must be a better way to describe this.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Accessor methods ?
Paul Johnson wrote:
> I've always found the word "like" to be very wishy-washy in a computer
> langauge. In what way is newbaz like baz? And just how alike are they?
> There must be a better way to describe this.
Perhaps:
method set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz }
method set_baz($newbaz is typeof($.baz)) { $.baz = $newbaz }
Damian
Re: "Attribute" vs. "Property"
David Wheeler wrote: > I just want to verify that I properly understand the use of these two terms > in Perl 6. and in the wider OO community, BTW. > * An "attribute" is a data member of a class. Yes. > * A "property" is a piece of metadata on a...uh...thing -- e.g., on an > attribute, on a class, or on a method. or on a subroutine, closure, or value. > Do I have it right? Yes. > So do I just need to turn myself around (at least when talking about > Perl), or is there a chance that the language designers would decide that > the way I use the terms is ever-so-much-better? ;-) Well, I suppose there's always a *chance* that we'd both completely reverse our careful thinking on this issue and ignore the common usage of "attribute" in the OO literature. But I do think it would be easier all round if you just went with our chosen terminology for Perl 6. ;-) Damian
Re: "Attribute" vs. "Property"
On 5/11/02 2:48 PM, "Damian Conway" <[EMAIL PROTECTED]> claimed: > Well, I suppose there's always a *chance* that we'd both completely reverse > our careful thinking on this issue and ignore the common usage of "attribute" > in the OO literature. But I do think it would be easier all round if you just > went with our chosen terminology for Perl 6. ;-) Damn. I was afraid you were going to say that! :-) Thanks for the reply. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Accessor methods ?
On 5/11/02 2:43 PM, "Damian Conway" <[EMAIL PROTECTED]> claimed:
> method set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz }
> method set_baz($newbaz is typeof($.baz)) { $.baz = $newbaz }
I like the latter best -- and it beats the hell out of "instanceof" ;-)
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: Accessor methods ?
David Wheeler <[EMAIL PROTECTED]> writes:
> On 5/11/02 2:43 PM, "Damian Conway" <[EMAIL PROTECTED]> claimed:
>
> > method set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz }
> > method set_baz($newbaz is typeof($.baz)) { $.baz = $newbaz }
>
> I like the latter best -- and it beats the hell out of "instanceof" ;-)
talking about instanceof, here are the various syntaxes:
* testing class membership
x isax Perl x
x is_a? kind_of? x Ruby x
x dynamic_cast x C++ x
x instanceof x Java x
x isinstance x Python x
x in x Ada x
x is x C# x
x is_a x PHP x
x entry_type x Pliant x
x ISTYPE x Modula-3 x
x object## < classname## x Beta x
x var ?= val (20)x Eiffel x
* get the class corresponding to an object/instance
x type x Ruby x
x __class__ x Python x
x getClass x Java x
x typeidx C++x
if you know some more, tell me :)
http://merd.net/pixel/language-study/syntax-across-languages.html
Re: Accessor methods ?
Damian Conway <[EMAIL PROTECTED]> writes:
> Paul Johnson wrote:
>
> > I've always found the word "like" to be very wishy-washy in a computer
> > langauge. In what way is newbaz like baz? And just how alike are they?
> > There must be a better way to describe this.
>
> Perhaps:
>
> method set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz }
> method set_baz($newbaz is typeof($.baz)) { $.baz = $newbaz }
FYI Ruby has:
a.type <= b.type or a.type == b.type
where the various operators (<, >, ==, != ...) are overloaded
according to the subtyping relation.
as for me,
- i find the "==" very readable,
- but i'm not sure "<=" is very readable
(who knows that a supertype is "greater", and a subtype is "smaller")
i prefer a.is_a?(b.type)
<=> is also defined but it seems broken since it returns 1 when there
is not subtyping relationship between 2 types.
Re: stringification of objects, subroutine refs
"Brent Dax" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED]:
> # I was wondering how perl6 would stringify (as in Data::Dumper):
>
> As Dan said, that's serialization. I don't know if Perl will support
> that built-in. But if it does...
>
> # 1) objects with 'my' and 'our' variables
>
> Those would have to be dumped from the pads or stashes. I don't think
> there's any way around that.
The semantics of this are unclear. Say I have (sorry if the syntax is
wrong)
{
my $t;
my ($x,$y) = (-> { ++$t }, -> { $t-- });
}
(The intent is I can use C<$x.()> and C<$y.()> to count backwards and
forwards).
Now, if I say C (assume suitable encoding,
delimiting, etc.; I'm not asking about those), I'd expect to get a
copy of C<$x> and C<$y>, and they should share the same C<$t>. Right?
What does the list C<($x.serialize(), $y.serialize)> give me? Given
that there's no way to know that both serializations will end up going
to the same file, they have to give me the equivalent of
{
my $t;
my $x = -> { ++$t };
}
{
my $t;
my $y = -> { $t-- };
}
So we've broken the meaning of the code (and serialization can't just
be a UNIVERSAL method, we have to be able to call it as a function on
a list). Is this a Good Thing? (Can we Do Better???)
OK, so now say I'm reading the original (C). And I
do it twice. Following the previous logic, I get 2 copies of C<$t>,
one for each reading. This might make sense, or it might not.
How do I read "half" of C? (That is, can I get just
C<$x>?) The easy answer is to say I can't. This creates an
uncomfortable situation. Every time I want to serialize a bunch of
closures, I have to serialize all of them in one go. And I have to
deserialize them all if I want to access any bit of them. What do I
do if I have 10_000 copies of some huge bunch, and I want to access
just one bit of it? Seems like I have to deserialize everything --
even though I we could be doing a lot better!
I guess I just don't understand how serializing closures is supposed
to work.
[...]
--
Ariel Scolnicov|http://3w.compugen.co.il/~ariels
Compugen Ltd. |[EMAIL PROTECTED]"Sometimes people write an
72 Pinhas Rosen St.|Tel: +972-3-7658117 accidental haiku. Damn!
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 It just happened!"
