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
--- 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 somet
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 orthogo
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
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.
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
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 a
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
[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
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( fre
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 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
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
[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
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
> > 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
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:
#
34 matches
Mail list logo
