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
--- 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
> 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
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
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
--- [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
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
> > 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
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
--- 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
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
--- 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.
>
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
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. Inte
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 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
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 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 pe
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
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
22 matches
Mail list logo
