Object spec, try 2
Dan Sugalski
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 named "foo".
Attributes are local to a class in an object's inheritance hierarchy.
An object can have one "foo" attribute per class in its inheritance
tree.
Attributes are considered class-private, so a class will normally
only see its own attributes. There will be a mechanism to see all the
attributes for an object, though. Code outside a class won't see the
attributes--they aren't exposed.
Methods override properties, so if an object has a method "foo" and a
property "foo", then accessing object.foo will call the method.
(Methods may be lvalue)
Code can ask for an explicit method handle, basically "give me a PMC
for the method named "foo" on this object" which can be called later.
Changes to a class's "foo" method won't affect "foo" method handles
already returned.
Methods can be redispatched, as well as dispatched. Redispatching
continues on following the class hierarchy. Methods do not have to do
this, but they may.
Classes that inherit via delegation, for example a Python or Perl 6
class that inherits from a perl 5 class, store away the object that's
being delegated and tack a property on it that links to the parent
object. That way when a delegated method redispatches, or calls
another method on the delegate object, the original object is
available to dispatch properly.
Classes may be responsible for delegating to child classes, though
this can be left automatic.
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 get it out and add it. Once we've
got it pretty much nailed I'll spec out the interface and we can
start in on the implementation.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Benjamin Goldberg
[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 get it out and add it. Once we've
> got it pretty much nailed I'll spec out the interface and we can
> start in on the implementation.
For the sake of completeness, I would like to ask, what are the
semantics of multiple inheritance?
Do we *only* natively offer a way of doing perl6 method dispatch
(whatever that may be), and any other type of method dispatch else has
to be emulated using a subroutine written in bytecode?
Or, do we offer multiple ways to look methods up... one way for each
language that we're compiling? So that we could compile C++ to parrot,
or compile perl(5|6) to parrot, or compile python to parrot, etc; using
a different operator (or one operator, with a parameter indicating the
language used for method dispatch) for method calls for each language?
If so, do we offer a way of extending parrot to allow other method
lookup schemes?
It would be sad if we only offered perl5 and perl6 method dispatch using
a single op each, and had to use multiple ops each to emulate other
languages' method dispatch techniques.
--
$;=qq qJ,krleahciPhueerarsintoitq;sub __{0 &&
my$__;s ee substr$;,$,&&++$__%$,--,1,qq;;;ee;
$__>2&&&__}$,=22+$;=~y yiy y;__ while$;;print
Brent Dax
# 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 get it out and add it.
# Once we've got
# > it pretty much nailed I'll spec out the interface and we
# can start in
# > on the implementation.
#
# For the sake of completeness, I would like to ask, what are
# the semantics of multiple inheritance?
#
# Do we *only* natively offer a way of doing perl6 method
# dispatch
...
# Or, do we offer multiple ways to look methods up... one way
# for each language that we're compiling?
I would assume that method dispatch would be executed by the Object PMC,
which could easily be customized for a particular language (creating
e.g. PythonObject or RubyObject). So while Parrot might only ship with
one (or a few) set of dispatch semantics, it would be a SMOP to add one
for your favorite language. Objects would dispatch based on the
semantics of the language they were defined in, which to me seems to be
the right thing.
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Brent Dax
# 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 class in its inheritance
# tree.
#
# Attributes are considered class-private, so a class will normally
# only see its own attributes. There will be a mechanism to see all the
# attributes for an object, though. Code outside a class won't see the
# attributes--they aren't exposed.
...
I honestly don't care much about such languages, but how is Parrot going
to support classless languages like JavaScript? Are such languages
going to have to fake it with anonymous classes, or will we make sure
that you don't *really* need a class behind an object?
Erik Bågfors
> 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 you give 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
--
er...@bagfors.nu
fingerprint: 6666 A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Dave Whipp
> 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 semantics, with
separate steps for allocation of memory, binding to a class, and
initialization of attributes? In what order are these done (inc multiple
inheritance issues)? What is the state of the object if an exception is
thrown before construction is complete; and how is it cleaned up? Even
with GC, we must ask similar questions with respect to object
destruction. Will there be finalizers; in what order are they called,
and can they throw exceptions?
Dave.
--
mailto:da...@whipp.name
http://dave.whipp.name
Benjamin Goldberg
>
> 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.
> I honestly don't care much about such languages, but how is Parrot
> going to support classless languages like JavaScript? Are such
> languages going to have to fake it with anonymous classes, or will we
> make sure that you don't *really* need a class behind an object?
Presumably, the similarly to how Java handles JavaScript -- all
JavaScript objects are, from Java's point of view, members of one single
class, the "JavaScriptObject" class. (Well, something like that,
anyway).
Dan Sugalski
>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 missive, "Class Spec" :)
This time I was trying to define just the behaviour of objects that
already exist, rather than specifying their creation or how the
classes that own the objects behave.
I was going to punt on a lot of the rest for now, but I expect I
really shouldn't, so I'lll work up try 2.5 tonight. :)
>destruction. Will there be well defined creation semantics, with
>separate steps for allocation of memory, binding to a class, and
>initialization of attributes? In what order are these done (inc
>multiple inheritance issues)? What is the state of the object if an
>exception is thrown before construction is complete; and how is it
>cleaned up? Even with GC, we must ask similar questions with respect
>to object destruction. Will there be finalizers; in what order are
>they called, and can they throw exceptions?
Dan Sugalski
>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 you give a clear example of what the difference is between
>properties and attributes?
Properties are runtime assigned name/value pairs that are stuck on a
variable. They're not particularly restricted to objects, though many
systems do that. (We aren't going to) A property isn't guaranteed to
be on any particular object except perhaps by convention.
Attributes, on the other hand, correspond to instance variables or
slots in other object systems. They're generally guaranteed to be on
any object of a particular class or child of a particular class--if
class Foo defines an attribute bar, then all Foo objects will have a
slot for the bar attribute.
Attributes are often fixed at compile or object creation time, but
we're not going to do that as I don't think we can, much as I'd like
to.
Dan Sugalski
>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 class in its inheritance
># tree.
>#
># Attributes are considered class-private, so a class will normally
># only see its own attributes. There will be a mechanism to see all the
># attributes for an object, though. Code outside a class won't see the
># attributes--they aren't exposed.
>...
>
>I honestly don't care much about such languages, but how is Parrot going
>to support classless languages like JavaScript? Are such languages
>going to have to fake it with anonymous classes, or will we make sure
>that you don't *really* need a class behind an object?
Fake it with anonymous classes. It ought to work out OK, I think.
Peter Seibel
> 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 class in its inheritance
> # tree.
> #
> # Attributes are considered class-private, so a class will normally
> # only see its own attributes. There will be a mechanism to see all the
> # attributes for an object, though. Code outside a class won't see the
> # attributes--they aren't exposed.
> ...
>
> I honestly don't care much about such languages, but how is Parrot
> going to support classless languages like JavaScript? Are such
> languages going to have to fake it with anonymous classes, or will
> we make sure that you don't *really* need a class behind an object?
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
classes--languages that support generic functions and multimethods
(i.e. a method is dispatched at runtime based on the type of more than
one of its arguments.) I ask because I started looking at Parrot (and
joined this list) because I was interested in the idea of writing a
Common Lisp that runs on Parrot. I had looked at the CLR as a possible
target and found it too tied to the single-dispatch model of methods
"belonging" to particular classes. I was hoping things would be more
flexible here. Was I hoping for too much?
-Peter
--
Peter Seibel pe...@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Allen Short
> 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 classes--languages that support generic functions and
> multimethods (i.e. a method is dispatched at runtime based on
> the type of more than one of its arguments.) I ask because I
> started looking at Parrot (and joined this list) because I was
> interested in the idea of writing a Common Lisp that runs on
> Parrot. I had looked at the CLR as a possible target and found
> it too tied to the single-dispatch model of methods "belonging"
> to particular classes. I was hoping things would be more
> flexible here. Was I hoping for too much?
I'd expect defmethod/defgeneric to generate instances of a
"standard-generic-function" and "standard-method" class, which holds
the code and specializations, and whose methods implement CL-style
dispatch; this would make for a convenient MOP, as well as providing
some chance for interfacing with modules in other languages.
Allen
Peter Seibel
So if I did that (and it makes sense) what are the chances that the
JIT would be able to do anything smart in the case where all the
methods defined on a generic function happen to be single dispatch?
I'm assuming that the code to do fully general CL-style dispatching is
going to be slower than the "native" single dispatch; in the case
where all the methods *are* in fact single dispatch, I'd like to
compile them to the "native" single dispatch rather than going through
a bunch of generalized machinery.
Again, apologies if this is all out of nowhere and ignorant to
boot--I've just recently started looking at Parrot.