# New Ticket Created by Allison Randal
# Please include the string: [perl #21476]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21476 >
I couldn't compile imcc under OS X because of a repeat of the old "ld:
multiple defini
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
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 he
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 se
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 w
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. Inte
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
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
--- 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.
>
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
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
--- 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 Associa
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 with
this?
Regards,
-- Gregor Purdy
Sam Vilain
> > 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 metho
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 "non-interc
--- [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 prog
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?
If
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 l
> 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 cou
--- 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 resul
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 ha
Jonathan Sillito wrote:
-Original Message-
From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
And from imcc's register allocations POV the whole coroutine stuff is a
PITA, no registers are preserved, AFAIK, so a coroutines and the caller
+ all edges out from both do share the same registers,
Tupshin Harper wrote:
In my ongoing quest to understand the possibilities (and possible
limitations) of parrot, here's another one. ;-)
How close a mapping can there be between regular (x86 in this example)
assembly (as generated by c-compilation) and pasm?
I can't figure out if the stack ops ca
25 matches
Mail list logo
