At 5:18 PM -0500 2/13/04, Simon Glover wrote:
Here's a patch to fix various typos etc. that I noticed on going over
the spec.
D'oh! Applied, thanks.
--
Dan
--it's like this---
Dan Sugalski
At 5:35 PM -0500 2/13/04, Simon Glover wrote:
A few questions:
1) How is the search order for the parents of a particular class
specified? In particular, is this determined at the Parrot level
or at the language level? Can it change at runtime?
It's determined by the method
At 10:31 AM +0100 2/14/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
While I'm still working on the vtable and supporting code section,
most of the revamp of PDD15 (objects!) is checked into the
repository. It'd be worth checking it out and checking it out, as
this would be
Dan Sugalski [EMAIL PROTECTED] wrote:
While I'm still working on the vtable and supporting code section,
most of the revamp of PDD15 (objects!) is checked into the
repository. It'd be worth checking it out and checking it out, as
this would be the time to get comments in.
1) Why is the
While I'm still working on the vtable and supporting code section,
most of the revamp of PDD15 (objects!) is checked into the repository.
It'd be worth checking it out and checking it out, as this would be
the time to get comments in.
great to see this, i guess everyone will agree. well, i have
While I'm still working on the vtable and supporting code section,
most of the revamp of PDD15 (objects!) is checked into the
repository. It'd be worth checking it out and checking it out, as
this would be the time to get comments in.
--
Dan
Here's a patch to fix various typos etc. that I noticed on going over
the spec.
Simon
--- pdd15_objects.pod.old Fri Feb 13 17:06:46 2004
+++ pdd15_objects.pod Fri Feb 13 17:10:08 2004
@@ -174,7 +174,7 @@
=item *
-remove interfaces
+Remove interfaces
=back
@@ -209,13 +209,13 @@
A few questions:
1) How is the search order for the parents of a particular class
specified? In particular, is this determined at the Parrot level
or at the language level? Can it change at runtime?
2) Re. the classoffset op: how does this work when multiple parent
classes
On Sun, Mar 09, 2003 at 03:46:39PM -0500, Dan Sugalski wrote:
Presenting internal state in a rational form is a rather
significantly different thing than being able to serialize things,
and I don't think it's feasable, unfortunately. It'll require too
much consistency to be useful (as I
At 7:29 AM +1300 3/8/03, Sam Vilain wrote:
On Sat, 08 Mar 2003 06:58, Dan Sugalski wrote:
At 2:08 PM +1300 3/7/03, Sam Vilain wrote:
As long as mechanisms are put in place to allow modules to bypass
object encapsulation and private/public constraints, and given that
Parrot will have no XS,
Sam Vilain wrote:
Associations *are* fundamental object things. Presenting them in terms of
attributes is the real hack.
Associations *are* fundamental things, but I don't think they are part
of an object.
They describe relationships between objects and should exist independantly
and
--- Andy Wardley [EMAIL PROTECTED] wrote:
Associations *are* fundamental things, but I don't think they are
part of an object. They describe relationships between objects and
should exist independantly and orthogonal to them.
Agreed. Is there any reason that shouldb't be done with something
At 2:08 PM +1300 3/7/03, Sam Vilain wrote:
As long as mechanisms are put in place to allow modules to bypass object
encapsulation and private/public constraints, and given that Parrot will
have no XS,
It wouldn't be wise to jump from Parrot won't do perl 5's XS scheme
to Parrot won't have a way
On Sat, 08 Mar 2003 06:58, Dan Sugalski wrote:
At 2:08 PM +1300 3/7/03, Sam Vilain wrote:
As long as mechanisms are put in place to allow modules to bypass
object encapsulation and private/public constraints, and given that
Parrot will have no XS,
It wouldn't be wise to jump from Parrot
Sam Vilain wrote:
No. All I'm saying is that this sort of construct:
*{$_} = \{Class::$_} foreach (qw(method method2 method3));
Like mixins? Perhaps something like this:
class My::Class;
mixin My::Random::Number::Generator qw( rand );
mixin My::Serialisation::Marshall qw( freeze
[EMAIL PROTECTED] (Andy Wardley) writes:
Like mixins? Perhaps something like this:
class My::Class;
mixin My::Random::Number::Generator qw( rand );
mixin My::Serialisation::Marshall qw( freeze thaw );
Yey! With this, the Perl6-o-meter now stands at:
PERL 5
On Thu, 06 Mar 2003 06:01, Dan Sugalski wrote:
*) We're not talking perl 5 style objects, rather objects as
fundamental things with attributes. Associations, from what I can see
from your description, don't really apply.
I was talking about objects as fundamentals, too. I was just using Perl
Sam Vilain wrote:
On Thu, 06 Mar 2003 05:10, Garrett Goebel wrote:
Several people have mentioned a desire to see Perl6
and Parrot facilitate object persistence. Should
such issues be tackled in Parrot?
Not necessarily. Just be friendly to object persistence
frameworks by exporting
Sam Vilain wrote:
Associations *are* fundamental object things. Presenting them in terms of
attributes is the real hack.
I agree with this statement; and Brent previously asked what
associations *are*. The problem with describing them in terms of
attributes/properties not not so much that its
On Thu, Mar 06, 2003 at 10:16:40AM +, Simon Cozens wrote:
: Like mixins? Perhaps something like this:
:
:class My::Class;
:mixin My::Random::Number::Generator qw( rand );
:mixin My::Serialisation::Marshall qw( freeze thaw );
:
: Yey! With this, the Perl6-o-meter now stands at:
On Fri, 07 Mar 2003 05:48, Garrett Goebel wrote:
Over on perl6-internals you've been talking about the need for
Associations. Is the addition of associations all that's missing from
Parrot to support exporting object relationships in a sensible and
consistent manner?
A prudent question. I
On Thu, 06 Mar 2003 05:51, Austin Hastings wrote:
You'd like to declare the relationship between them, but this can be
really difficult (consider e.g., nethack, in which the things you can
own are constrained by weight/volume/knapsack).
So certainly you need to be able to add code to the
At 10:48 AM -0600 3/6/03, Garrett Goebel wrote:
Sam Vilain wrote:
On Thu, 06 Mar 2003 05:10, Garrett Goebel wrote:
Several people have mentioned a desire to see Perl6
and Parrot facilitate object persistence. Should
such issues be tackled in Parrot?
Not necessarily. Just be friendly to
At 3:28 AM +1300 3/6/03, Sam Vilain wrote:
On Wed, 05 Mar 2003 13:31, Brent Dax wrote:
# *) A superclass (obviously, but I consider it to be the
# same level as
# Properties, Methods and Attributes.)
Superclass*es*. Perl 5 has MI, and I don't expect that to change in
Perl 6. Parrot
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 5:02 AM +1300 3/6/03, Sam Vilain wrote:
*{$_} = \{Class::$_} foreach (qw(method method2 method3));
Gives you everything that inheriting a class does, apart from the
-isa() relationship. And potential unwanted namespace pollution.
It's
On Wed, 05 Mar 2003 13:31, Brent Dax wrote:
# *) A superclass (obviously, but I consider it to be the
# same level as
# Properties, Methods and Attributes.)
Superclass*es*. Perl 5 has MI, and I don't expect that to change in
Perl 6. Parrot absolutely *must* support Perl, or it has
--- Sam Vilain [EMAIL PROTECTED] wrote:
What I'm saying is that it should be possible to `filter' which
methods you inherit via @ISA. Ideally there would be some standard
way for a module to describe groups of methods for other classes to
import a la Exporter's %EXPORT_TAGS.
The result
Are you speaking in terms of limitation, or requirement?
It would be nice to have a syntax solution. I've seen p5 interfaces
with stubs that die so that you have to override them in a subclass. It
works, but seems a little kludgy.
Back in 1988 programming Objective-C under NeXTSTEP you could
On Thu, 06 Mar 2003 04:19, Paul wrote:
Are you speaking in terms of limitation, or requirement?
It would be nice to have a syntax solution. I've seen p5 interfaces
with stubs that die so that you have to override them in a subclass. It
works, but seems a little kludgy.
And I'm coming in late
Several people have mentioned a desire to see Perl6 and Parrot facilitate
object persistence. Should such issues be tackled in Parrot? Will there ever
be a Parrot Object Database that we can serialize our Perl, Python and Ruby
objects into, to be used at some later date in code written in Jako?
--- [EMAIL PROTECTED] wrote:
Are you speaking in terms of limitation, or requirement?
It would be nice to have a syntax solution. I've seen p5 interfaces
with stubs that die so that you have to override them in a
subclass. It works, but seems a little kludgy.
Back in 1988 programming
On Thu, 06 Mar 2003 04:19, Paul wrote:
Leave them out to carry on with the status quo of a myriad of subtly
different, non-interchangable approaches to associating classes.
TMTOWTDI?
Still, though your point is valid if I understand it, it will always be
possible to create
Garrett Goebel [EMAIL PROTECTED] writes:
Several people have mentioned a desire to see Perl6 and Parrot facilitate
object persistence. Should such issues be tackled in Parrot? Will there ever
be a Parrot Object Database that we can serialize our Perl, Python and Ruby
objects into, to be used
And I'm coming in late on this. Are you saying you want
Exporter/%EXPORT_TAGS functionality built into the language and
into all objects? Wouldn't that jack up the overhead?
No. All I'm saying is that this sort of construct:
*{$_} = \{Class::$_} foreach (qw(method method2
Vilain [EMAIL PROTECTED]
Sent by: Sam Vilain [EMAIL PROTECTED]
03/05/2003 11:11 AM
To: [EMAIL PROTECTED], Paul [EMAIL PROTECTED], [EMAIL PROTECTED]
cc:
Subject:Associations between classes [was: Re: Object spec]
On Thu, 06 Mar 2003 04:19, Paul wrote:
Leave them
--- Sam Vilain [EMAIL PROTECTED] wrote:
Consider this excerpt from the test script:
my $joe = new Person(name = Joe Average);
my $car = new Object(description = Red Car);
$car-set_owner($joe);
ok($joe-posessions-includes($car), Joe owns car);
How much of Association is just tricky,
At 5:02 AM +1300 3/6/03, Sam Vilain wrote:
No. All I'm saying is that this sort of construct:
*{$_} = \{Class::$_} foreach (qw(method method2 method3));
Gives you everything that inheriting a class does, apart from the -isa()
relationship. And potential unwanted namespace pollution.
It's
Sam Vilain:
# We musn't dictate style.
#
# No, but we should emanate good style. And I consider opening
# two class'
# namespaces into the same stash to be very bad style.
We *must* support MI, delegation and interfaces in Parrot. Interfaces
can probably be implemented in terms of MI and/or
On Thu, 06 Mar 2003 15:31, Brent Dax wrote:
Sam Vilain:
# We musn't dictate style.
#
# No, but we should emanate good style. And I consider opening
# two class'
# namespaces into the same stash to be very bad style.
We *must* support MI, delegation and interfaces in Parrot. Interfaces
Sam Vilain:
# Alternatively, the approach taken with MI namespace clashes
# in Perl 5
# is to let the programmer arrange the inheritance tree as he
# sees fit,
#
# You are right - but this is a different condition. There is
# no error in
# this case because there is no ambiguity as to
On Thu, 06 Mar 2003 05:10, Garrett Goebel wrote:
Several people have mentioned a desire to see Perl6 and Parrot
facilitate object persistence. Should such issues be tackled in Parrot?
Not necessarily. Just be friendly to object persistence frameworks by
exporting object relationships in a
On Thu, 06 Mar 2003 05:40, [EMAIL PROTECTED] wrote:
Seems like you are thinking along the lines of making Parrot support
Prevayler-style
http://www-106.ibm.com/developerworks/web/library/wa-objprev/index.html
stuff naturally and with less coding at the top layer. Is that where you
are headed
On Thu, 06 Mar 2003 16:22, Brent Dax wrote:
Who said it would be silent? I mentioned emitting a warning below. The
module writer will fix the warning, and module users can disable the
warning easily until the new version is out.
# It sounds like you already have a plan - I didn't realise
#
[This came from perl6-internals, and should go back there. Redirect
followups appropriately, please]
At 11:58 PM +1300 3/4/03, Sam Vilain wrote:
Dan,
Sorry if I'm flogging a dead horse, but I just caught this call via the
summarizer.
Okay, here's another shot at the semantics for objects [for
At 10:10 AM -0600 3/5/03, Garrett Goebel wrote:
Several people have mentioned a desire to see Perl6 and Parrot facilitate
object persistence. Should such issues be tackled in Parrot?
To some extent, yes. (And as such this is CC'd to both p6l and p6i,
but discussion really belongs in p6i)
There's
Dan,
Sorry if I'm flogging a dead horse, but I just caught this call via the
summarizer.
Okay, here's another shot at the semantics for objects [for perl 6]. If
folks,
especially non-perl folks, would look this over and chime in, I'd
much appreciate it.
Objects have (all optional):
*)
And attributes are essentially member variables of objects, which you
can access as $obj.foo. Another possible description of
them might be
lvalue methods which never take arguments, and which fetch and store
class-specific pieces of data. Different classes may define their own
private
Allen Short [EMAIL PROTECTED] writes:
Peter == Peter Seibel [EMAIL PROTECTED] writes:
Hi, I'm new to this list and haven't had a chance to grovel
through the old archives yet so please forgive me for jumping in
in the middle of things.
Anyway, what about languages
Sam Vilain:
# Okay, here's another shot at the semantics for objects [for
# perl 6].
# If folks, especially non-perl folks, would look this over and chime
# in, I'd much appreciate it.
# Objects have (all optional):
# *) Properties
# *) Methods
# *) Attributes
#
# Add to that:
# *) A
Peter == Peter Seibel [EMAIL PROTECTED] writes:
Hi, I'm new to this list and haven't had a chance to grovel
through the old archives yet so please forgive me for jumping in
in the middle of things.
Anyway, what about languages that don't attach methods to
particular
Brent Dax [EMAIL PROTECTED] writes:
Dan Sugalski:
# Okay, here's another shot at the semantics for objects. If folks,
# especially non-perl folks, would look this over and chime in, I'd
# much appreciate it.
...
# Attributes are local to a class in an object's inheritance hierarchy.
#
On Mon, 2003-03-03 at 16:52, Garrett Goebel wrote:
From: Erik Bågfors [mailto:[EMAIL PROTECTED]
On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote:
Okay, here's another shot at the semantics for objects. If folks,
especially non-perl folks, would look this over and chime in, I'd
much
Brent Dax wrote:
Dan Sugalski:
# Okay, here's another shot at the semantics for objects. If folks,
# especially non-perl folks, would look this over and chime in, I'd
# much appreciate it.
[snip]
I honestly don't care much about such languages, but how is Parrot
going to support classless
Erik Bågfors wrote:
On Mon, 2003-03-03 at 16:52, Garrett Goebel wrote:
From: Erik Bågfors [mailto:[EMAIL PROTECTED]
On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote:
Objects have (all optional):
*) Properties
*) Methods
*) Attributes
Can you give a clear
At 5:54 PM -0800 3/2/03, Dave Whipp wrote:
Dan Sugalski wrote:
Okay, here's another shot at the semantics for objects. If folks,
especially non-perl folks, would look this over and chime in, I'd
much appreciate it.
The thing that I noticed was the lack of semantics for creation and
Hence the
At 9:49 AM +0100 3/3/03, Erik Bågfors wrote:
On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote:
Okay, here's another shot at the semantics for objects. If folks,
especially non-perl folks, would look this over and chime in, I'd
much appreciate it.
Objects have (all optional):
*) Properties
*)
At 6:29 PM -0800 3/2/03, Brent Dax wrote:
Dan Sugalski:
# Okay, here's another shot at the semantics for objects. If folks,
# especially non-perl folks, would look this over and chime in, I'd
# much appreciate it.
...
# Attributes are local to a class in an object's inheritance hierarchy.
# An
At 5:30 PM +0100 3/3/03, Erik Bågfors wrote:
On Mon, 2003-03-03 at 16:52, Garrett Goebel wrote:
From: Erik Bågfors [mailto:[EMAIL PROTECTED]
On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote:
Okay, here's another shot at the semantics for objects. If folks,
especially non-perl folks,
At 12:43 PM -0500 3/3/03, Benjamin Goldberg wrote:
AFAIK, though, properties are only attatched to values (not variables),
and are entirely run-time things.
Nope, they can go on both (or either), which makes things somewhat
more interesting.
--
Dan
Dan Sugalski wrote:
Okay, here's another shot at the semantics for objects. If folks,
especially non-perl folks, would look this over and chime in, I'd much
appreciate it.
The thing that I noticed was the lack of semantics for creation and
destruction. Will there be well defined creation
a clear example of what the difference is between
properties and attributes?
Also, how is the difference between a class variable and a object
variable?
Maybe I would have understod better if I read the last object spec
better :)
/Erik
--
[EMAIL PROTECTED]
fingerprint: A85B 95D3 D26B 296B
From: Erik Bågfors [mailto:[EMAIL PROTECTED]
On Sun, 2003-03-02 at 23:21, Dan Sugalski wrote:
Okay, here's another shot at the semantics for objects. If folks,
especially non-perl folks, would look this over and chime in, I'd
much appreciate it.
Objects have (all optional):
Benjamin Goldberg:
# Dan Sugalski wrote:
# [snip]
# All of these--method lookup, property lookup, attribute
# lookup--may be
# intercepted, and all may have a fallback method that's
# called if the
# 'proper' lookup fails.
#
# I think this about covers it. If there's missing semantics,
Dan Sugalski:
# Okay, here's another shot at the semantics for objects. If folks,
# especially non-perl folks, would look this over and chime in, I'd
# much appreciate it.
...
# Attributes are local to a class in an object's inheritance hierarchy.
# An object can have one foo attribute per
Okay, here's another shot at the semantics for objects. If folks,
especially non-perl folks, would look this over and chime in, I'd
much appreciate it.
Objects have (all optional):
*) Properties
*) Methods
*) Attributes
Properties are global to the object. An object can have only one
propery
Dan Sugalski wrote:
[snip]
All of these--method lookup, property lookup, attribute lookup--may
be intercepted, and all may have a fallback method that's called if
the 'proper' lookup fails.
I think this about covers it. If there's missing semantics, and I
expect I missed something, let's
66 matches
Mail list logo
