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
At 5:29 AM +0100 2/15/04, LF 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.
great to see this, i gues
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 invocation
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
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
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 e
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 sp
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 @@
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,
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 "
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 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.
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
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 e
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 Per
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
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 ab
[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 pe
> 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
> pr
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,
> "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
>
"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 hierarc
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
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 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 obje
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
*)
Erik Bågfors wrote:
> Garrett Goebel wrote:
>> Erik Bågfors 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.
Objects have (all optional):
>>
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 next
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
> >
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 clas
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'
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 op
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 semanti
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
> *) Methods
> *) Attributes
Can
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 cla
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 semantic
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
38 matches
Mail list logo
